Build a to-do board you share with your agents

A brief for an agent. It sets up what Ben Tossell describes in "I wanted to see my to-dos": one markdown file of to-dos on your human's computer, a page that shows it and ticks lines, grouped by the areas of their life, and a private copy on the web that only they and their agent can open. Build it for your human's own setup.

Ask your human first

One question at a time. Suggest an answer each time.

Where should the to-do file live? (A markdown file in a folder they can open and that you can read and write. If there is none, make todos.md.)
Which areas of life or work should the board group by? (For example: Work, Newsletter, Home, Family.)
Which agents do they use, and what does each one look after? (Write this down; the board's Map shows it.)
Do they want it on their phone? If yes: here.now (or a host with a small database and email-based access), and which emails may open it. Usually their own and their agent's.

The rules that make it work

The file is the only truth. The page, the site and every agent read it and write to it. Anything else is a copy.
One line per to-do. A change edits one line and leaves every other byte alone. Write the file atomically (temp file, then rename).
Find the line safely. The page sends {file, line number, exact line text}. If that line moved, look for the exact text once elsewhere; if it is not there exactly once, refuse and reload.
Everything about a to-do lives in its line, as tags at the end, because agents edit the file directly.

The line format

- [ ] Short title: details #area #status #due:YYYY-MM-DD #id:xxxxxxxx
- [x] Short title: details #area #done:YYYY-MM-DD #id:xxxxxxxx

Short title: 8 words or fewer, before the first colon. Details after it.
Status, one only: #today, #in-progress, #waiting, #open. No tag means open.
Area: #work or #work/project.
#done: is the day it was ticked. #id: is a permanent 8-character id, so rewording a line keeps it the same item. New lines get one at the next sync; never write one by hand.

Give this section to every agent that edits the file.

Build it in this order

Check each step before the next. Test on a copy of the file first.

A local page. A small server on the computer (Python's standard library is enough) and one HTML file: show the to-dos grouped by area and status, tick a box to change its line, re-read the file every few seconds so agents' edits show up. Light and dark follow the system.
Online, private. Publish the page to here.now and set access to "specific emails": your human's and yours. Anyone else gets a 401. A free here.now account is enough; restricted access needs the site to belong to an account, not an anonymous publish.
Ticks from the phone. Add a here.now Site Data collection for the to-dos (one record per to-do, key = its id). The page reads it and saves ticks to it from the browser. Site Data follows the site's access, so it is as private as the page.
A sync script on a timer (every 10 minutes: launchd on a Mac, cron on Linux). First pull: apply changes from the site to the file, one line each. Then push: send the whole list back up. If the same line changed in both places since the last run, the file wins. If the site can't be read, change nothing. When the computer is off, the site keeps working and the next run catches up.
A map and a work log. map.md: one card per area (what it is, where it lives, who looks after it), shown on a Map tab. work-log.md: append-only, one line per thing an agent makes (- YYYY-MM-DD HH:MM | agent | area | what | path or link | status), shown on a Log tab. It is mostly for agents: who did what, where and when.
Agent rules. Tag a to-do #in-progress when you start it, tick it with #done: when you finish, add a work-log line, and ask your human before adding new work.

Optional: let your agents talk to each other

Only if your human asks. Ben's setup, for reference:

His personal agent (bites, in Grok Bot) can start jobs in his coding agent. A few lines in his AGENTS.md say how, and he calls those jobs "Bill".
The personal agent has its own email address (some apps let you set one; services like AgentMail give any agent an inbox) and a trigger that runs it the moment an email lands. Coding jobs report back by email.
A comment on the board that mentions the personal agent (@bites) emails it the to-do and its context; it replies on the board.
His services (Gmail and the rest) connect once, through Executor, so every agent has the same access.

If your human wants this, ask them which personal agent and which coding agent they use, then work out the simplest version for their tools.

Keep it safe

Nothing is sent, published or pushed without your human saying yes.
Never edit agent instruction files unless asked.
Back up before changing many lines, and compare counts before and after.
Keep the live site restricted: it holds real to-dos.

# Build a to-do board you share with your agents A brief for an agent. It sets up what Ben Tossell describes in "I wanted to see my to-dos": one markdown file of to-dos on your human's computer, a page that shows it and ticks lines, grouped by the areas of their life, and a private copy on the web that only they and their agent can open. Build it for your human's own setup. ## Ask your human first One question at a time. Suggest an answer each time. 1. Where should the to-do file live? (A markdown file in a folder they can open and that you can read and write. If there is none, make `todos.md`.) 2. Which areas of life or work should the board group by? (For example: Work, Newsletter, Home, Family.) 3. Which agents do they use, and what does each one look after? (Write this down; the board's Map shows it.) 4. Do they want it on their phone? If yes: here.now (or a host with a small database and email-based access), and which emails may open it. Usually their own and their agent's. ## The rules that make it work 1. **The file is the only truth.** The page, the site and every agent read it and write to it. Anything else is a copy. 2. **One line per to-do. A change edits one line and leaves every other byte alone.** Write the file atomically (temp file, then rename). 3. **Find the line safely.** The page sends `{file, line number, exact line text}`. If that line moved, look for the exact text once elsewhere; if it is not there exactly once, refuse and reload. 4. **Everything about a to-do lives in its line**, as tags at the end, because agents edit the file directly. ## The line format ``` - [ ] Short title: details #area #status #due:YYYY-MM-DD #id:xxxxxxxx - [x] Short title: details #area #done:YYYY-MM-DD #id:xxxxxxxx ``` - Short title: 8 words or fewer, before the first colon. Details after it. - Status, one only: `#today`, `#in-progress`, `#waiting`, `#open`. No tag means open. - Area: `#work` or `#work/project`. - `#done:` is the day it was ticked. `#id:` is a permanent 8-character id, so rewording a line keeps it the same item. New lines get one at the next sync; never write one by hand. Give this section to every agent that edits the file. ## Build it in this order Check each step before the next. Test on a copy of the file first. 1. **A local page.** A small server on the computer (Python's standard library is enough) and one HTML file: show the to-dos grouped by area and status, tick a box to change its line, re-read the file every few seconds so agents' edits show up. Light and dark follow the system. 2. **Online, private.** Publish the page to here.now and set access to "specific emails": your human's and yours. Anyone else gets a 401. A free here.now account is enough; restricted access needs the site to belong to an account, not an anonymous publish. 3. **Ticks from the phone.** Add a here.now Site Data collection for the to-dos (one record per to-do, key = its id). The page reads it and saves ticks to it from the browser. Site Data follows the site's access, so it is as private as the page. 4. **A sync script** on a timer (every 10 minutes: launchd on a Mac, cron on Linux). First pull: apply changes from the site to the file, one line each. Then push: send the whole list back up. If the same line changed in both places since the last run, the file wins. If the site can't be read, change nothing. When the computer is off, the site keeps working and the next run catches up. 5. **A map and a work log.** `map.md`: one card per area (what it is, where it lives, who looks after it), shown on a Map tab. `work-log.md`: append-only, one line per thing an agent makes (`- YYYY-MM-DD HH:MM | agent | area | what | path or link | status`), shown on a Log tab. It is mostly for agents: who did what, where and when. 6. **Agent rules.** Tag a to-do `#in-progress` when you start it, tick it with `#done:` when you finish, add a work-log line, and ask your human before adding new work. ## Optional: let your agents talk to each other Only if your human asks. Ben's setup, for reference: - His personal agent (bites, in Grok Bot) can start jobs in his coding agent. A few lines in his `AGENTS.md` say how, and he calls those jobs "Bill". - The personal agent has its own email address (some apps let you set one; services like AgentMail give any agent an inbox) and a trigger that runs it the moment an email lands. Coding jobs report back by email. - A comment on the board that mentions the personal agent (`@bites`) emails it the to-do and its context; it replies on the board. - His services (Gmail and the rest) connect once, through Executor, so every agent has the same access. If your human wants this, ask them which personal agent and which coding agent they use, then work out the simplest version for their tools. ## Keep it safe - Nothing is sent, published or pushed without your human saying yes. - Never edit agent instruction files unless asked. - Back up before changing many lines, and compare counts before and after. - Keep the live site restricted: it holds real to-dos.