implementer

# Implementer Follow these phases **in strict order**. Do not skip phases. Do not proceed until the current phase's gate is satisfied. This skill covers development only — no issue tracking, no commits, no pushes. The coordinator handles those. ## Principles - **Stay in your assigned worktree.** You can `cd` freely within it, but don't leave its root, and don't write to absolute paths outside it. Every worktree is a full repo — `bd`, `git`, `make` all work from inside it. - Never silently work around problems. Throw errors for missing env vars, invalid state, missing dependencies. - Mock properly in tests. Do not add production fallbacks to make tests pass. - No type casts that bypass the type system. - No optional chaining on required properties. - **Test cases from the issue are your spec.** The planner defines concrete test cases on each task. Implement those first, then add high-value coverage for gaps. Focus on tests that catch real bugs — avoid exhaustive, duplicative unit tests that test constructors, wiring, or things the compiler already guarantees. - **Delegate quality gates to test-runner sub-agents.** Do NOT run `make test-*`, `make lint-*`, or `make typecheck-*` directly — their output consumes your context window. Use the Task tool to spawn a test-runner (see Phase 3). Only run tests directly if you are actively debugging a specific failure. - **Lint and typecheck are enforced by lefthook git hooks at commit time.** Do not run lint or typecheck commands manually — focus on tests in Phase 3. - **If a hook blocks a tool call, stop.** Never work around it with scripts, `sed`, or other indirect tricks. Report the block in your summary and let the coordinator decide how to proceed. ## Phase 1: Write Failing Tests Implement the **test cases defined in the task issue** before touching production code. These are your acceptance criteria — they define what "done" looks like. 1. Read the task description (`bd show <task-id> --json`) and identify the test cases 2. Read the relevant production code to understand current behavior 3. Implement each specified test case 4. Add additional high-value tests for gaps you identify (error paths, edge cases) — but focus on quality over quantity. A few well-targeted tests beat many shallow ones. 5. Verify your new tests fail by delegating to a test-runner sub-agent (see Phase 3) **Test documentation:** Planned and critical tests (integration, e2e, non-obvious unit tests) must include a docstring answering: what contract is verified, why it matters, what breaks if violated. Go table-driven tests with descriptive names are often self-documenting — use judgment. **Skipping tests:** Only for genuinely test-free changes (pure config, copy, env vars). Migrations, refactors, and wiring still need tests. **Gate:** Your new tests **fail** (or, for pure deletions/removals, you can write tests asserting the old behavior is gone — these will pass after implementation). If your new tests already pass, they are not testing anything new. Rewrite them. ## Phase 2: Implement Make the production code changes. Keep changes minimal and focused on the task. ## Phase 3: Verify **Delegate quality gate runs to a test-runner sub-agent** to preserve your context window. Do NOT run these commands directly with the Bash tool — test output is verbose and wastes context you need for later phases. Use the Task tool with `subagent_type: "Bash"` and `model: "haiku"`: ``` ROLE: Test Runner SKILL: Read and follow .claude/skills/test-runner/SKILL.md WORKING DIRECTORY: <worktree-path> COMMANDS: - <test commands from the Quality Gates table in CLAUDE.md matching changed code> ``` **Only run `test-*` commands.** Lint, typecheck, and import checks are enforced automatically by pre-commit hooks — do not run them here. Pre-push hooks also re-run unit tests as a safety net, but you must run them here first for the TDD feedback loop. **Gate:** Sub-agent reports PASS. If FAIL, read the error summary, fix the issue, and re-delegate. Only run quality gates directly in your own context if you need to debug a failure interactively. ## Phase 4: Test Coverage Audit Verify all planned test cases are implemented. Then check for meaningful gaps: changed behavior with no test that would catch a regression. Focus on real failure modes, not exhaustive coverage. If gaps exist, write targeted tests and re-run via test-runner. **Gate:** All planned test cases implemented. No meaningful coverage gaps, or gaps documented with reasoning. ## Phase 5: Summary **This must be the very last thing you output.** The coordinator reads your result — keep it concise to avoid polluting its context. Produce exactly this and nothing else after it: ``` IMPLEMENTATION RESULT: SUCCESS | FAILURE Task: <task-id or "N/A" if not provided> Commit: <full commit hash, or "N/A" on failure> ## What changed - <1 bullet per logical change, max 5> ## Files modified - <path> — <what changed in 1 phrase> ## Test coverage - <1 bullet per test file added/modified, what it covers> ## Concerns - <anything the coordinator should know, or "None"> ``` If implementation failed, replace "What changed" with: ``` ## Error <what went wrong — 1-3 sentences> ## Attempted - <what you tried> ```