implementlisted

# implement — Build a spec, task by task ## Preconditions - A spec exists at `.specs/<slug>/spec.md`. If `<slug>` is omitted, list the live specs and ask which one. - Its `Status` is `approved`. If it is `draft`, say so and ask before starting — implementing an unreviewed spec is how a misread requirement becomes a merged branch. If it is `done` or `archived`, this is a resume or a mistake; establish which. - The branch is `<slug>`. Offer to create it from the default branch. - `.steering/tech.md` names this project's validators and its reviewer. **Read it now; never assume commands.** ## The loop For each task in the spec's Tasks list, in order: 1. **Red** — write the failing test the task names. Run it. Confirm it fails **for the stated reason**, not for a setup error. A test that fails because of a typo has proved nothing. 2. **Green** — the smallest implementation that passes. Run the tests. 3. **Refactor** — clean up under green tests. Re-run the validators. 4. Tick the task, then make one commit scoped to that task, in this project's commit convention (see `.steering/tech.md`). ## Review gate — mandatory When every task is committed and the validators pass: 1. Run the full validator set from `.steering/tech.md`. Set the spec `Status: done`. 2. **Invoke the reviewer subagent** named in `.steering/tech.md`, asking it to review the branch diff against the default branch, and against `.specs/<slug>/spec.md`. **Invoke it and wait for its result in the same turn. Do n