A Todo List That Tracks Itself

Steve Yegge just published beads, a git-native todo list for AI coding agents. I’ve been looking at it and the core concepts are fantastic. Issues stored as an append-only log right in the repo. No external service to configure. State that survives between agent sessions because it’s in the working tree, not in a conversation that gets garbage collected.

But its biggest premise I disagree with.

Beads is a todo list for agents. Agents create tasks from their work, then agents work on them, creating more tasks in the process. Repeat. But now you have split your work in two worlds: tasks for humans still living in issue trackers like Jira, Linear or GitHub issues. Tasks for agents living in the beads database.

The best work happens when human and agent are genuine collaborators working from the same information and knowledge. I spot a design problem, the agent helps me classify it. The agent surfaces a decision point, I make the call. That only works if we’re both looking at the same task list, not two separate systems where I have to translate between human-land and agent-land.

The other thing I keep coming back to: setting up issue tracking for a new project is painful. You create a Jira project or a Linear workspace, define your workflows, configure labels, set up statuses. Suddenly you’ve spent an afternoon on process before writing a line of code. For a prototype or an experiment, it’s just not worth it. So you don’t bother, and the project that would’ve benefited from some structure never gets any.

But beads showed something real: agents derive genuine value from having a todo list that survives context and sessions. So there’s a clear need. The setup cost is what kills it. And it has to work equally well for both sides: a shared surface where human and agent can decompose a problem into stories, prioritize, discuss, assign, and work things off together. Not a human tool that agents can poke at, and not an agent tool that humans can inspect. A meeting point.

I want something opinionated enough that you can start using it in 30 seconds. No workflow design, no configuration ceremony. Rails over Spring.

So I’m building it. A Go CLI called Beats.

What exists after two days

It’s December 18th and I’ve been at this since this afternoon. By the end of today: creating issues, listing them with status icons, tracking parent-child relationships, filtering by state and time ranges, searching by keyword, and warning about duplicates. All stored in a JSONL file in a .beats/ directory in the repo.

The tool is already tracking its own development. The first bug was filed 20 minutes after the initial checkin, “first item in list has purple background highlight,” and fixed 2 minutes later. The second bug followed immediately: “first item has extra indentation.” This is the kind of tight loop I want: notice a problem, file it in the tool, fix it, mark it done, all without leaving the terminal.

There’s something deeply satisfying about this. Before today I was tracking ideas and bugs for my projects in markdown files. Flat lists of checkboxes. It worked when there were ten items. At eighty items it was chaos. No status tracking, no relationships between items, no history of what changed and why. Just a growing document that I’d scroll through hoping I remembered what was important.

Now the tool that replaces that markdown file is being built with the tool itself. I’m eating my own dogfood from commit one. If it can’t manage its own development, it has no business managing anyone else’s.

The decisions I’m making early

Append-only event log. Every change is an event appended to a file. No mutations. This means the full history of every issue is preserved: who changed what, when, and from what state. I have a strong intuition that this will pay off later in ways I can’t fully see yet. At minimum it means undo and audit trails come for free.

Four issue types: Task, Bug, Epic, Story. No custom types. This covers what I need and I suspect it covers what most small teams need.

Five statuses: Backlog, Todo, In Progress, Review, Done. No custom workflows. The simplicity is the point. You can start using the tool without reading a manual.

Parent-child relationships. Epics contain stories and tasks. When a child’s status changes, the parent updates automatically. This keeps the hierarchy consistent without manual bookkeeping.

Auto-commit optional. The tool can auto-commit issue changes to git, but it’s configurable. I want every status change in the git history for my projects. Other people might want to batch them. Both should be valid.

Tomorrow: interactive mode, shell completions, archive and delete. I want this to feel like a proper CLI tool, not a toy.