| name | tdd |
| description | Drive a single behavior change with Kent Beck's red → green → refactor loop — write the failing test FIRST, confirm it fails for the right reason, implement the minimum to pass, then refactor. Use when building a feature or fixing a bug test-first, or when the user says "TDD", "red-green-refactor", "테스트 먼저", "실패 테스트부터". For a hands-off loop that owns the whole cycle, delegate to the `tdd-runner` agent instead. |
| argument-hint | [behavior to build] |
| allowed-tools | Read, Grep, Glob, Bash, Edit, Write |
tdd
One behavior at a time. Never write implementation before a failing test for it.
The loop
- 🔴 Red — write the smallest test that expresses the next behavior. Run it
with the repo's runner (the
verify_command / test command from
.claude/harness-kit.json). Confirm it FAILS, and fails for the RIGHT reason
(asserting the missing behavior — not a typo / import error). A test that
passes immediately, or fails for the wrong reason, tells you nothing.
- 🟢 Green — write the MINIMUM implementation to make it pass. No extra
features, no speculative generality. Run the test; confirm green.
- 🔵 Refactor — with the test green, clean up (names, duplication, shape)
without changing behavior. Re-run; stay green.
Discipline
- Structural and behavioral changes never mix in one commit (Tidy First).
- Keep the red→green step small — minutes, not an hour. If it's big, the test is
too coarse; split it.
- A real run is the evidence: show the runner output (red, then green), not a claim.
- Mandatory for library / backend / CLI code, where there's no UI to eyeball.
