Agree where behavior will be observed, then alternate one failing test with the smallest implementation that passes it.
Install and prepare
Run the following in your project terminal, then use the prompt below in Claude Code. This installs editable, project-scoped skill files.
npx skills@latest add mattpocock/skills --skill tdd --skill codebase-design --agent claude-code
For Codex, replace claude-code with codex in the command and /tdd with $tdd in the prompt. With the complete Claude Code plugin, select /mattpocock-skills:tdd instead; avoid installing the same skills twice.
Prepare a working test command and one defined behavior. Install codebase-design alongside this skill for interface and testing-boundary discussions, and provide existing glossary and decision records.
Your first task
Adapt the scenario and paths to your project, then enter this in the agent conversation:
/tdd
Add a coupon that takes 10 off a cart subtotal of at least 100; amounts are stored in cents. Explain candidate test boundaries and what each covers, wait for my choice, then implement one failing test at a time.
Work through the task
Choose an observable boundary
A cart interface can expose the discount, while a checkout interface can expose the final payable amount. Ask what integration mistakes the first would miss and what setup the second requires before choosing. The boundary determines which failures the tests can actually detect.
Start with an independent expected result
Start with a worked example: a subtotal of 10,000 cents should receive a 1,000-cent discount. The expected value comes from the rule, not a copy of the production calculation inside the test. Run the failing test before adding enough implementation to pass it.
Add the next meaningful behavior
Next consider real requirements such as a subtotal just below the threshold, repeated redemption and other discounts. Add them one at a time. Avoid drafting an entire imagined test suite or testing every private helper. Renaming an internal function should not break behavior-based assertions.
Check the result
Check that each test genuinely failed first, expected values came from independent rules and mocks sit at external dependencies. The current workflow leaves refactoring to the review stage, so schedule a review after the behavior is stable.
Common questions
Why ask about boundaries first? The workflow requires this decision; ask what each option catches and misses.
Why no automatic refactoring? The current instructions use a red → green loop and leave refactoring to review.
Should I use it for a configuration line? Prefer behaviors with observable inputs, outputs and independent acceptance criteria.
Take a shipping rule from red to green
Unlike a coupon example, start with free shipping at a cart threshold. Ask: “Use tdd at the public order-calculation boundary. A 9,900-cent subtotal pays shipping and a 10,000-cent subtotal does not. Propose the test seam and wait for my agreement. Write one test that fails because the behavior is missing, then the minimum implementation.” Derive the expected amounts from the product rule, not by calling production calculation code inside the test.
After the first green result, add decided edge cases such as post-discount totals, free items, or currencies. If the agent writes ten tests at once and all are green, ask whether any exposed new behavior. If an internal rename breaks the suite, the tests are too close to implementation. When no useful public seam exists, discuss the boundary instead of mocking your own modules simply to produce a test.
Include boundary inputs in test decisions
When agreeing on test seams, do more than write “critical path.” List boundary inputs that could change the decision, such as a zero amount, repeated request, missing permission, or concurrent update. Show that the test fails against the broken behavior before trusting green. An external evaluation of this skill reported false greens from untested edge cases. Its public issue does not include a reproducible dataset, so use it as a prompt to choose better examples, not as a claimed failure rate.