implement-spec

Implementing a spec

The spec is the contract; this skill is how the contract becomes code without losing anything on the way. It exists because prose discipline drifts and checklists don't — follow it in order. (Until specs/ exists here, "the spec" is the plan or decision the change implements — research/ plans and AGENTS.md → Decisions entries count.)

1 · Breakdown before code

Read the spec twice. Decompose it into aspects — every contract clause, every negative promise, every error slug, every acceptance line is an aspect. Write the list into the working branch's commit plan. An aspect with no test planned is a hole: fix the plan, not later.

2 · Red first

Turn the spec's acceptance into failing tests before any implementation — integration tests verbatim where the spec gives observable behavior, unit tests for what it marks unit-tier. Run them; watch them fail for the right reason. The implementation's job is to turn exactly these red lights green — nothing more. If implementing reveals the acceptance is wrong, fix the spec in the same commit (code wins; supersession visible).

3 · Implement in aspect-sized commits

One aspect, its test, its code — smallest change that proves the next assumption. Never batch five aspects into one commit; review dies there.

4 · Aggressive self-review before declaring anything

Before "done", attack your own work the way this repo attacks specs:

• Re-read the spec clause by clause against the diff — every clause either has a passing test or a written reason it can't.
• Hostile pass: what did I not handle — interruption, empty input, weird names, missing binary, no network, wrong platform? The error contract is the map; every failure path must be reachable and tested.
• For anything non-trivial, run the repo's adversarial pattern: independent reviewers with distinct lenses (/code-review at high effort, or spawn review agents). Findings get fixed or recorded — never quietly dropped.