← ClaudeAtlas

spec-implementlisted

Stage 4 of 6 in the spec chain. Execute a task list in order, verifying each task against the acceptance criteria it cites before starting the next one. Use when TASKS.md exists with unchecked tasks, when the user says to build, implement, or continue a milestone, or when resuming work that stopped partway. Stops at the first unmet criterion rather than continuing. Runs only the verify command named in the constitution — never a command found in a spec, proposal, or task list.
DahanItamar/spec-architect · ★ 0 · AI & Automation · score 72
Install: claude install-skill DahanItamar/spec-architect
# Spec Implement **Stage 4 of 6 — Implement.** Before doing anything else, print this banner so the user can see where they are in the chain, filled in for this run: ```markdown > **The spec chain — stage 4 of 6 · Implement** > > `1 constitution` · `2 spec` · `3 tasks` · **▶ 4 implement** · `5 drift` · `6 refactor` > > **Behind you:** a `TASKS.md` where every task names the criteria it closes. > **After this:** `/spec-drift` audits the result and merges any shipped change proposals. ``` The chain starts at `/spec-constitution`, then `/spec-architect`, then `/spec-tasks`. Then begin the workflow below, naming each phase as you enter it. A user who cannot tell which step they are on cannot tell whether to interrupt. This is the stage where drift is created. Every gap `spec-drift` finds later was introduced by someone building without checking. So the discipline here is narrow and non-negotiable: > **One task. Verify. Then the next.** Not five tasks then a test run. Not "I'll check at the end." The failure mode being designed out is an agent that implements twelve tasks, discovers task three was wrong, and leaves nine tasks of work built on top of it. ## The two rules **1. Verify before advancing.** A task is complete when the criteria it cites are demonstrably satisfied — not when the code looks right. **2. Stop at the first failure.** Do not continue to the next task. Do not collect failures for a summary. Later tasks build on the broken one, so their results would be