test-driven-developmentlisted

# Test-Driven Development Use this skill before implementation work. It governs each small implementation chunk until the change is complete. ## Core Rule Write the test first. Watch it fail for the expected reason. Write the smallest code that makes it pass. Refactor only after green. ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` If implementation code was written before the test, delete that implementation and restart from the test. Do not keep it as reference material. ## When To Use Use for: - New features. - Bug fixes. - Refactoring that can change behavior. - Any user-visible behavior change. Exceptions require an explicit user decision: - Throwaway prototypes. - Generated code. - Pure configuration changes. ## Outer and Inner Loops TDD runs as two nested feedback loops, not one. The outer loop is acceptance-test driven. For each slice of behavior, write a failing acceptance test that exercises the feature from outside the unit boundary. Watch it fail for the right reason. Then drive inner cycles until that acceptance test goes green. The inner loop is red-green-refactor as described in the next section. It runs many times inside one outer-loop iteration: one inner cycle per unit-level behavior needed to satisfy the acceptance test. When the acceptance test passes, refactor at the slice boundary if useful, then start the outer loop again with the next slice. "Acceptance test" here means any test that exercises the slice from outside the unit bo