tdd-workflow

Drive a feature with a disciplined test-driven development loop — red, green, refactor. Use when implementing a feature or fixing a bug and you want tests to lead, or when asked to 'do this with TDD' / write the test first. Produces a step-by-step red-green-refactor plan: the failing test to write first, the minimal code to pass it, and the refactor — one small cycle at a time.

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

tdd-workflow

Start a fresh conversation. Replace the highlighted placeholders.

Use tdd-workflow to produce the first disciplined red-green-refactor cycle for [observable behavior and edge cases] in [stack and test location], focused on [function/module/endpoint and collaborators].

Required inputs

[observable behavior and edge cases]
[stack and test location]
[function/module/endpoint and collaborators]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: tdd-workflowdescription: "Drive a feature with a disciplined test-driven development loop — red, green, refactor. Use when implementing a feature or fixing a bug and you want tests to lead, or when asked to 'do this with TDD' / write the test first. Produces a step-by-step red-green-refactor plan: the failing test to write first, the minimal code to pass it, and the refactor — one small cycle at a time."

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.

Example Trigger Phrases

"Implementing a feature."
"Fix a bug and you want tests to lead."
"'do this with TDD' / write the test first."