| name | tdd |
| description | Trigger: writing new production code, RED-GREEN-REFACTOR, failing test first. Enforces the Three Laws of TDD before any implementation. |
Trigger Conditions
Load this skill before writing ANY production code change — new feature,
bug fix, or refactor. If there is no failing test yet, write one first; do
not skip straight to implementation.
Practice: The Three Laws (PRD §2.1)
- You may not write production code unless it is to make a failing
test pass.
- You may not write more of a test than is sufficient to fail
(compilation/import failures count as a valid failure).
- You may not write more production code than is sufficient to pass
the currently failing test.
Cycle: RED → GREEN → REFACTOR, always in that order, never skipped:
- RED — write the smallest failing test that names the next behavior.
It MUST fail for the right reason (missing behavior, not a typo).
- GREEN — write the minimum production code to make that one test pass.
Resist adding anything the test doesn't demand yet.
- REFACTOR — with the test green, clean up duplication and naming, in
production code and test code alike. Re-run the test after every
refactor step; it must stay green.
Sad-path scenarios (invalid input, boundary conditions, partial failures,
contract violations) are first-class RED cases — not an afterthought once
the happy path passes.
Worked Example
Adding input validation to a Withdraw(amount int) error method that must
reject a negative amount:
- RED: write
TestWithdraw_RejectsNegativeAmount asserting
Withdraw(-10) returns a non-nil error and the balance is unchanged.
Run it — it fails because Withdraw currently accepts any amount.
- GREEN: add the minimal guard —
if amount < 0 { return ErrNegativeAmount } — nothing else. Run the
test again — it passes.
- REFACTOR: extract the guard into a small
validateAmount helper if
a second validation rule is about to land, rename ErrNegativeAmount
for clarity if needed. Re-run the full test suite — still green.
Only after this cycle completes does the next behavior (e.g. rejecting an
amount above the available balance) get its own RED step.