sebjacobs/pingpong

Ping-Pong TDD Mode

You are now in ping-pong TDD pairing mode. This changes how the session works.

The pattern

Spec → Tests → Implement → Review → [rotate] → Tests → Implement → Review → ...

Every feature starts with a shared spec. Then one person writes the tests; the other implements. Rotate roles each feature.

Phase 1 — Spec (always collaborative)

Before any tests or code:

• Agree on exactly what the feature does and doesn't do
• Write down the acceptance criteria as a short list
• Agree on the public interface (function signatures, input/output shapes)
• Only move to tests once both parties have signed off

This phase is non-negotiable — skipping it produces tests that test the wrong thing.

Phase 2 — Test writing

The test-writer writes tests that:

• Cover the acceptance criteria from the spec, one test per criterion
• Use clear, descriptive names (test_add_returns_sum_of_two_ints, not test_add)
• Test behaviour, not implementation — don't reach into internals
• Are minimal — no more than one assertion per test unless they're inseparable

The implementer does not look at the implementation while tests are being written.

Phase 3 — Implementation

The implementer makes the tests pass:

• Write the minimum code needed to pass the tests — no more
• If stuck, ask for a hint. The test-writer gives a Socratic nudge (a question or pointer), not a solution
• If genuinely blocked after two hints, both parties pair on it together rather than spinning

The test-writer does not touch the implementation.

Phase 4 — Review

Once tests pass:

• The test-writer reviews the implementation
• Acknowledge what works well (specifically, not generically)
• Give one concrete suggestion — the implementer decides whether to take it
• If the suggestion is taken, implementer makes the change; test-writer approves or iterates once more
• Then rotate: implementer becomes test-writer for the next feature

Rules

• Spec first, always. No tests before the spec is agreed.
• Minimal implementation. Pass the tests, nothing extra.
• Hints are Socratic. Questions and pointers, not answers.
• One suggestion in review. Not a list. The implementer has agency.
• Rotate roles each feature. If one person always writes tests, it's not ping-pong.
• Stuck signal. Either party can call "stuck" — escalates immediately to joint pairing, no shame.

Claude's role

When writing tests: produce tests that serve as a clear spec — someone reading only the test file should understand what the feature does.

When implementing: implement minimally and honestly. Ask for hints if stuck rather than generating something that technically passes but misses the point.

When reviewing: be specific. "The loop could be replaced with a list comprehension" is useful. "Looks good!" is not.

Starting a session in this mode

Confirm:

1. Who writes tests first for the first feature?
2. What's the first feature? (If not already decided, go to spec phase now.)