---
name: test-driven-development
description: ALWAYS use this when implementing or changing behavior that can be defined by a failing test first, including bug fixes, parsing, validation, business rules, state transitions, and regression-prone logic.
Test-Driven Development
Selective Reading Rule
Start with:
references/usage-routing.md
references/quality-checklist.md
Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.
Selective Reading Rule
Start with:
references/senior-master-standard.md
references/red-green-refactor-checklist.md
references/test-shape-heuristics.md
Read references/test-shape-heuristics.md before writing the first test when the system has lots of mocking, async behavior, or awkward setup.
Purpose
Use failing tests to define behavior before implementation makes the answer look obvious.
Use This Skill When
- a bug fix can be reproduced in a test
- a new rule, parser, validation, or state transition needs precision
- refactoring could quietly change behavior
- confidence matters more than raw typing speed
Core Law
No production logic before a failing proof.
Red-Green-Refactor
- Red.
- write the smallest realistic test that demonstrates the missing behavior
- run it and confirm it fails for the right reason
- Green.
- implement the smallest change that makes the test pass
- Refactor.
- improve names, structure, and duplication while keeping the suite green
Rules
- Keep each test focused on one behavior.
- Prefer real behavior over mock choreography.
- Run the focused proof first, then widen verification only as needed.
- If a test passes immediately, it did not prove the change you think it proved.
When Not To Force It
- visual exploration where expectations are not yet stable
- disposable spikes that are intentionally throwaway
- tasks blocked by unresolved architecture decisions
Deliverable
Report:
- the failing proof you added or tightened
- the implementation change
- the focused test result
- the broader regression checks you ran
1---2name: test-driven-development3description: ---4---5---6name: test-driven-development7description: ALWAYS use this when implementing or changing behavior that can be defined by a failing test first, including bug fixes, parsing, validation, business rules, state transitions, and regression-prone logic.8---910# Test-Driven Development1112## Selective Reading Rule1314Start with:1516- `references/usage-routing.md`17- `references/quality-checklist.md`1819Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.2021## Selective Reading Rule2223Start with:2425- `references/senior-master-standard.md`26- `references/red-green-refactor-checklist.md`27- `references/test-shape-heuristics.md`2829Read `references/test-shape-heuristics.md` before writing the first test when the system has lots of mocking, async behavior, or awkward setup.3031## Purpose3233Use failing tests to define behavior before implementation makes the answer look obvious.3435## Use This Skill When3637- a bug fix can be reproduced in a test38- a new rule, parser, validation, or state transition needs precision39- refactoring could quietly change behavior40- confidence matters more than raw typing speed4142## Core Law4344No production logic before a failing proof.4546## Red-Green-Refactor47481. Red.49 - write the smallest realistic test that demonstrates the missing behavior50 - run it and confirm it fails for the right reason512. Green.52 - implement the smallest change that makes the test pass533. Refactor.54 - improve names, structure, and duplication while keeping the suite green5556## Rules5758- Keep each test focused on one behavior.59- Prefer real behavior over mock choreography.60- Run the focused proof first, then widen verification only as needed.61- If a test passes immediately, it did not prove the change you think it proved.6263## When Not To Force It6465- visual exploration where expectations are not yet stable66- disposable spikes that are intentionally throwaway67- tasks blocked by unresolved architecture decisions6869## Deliverable7071Report:7273- the failing proof you added or tightened74- the implementation change75- the focused test result76- the broader regression checks you ran