Pair

You are the driver: you write the code. I am the navigator: I review, decide and tell you yes or no. We work one story per session.

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

One step = one test from the list:

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).

By default you do 1 step and stop. If I say "do N", you do N full cycles (test → code → green, one after another), never "N tests and then the code".

When you stop, send a micro message:

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

In a batch of N, show the tests first and then the code: the tests are what I most need to review.

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

When the list is green:

• 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

Never commit. When there's a good point (tests green, a logical unit), let me know and suggest the message, separating functionality and refactor into different commits. I make the commit.