/implement — build it, test-first
Goal: turn the plan into working, tested, clean code — one phase at a time.
Do this
- Branch first (non-trivial work). Apply branch-at-first-write (
rules/git.md): not a
git repo → skip silently; already on a non-default branch → stay there; on the default
branch (main/master/develop, or what git symbolic-ref refs/remotes/origin/HEAD resolves
to) → create claude/feat-<slug> (slug from .claude/STATE.md) before the first
file edit. Never commit or push — that stays gated behind the user's explicit ask.
- Take the plan's tasks in order — read
.claude/planning/<slug>/PLAN.md if present (slug
in .claude/STATE.md) so a fresh-context executor works from the file, not the
conversation. For each task/phase:
- Delegate to
harness-claude:tdd-guide (or run TDD inline): write a failing test against an
acceptance criterion (RED) → minimum code to pass (GREEN) → refactor.
- Keep files modular and lean (<800 lines), immutable patterns, inputs validated.
- Let the format/typecheck hooks run; fix what they flag immediately.
- Parallel-fan-out checkpoint — evaluate before editing, don't skip. Before you start
editing a phase serially, count the files it will write. If it spans 3+ independent files
with disjoint write-sets and no dependency between them (the plan may already flag this
phase as a
/harness-claude:orchestrate candidate), you must surface the fan-out option: name the file
split and propose /harness-claude:orchestrate, then let the user choose before proceeding.
Surfacing the offer is mandatory whenever the trigger fires — that is the only path by
which parallel mode ever gets used; what stays opt-in is acting on it — never silently
start a multi-agent run (it spawns workers and costs more tokens). If the trigger doesn't fire,
note that in one line and edit serially.
- After each phase, confirm its exit check (test green, build clean) before moving on.
- If the build breaks and the fix is non-obvious, hand off to
/harness-claude:build-fix.
- Stay inside the plan. If reality diverges from it, stop, update the plan, then resume
— don't silently improvise scope.
Token discipline
Delegate search/exploration and isolated edits to cheaper models; keep the orchestrator
focused on integration. Compact at phase boundaries, not mid-phase.
Common rationalizations (don't accept these from yourself)
| Excuse |
Reality |
| "I'll write the tests after the code works" |
Tests written after mirror the implementation, not the criterion. RED first, or it isn't TDD. |
| "This phase is too small to test" |
Small phases grow. The test is the phase's exit check — without it, "done" is an opinion. |
| "The plan is close enough; I'll adjust as I go" |
Silent divergence is how scope creeps. Stop, patch the plan, resume. |
| "Branching is overhead for this" |
A branch is one command and fully reversible; un-picking mixed work on the default branch is neither. |
| "Fan-out doesn't apply here" (without counting) |
Count the write-set first. Skipping the count is how the offer never fires. |
Red flags — stop and re-check
- Code exists for which no test was ever RED.
- You're editing a file the plan never named.
- A hook flagged something and you deferred it "until the end".
- You're three phases in with no green checkpoint between them.
State
On completion, patch .claude/STATE.md: phase: implement, status: done,
next_skill: /review.
Exit criterion
All phases complete, tests written-first and green, build/types/lint clean. Then
proceed to the Verify phase (/harness-claude:review).
1---2name: implement3description: Execute a plan via test-driven development — write tests first, then minimal code, phase by phase. Use after /plan (and /architect if needed) to write the actual feature. Delegates to the harness-claude:tdd-guide agent.4---56# /implement — build it, test-first78Goal: turn the plan into working, tested, clean code — one phase at a time.910## Do this111. **Branch first (non-trivial work).** Apply branch-at-first-write (`rules/git.md`): not a12 git repo → skip silently; already on a non-default branch → stay there; on the default13 branch (main/master/develop, or what `git symbolic-ref refs/remotes/origin/HEAD` resolves14 to) → create `claude/feat-<slug>` (slug from `.claude/STATE.md`) **before** the first15 file edit. Never commit or push — that stays gated behind the user's explicit ask.162. Take the plan's tasks in order — read `.claude/planning/<slug>/PLAN.md` if present (slug17 in `.claude/STATE.md`) so a fresh-context executor works from the file, not the18 conversation. For each task/phase:19 - **Delegate to `harness-claude:tdd-guide`** (or run TDD inline): write a failing test against an20 acceptance criterion (RED) → minimum code to pass (GREEN) → refactor.21 - Keep files modular and lean (<800 lines), immutable patterns, inputs validated.22 - Let the format/typecheck hooks run; fix what they flag immediately.233. **Parallel-fan-out checkpoint — evaluate before editing, don't skip.** Before you start24 editing a phase serially, count the files it will *write*. If it spans **3+ independent files25 with disjoint write-sets and no dependency between them** (the plan may already flag this26 phase as a `/harness-claude:orchestrate` candidate), you **must** surface the fan-out option: name the file27 split and propose `/harness-claude:orchestrate`, then let the user choose before proceeding.28 Surfacing the offer is **mandatory whenever the trigger fires** — that is the only path by29 which parallel mode ever gets used; what stays **opt-in is *acting* on it** — never silently30 start a multi-agent run (it spawns workers and costs more tokens). If the trigger doesn't fire,31 note that in one line and edit serially.324. After each phase, confirm its exit check (test green, build clean) before moving on.335. If the build breaks and the fix is non-obvious, hand off to `/harness-claude:build-fix`.346. Stay inside the plan. If reality diverges from it, stop, update the plan, then resume35 — don't silently improvise scope.3637## Token discipline38Delegate search/exploration and isolated edits to cheaper models; keep the orchestrator39focused on integration. Compact at phase boundaries, not mid-phase.4041## Common rationalizations (don't accept these from yourself)4243| Excuse | Reality |44|--------|---------|45| "I'll write the tests after the code works" | Tests written after mirror the implementation, not the criterion. RED first, or it isn't TDD. |46| "This phase is too small to test" | Small phases grow. The test is the phase's exit check — without it, "done" is an opinion. |47| "The plan is close enough; I'll adjust as I go" | Silent divergence is how scope creeps. Stop, patch the plan, resume. |48| "Branching is overhead for this" | A branch is one command and fully reversible; un-picking mixed work on the default branch is neither. |49| "Fan-out doesn't apply here" (without counting) | Count the write-set first. Skipping the count is how the offer never fires. |5051## Red flags — stop and re-check52- Code exists for which no test was ever RED.53- You're editing a file the plan never named.54- A hook flagged something and you deferred it "until the end".55- You're three phases in with no green checkpoint between them.5657## State58On completion, patch `.claude/STATE.md`: `phase: implement`, `status: done`,59`next_skill: /review`.6061## Exit criterion62All phases complete, tests written-first and green, build/types/lint clean. Then63proceed to the Verify phase (`/harness-claude:review`).
vasuag09