Implement using strict red-green-refactor TDD — one test at a time.
Work through the acceptance criteria test bullets sequentially. For each test bullet:
- Red. Write exactly ONE test method for the current bullet. Run it. It MUST fail. If it passes immediately, the test is not testing new behaviour — either the assertion is wrong or the code path already exists. Fix the test or skip to the next bullet.
- Green. Write the minimum production code to make that one test pass. Run the test again to confirm green. Do not write code for any other test bullet yet.
- Refactor. If the code you just wrote can be cleaned up without changing behaviour, do it now. Run the test again to confirm it still passes.
- Move on. Only after the current test is green, proceed to the next acceptance criteria bullet and repeat from step 1.
This means you will have multiple red-green-refactor cycles per task — one per test bullet. You must NEVER:
- Write multiple test methods before implementing any production code
- Write all tests first and then make them pass in bulk
- Skip the red step — every test must be observed failing before you write production code for it
- Write production code that satisfies a future test bullet before that bullet's test exists
For integration/feature tests where the failure progresses through stages (e.g., "route not found" → "controller not found" → "method not found" → passing), re-run the test after each incremental change to confirm the failure message advances. This progressive-failure cycle is the green step for that single test.
Before writing any tests, read ~/.claude/skills/_shared/testing-rules.md and apply its rules. If an acceptance criteria bullet asks for a test that merely tests the language or framework, skip it and move to the next bullet.
Keep changes scoped tightly to what the task requires — do not refactor surrounding code, add unrelated features, or fix unrelated issues.
