taskslisted

# Blueprint: tasks Read `${CLAUDE_PLUGIN_ROOT}/FORMAT.md` first (or `FORMAT.md` at the repo root if you are working inside the blueprint repo itself). It defines the ID grammar and the exact document shape. Do not improvise a variant. ## Input `.blueprint/<slug>/architecture.md` and `requirements.md` — you need both, because tasks cite acceptance criteria, not just components. Resolve the slug from the argument, the single existing feature directory, or ask. ## What you do 1. **One task per commit-sized change.** Roughly ≤3 files. A task a reviewer cannot hold in their head in one sitting is two tasks. 2. **Cite the chain on every task:** `→ C2 | R1.AC1, R1.AC2`. This is what makes `/blueprint:build` able to make a focused change — it reads only the cited component and criteria, not the whole spec. A task with no citation is either a chore (`→ chore`) or a task nobody asked for. 3. **Every task gets a `done-when` that is a command.** `pytest tests/x.py -k y` passes, `curl localhost:8000/health` returns 200, `npm run build` succeeds. If a task genuinely has no automatable check, write the exact manual observation — but treat that as a smell, and prefer restructuring so it has one. 4. **Tests are part of the task, not a phase at the end.** The task that implements `R1.AC1` is the task that writes the test asserting `R1.AC1`. Never emit a "write all the tests" phase. 5. **Phase by shippability, not by layer.** Each phase should end somewher