tdd-workflow

TDD Workflow Skill

The failure mode of AI-assisted coding is writing a pile of code, then maybe some tests that rubber-stamp it.

TDD inverts that: the test defines the behavior first, the code does the minimum to pass, then you refactor

safely. This skill runs that loop with discipline — one small red-green-refactor cycle at a time, never

jumping ahead to untested code.

Required Inputs

Ask for these only if they aren't already provided:

• The behavior to build — the feature/bugfix, stated as observable behavior (input → expected output).
• The stack — language, test framework/runner, where tests live.
• The seam — the function/module/endpoint under test, and any collaborators to fake/mock.
• Edge cases — the conditions that matter (errors, empty, boundaries).

Output Format

TDD plan: [behavior]

Behavior list — the observable cases to drive out, ordered simplest → richest (happy path first, then edges/errors). Each becomes one cycle.

Then, for each cycle (do them one at a time, smallest first):

🔴 Red — the single failing test to write now (the actual test code), and why it fails (the behavior doesn't exist yet). One assertion of one behavior.

🟢 Green — the minimal code to make exactly that test pass — even if it's obvious/ugly. No extra features, no speculative generality.

🔵 Refactor — what to clean up now that it's green (naming, duplication, structure) with the test as the safety net. Skip if nothing's needed.

Run — the command to run the test(s) and what "passing" looks like.

End with: the next cycle's red test, and a note to commit at each green.

Quality Checks

• [ ] Behaviors are listed and ordered simplest-first; each cycle tests ONE behavior
• [ ] The red step writes a genuinely failing test before any implementation
• [ ] The green step is the minimal code to pass — no untested extra functionality
• [ ] Refactoring happens only on green, with tests as the safety net
• [ ] Edge/error cases each get their own cycle, not bolted onto the happy path

Anti-Patterns

• [ ] Do not write the implementation first and the test after — that's not TDD, it's rationalization
• [ ] Do not write five tests then all the code — one red→green→refactor cycle at a time
• [ ] Do not over-build in green — only enough to pass the current test
• [ ] Do not test implementation details — test observable behavior so refactors don't break tests
• [ ] Do not skip the refactor step when there's obvious duplication or a bad name

Based On

Test-Driven Development (Kent Beck): red → green → refactor, triangulation, one behavior per cycle.