| name | tdd |
| description | Apply test-driven development with small, behavior-focused feedback loops. Use when the user asks to build or fix something test-first, mentions red-green-refactor, or wants integration tests. |
Test-Driven Development
Use small red → green → refactor cycles when a test-first feedback loop is
practical. Treat repository conventions, existing tests, and the requested
behavior as authoritative.
Loop
- Identify one observable behavior and the seam through which callers see it.
- Write the smallest meaningful test and confirm that it fails for the expected
reason.
- Add only enough implementation to make the test pass.
- Refactor when doing so improves clarity or design; keep the suite green.
- Repeat with the next vertical slice.
Infer seams from public interfaces and nearby tests. Ask the user only when
choosing a seam would materially change the product contract, cost, or scope.
Judgment
- Prefer behavior-focused tests that survive internal refactors.
- Derive expected results from a specification, worked example, or other
independent source rather than duplicating the implementation.
- Mock external or nondeterministic boundaries when useful; follow established
repository patterns where they provide an adequate feedback loop.
- Prefer vertical slices over a speculative batch of tests. Batch closely
related mechanical cases when that is clearer and faster.
- If a failing-first cycle is impractical—for example in legacy code with no
usable seam—state the limitation and establish the nearest reliable
characterization or integration test.
Read tests.md for examples and mocking.md when deciding
whether and where to use test doubles.
