| name | implement-feature |
| description | Use after analyze reports clean to implement the active feature's tasks.md, one task at a time with TDD, once spec.md and plan.md both carry status:approved. |
implement-feature
When: spec, plan, and tasks all exist for the active feature, analyze reported clean, and a human has flipped both spec.md and plan.md to status: approved. The phase-gate hook (core/claude/hooks/phase-gate.mjs) enforces this — it blocks Edit/Write on code files until both carry status: approved; it does not check tasks.md.
Template: none — this skill writes/edits source and test files per the task breakdown, not a spec-style document.
Output: source + test code for ONE task from specs/<active-feature>/tasks.md, plus the corresponding checkbox ticked.
Steps:
- Resolve the active feature from
.specify/state (fallback: newest dir under specs/).
- Read
specs/<active-feature>/tasks.md and pick the next unchecked top-level task (in order — do not skip ahead).
- Read that task's subtasks plus the relevant slices of
spec.md (Requisitos Funcionais, Critérios de Aceitação) and plan.md (Arquitetura, Estrutura de Arquivos, Decisões Técnicas) to ground the implementation. If .specify/impl-conventions.txt lists convention lenses (from packs such as stack-conventions), apply the relevant ones as you write — naming (code↔DB↔wire), Postgres indexing/RLS, TS type-at-the-boundary — matching existing code over inventing. Empty registry ⇒ no-op. When a subtask uses a framework/library API whose current shape you are recalling from memory, follow source-driven-development — verify it against the installed version's official docs (via context7/WebFetch) and cite the source, rather than coding the signature from training memory.
- If Edit/Write is blocked with a phase-gate error, stop and report it — do not work around the gate; the spec/plan need approval first.
- Implement with TDD — REQUIRED, follow the
test-driven-development skill for every subtask. Iron Law: NO production code without a failing test first. Test BEHAVIOR (observable outcomes), never implementation details or mocks. Per subtask: write the failing test, watch it fail for the right reason, then climb the laziness ladder before writing code (reuse existing → stdlib → native → installed dep → one-liner → minimum viable; see the architecture skill's minimalism.md) — never at the cost of validation/data-loss/security/a11y — and write the minimal code to pass, refactor while green. Skipping test-first or asserting on mocks is not allowed — delete and start over.
- Work ONE task at a time. Do not start the next top-level task in the same pass — stop after the current one is done and tested.
- Tick the task's checkbox in
tasks.md once its subtasks are all complete and its tests pass.
- Do not run
.specify/gates/run-gates.sh yourself here — that is fix-runner's job — but do not leave the codebase in a state you know fails to compile or run its own tests.
Model routing: when this skill's work is handed to a subagent (via dispatching-parallel-agents) instead of run inline, size the model to the task's real difficulty — do NOT inherit the session model by default. A 1-2 file task with a complete spec is transcription-plus-testing: cheapest tier. Multi-file integration or design judgment: standard-or-top tier. See the routing-minimum-capable-model skill and subagent-driven-development's Model Selection. (For 3+ independent tasks, implement-and-evaluate should be in dispatch mode, which handles this routing per task.)
Next: evaluator, then fix-runner, looped via implement-and-evaluate until all tasks are done.
