Task files in stage directories are the only source of truth. A stdlib-only board narrates what happens to them — agents working in git worktrees, PRs opening on review, CI on the cards — and never merges anything itself.
no account, no service, no database. it is python 3 on your own machine.$ mkdir .task-manager && curl -L \ https://github.com/12vectors/bench/releases/latest/download/bench.tar.gz \ | tar -xz -C .task-manager $ ./.task-manager/start.sh No .task-manager/manager/local/.env yet — a few questions and bench writes one. solo or team? [solo]: which agent adapter? [claude]: what command runs this project's tests? [python3 -m unittest]: Task board for ~/your-repo/.task-manager/tasks http://127.0.0.1:26071/ Ctrl-C to stop
from AGENTS.md — the section below is this file's, not a retelling of it
Where new tasks are written and where they wait. A backlog task may be rough, incomplete, or fully specified — what it has in common with its neighbours is that nobody is working on it. Most tasks live here for most of their life.
Picked up and queued to work on next. Moving a task from backlog/ to to-do/
is a commitment to do it soon, so keep this directory short — a long to-do/ is
just a second backlog.
Actively being worked on right now. Anything here should have someone (or an
agent session) attached to it. If work stalls, move it back to to-do/ or
backlog/ rather than leaving it parked — a stale in-progress/ makes the board
lie about what is happening.
Implementation plans (created via Claude Code's plan mode) are stored in plans/
and can be referenced from the task file.
The work is built and awaits judgment: tests written and passing, a PR open
(see "Pull requests"), behaviour checked in the running app, edge cases
probed. A task sitting here has code but not yet confidence. If review turns
up problems, move it back to in-progress/.
Finished and merged. Completed task files are kept as a record of what was built and why — they are the closest thing we have to design history, so don't delete or trim them.
Supporting documents that tasks can link to — external specs, API documentation,
research notes, screenshots, competitive analysis, regulatory references, etc.
These don't move through the workflow; they're stable resources. Reference them
from task files using relative links — two levels up from a stage directory
(e.g. [IVASS spec](../../reference/ivass-document-requirements.md)).