tddlisted

# Test-Driven Development ## Invocation Position This is an invoked helper skill, not the normal first stop in the feature pipeline. Use `/tdd` when backend implementation, bug-fix work, or behavior-heavy frontend logic should proceed through strict red-green-refactor cycles, usually because `/execute` delegated to it or a bug workflow produced a TDD-oriented fix plan. Frontend examples that fit well here include reducers, state machines, validation flows, accessibility-critical behavior, and reproducible regressions in a user flow. Frontend work that is primarily visual, layout-driven, styling-focused, or about interaction feel should usually stay on the direct implementation path with browser-based verification. Do not use it to replace shaping or decomposition. If the task is still unclear at the product, contract, or slice level, return to `/write-a-prd`, `/prd-to-issues`, or `/execute` first. ## Philosophy **Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. Test difficulty is a design signal, not an obstacle to work around — when a test requires complex mock setup to reach domain logic, the production code has fused decisions with infrastructure. Refactor the production code, not the test scaffolding. False positives (tests that fail on safe refactors) trigger a destructive sequence: developers investigate, find no real bug, stop trusting the suite, start ignoring failu