test-driven-developmentlisted

# Test-Driven Development Use this skill when writing or changing behavior that should be protected by tests. ## Core Principle Write the test first. Watch it fail for the expected reason. Then write the smallest production change that makes it pass. If you did not observe the failure before implementation, you do not know whether the test proves the behavior you care about. ## When to Use This Skill Use this skill for: - new features - bug fixes - refactors that affect behavior - changes to validation, parsing, state transitions, or side effects Usually skip this only for: - throwaway prototypes - purely mechanical configuration edits - generated code If in doubt, prefer TDD. ## The Rule No production code for a new behavior without a failing test first. If code was already written for the behavior and no failing test came first, do not pretend it was TDD. Either backfill tests consciously or restart the change with an actual red-green-refactor cycle. ## Red-Green-Refactor ### 1. RED Write one focused failing test that demonstrates the next behavior you want. Good tests are: - focused on one behavior - named clearly - checking real behavior, not test scaffolding - as small as possible while still meaningful ### 2. VERIFY RED Run the focused test and confirm: - it fails - it fails for the expected reason - it fails because the behavior is missing or wrong, not because the test itself is broken If the test passes immediately, it is not proving the missing