Skip to main content
Interlaced eucalypt canopies with birds threading between the crowns, in a three-ink risograph print

Task tracking

A structured task list, held outside the agent's context window, is the plan's external source of truth

A task tracker holds that list where both sides can see it: the agent reads and writes it between turns, and so do you, as work proceeds. It records what’s done, what’s in progress, and what’s still to come.

Without one, the plan exists only in the conversation. As the conversation grows, earlier sub-tasks may leave the context window, and “done” can mean only that the agent claimed completion. A tracker records the complete task list and lets both you and the agent compare each progress report with the file.

Markdown and file-based trackers

Spec-driven workflows produce task lists too

The same pattern shows up inside the spec-driven toolkits — spec-kit, superpowers, cc-sdd, agent-os; see the catalogue’s spec-driven section — which take a brief or PRD and emit a tracked task list as the Tasks stage of a longer pipeline, rather than offering the tracker as a standalone tool.

MCP-server task lists

Pick one and keep it boring

Use whichever tool you will update consistently. For coursework, keep one tracker per prototype across sessions. On the morning of your cutoff, it should show exactly what remains before the crit.

Use separate tools for separate records. The agent’s tracker (beans, beads, Backlog.md) is working memory that can be rewritten freely. A human-visible tracker (Linear, GitHub Issues, or a course assignment brief) is the permanent record across sessions.