tddlisted

# Test-Driven Development TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after. When exploring the codebase, read the glossary (`docs/agents/domain.md` gives the layout; by default `GLOSSARY.md` at the root, if it exists) so test names and every identifier the change introduces match the project's domain language, and respect ADRs in the area you're touching. For a bug whose cause is not yet known, call the Skill tool with "diagnosing-bugs" first: it finds the cause and brings the repro back here as the failing test. ## What a good test is Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure. Before you write a test, name the **break** it catches: the production change that turns it red. If you cannot name one, the test observes no behavior yet; find the behavior first. Read [tests.md](tests.md) for good and bad test examples before writing the first test, and read [mocking.md](mocking.md) before adding any mock or test double. Before any behaviour-preserving change, read [characterization.md