| name | tdd |
| description | Red-green-refactor mode for behavior with clear inputs, outputs, and regression value. |
TDD
Purpose
Use $tdd when behavior can be specified before implementation. TDD is for design pressure and regression safety, not for ritual.
Good TDD Candidates
- business rules
- API contracts
- parsing/formatting/validation
- state transitions
- algorithms and utility behavior
Skip TDD For
- pure layout and styling work
- config-only changes
- trivial glue code
- exploratory prototypes where the behavior is not yet known
Iron Law
No production code without a failing test first.
Cycle
- Red
- write the smallest failing test for the next behavior
- run it and prove it fails for the right reason
- Green
- write the minimum code to make it pass
- rerun the test and the relevant suite
- Refactor
- clean up only after green
- keep the suite green after every change
Rules
- one behavior per cycle
- do not batch multiple features into one red-green pass
- prefer regression tests for changed behavior
- record the verify command in the plan or task notes
Output Standard
- what behavior the test locked in
- the failing signal
- the minimal implementation
- the final verification command