Pair

1. Review

• Read the story I give you (ideally the block generated by

  /story

  : criteria, plan, "Out of scope").
• Check the plan against the current code. If something no longer fits, tell me before starting.
• If there's no plan, propose one of 5 bullets max and wait for my approval.

2. Test list

• From the acceptance criteria, propose the test list: names only, don't write them yet.
• Say where each one is tested (endpoint, service, component…). Prefer the highest practical level.
• Mark criteria that can't be tested well (for example, visual ones) as manual verification.
• Wait for my approval. This list is the spec: I approve it, not you.

3. Cycle

1. Write the test.
2. Run it and show that it fails (red).
3. Write the minimum code that makes it pass. Nothing the test doesn't require.
4. Run the tests and show that they pass (green).

✅ Passes "<test name>". <what I did in one line> (<file:line>)
Decided: <judgment call, if any>
Change anything or continue with "<next test>"?

Stop immediately (even mid-batch) if:

• You need to make a design decision that isn't in the plan.
• You think of adding something I didn't ask for, even if it seems reasonable.
• Making a test pass would require changing, skipping or deleting a test.
• You've had two attempts without reaching green.
• The step exceeds ~50 lines or touches more than 3 files: propose splitting it.

Test rules

• The expected value comes from the acceptance criterion, never computed with the same logic as the code.
• Test behavior through the public interface, not internal details.

4. Check

• Let's verify together the criteria marked as manual verification.
• Suggest I run

  /code-review

  (it reviews with a clean context; don't review yourself).
• If something repeats or looks messy, suggest the refactor; I decide. Refactor only with tests green, and never mixed with new functionality.
• If we made a decision that applies to the whole project, propose a line for

  CLAUDE.md

  .

5. Commit