Claude Code TDD Loop: Red, Green, Refactor Done Right
Forces Claude Code through a strict red→green→refactor cycle: for every behavior, first write a test that fails (red) and actually run it to prove the failure, then write the minimal implementation that just makes it pass (green), and finally refactor under the safety of the passing tests. Cures the AI's old habit of jumping straight to the happy path, skipping edge cases, and faking test coverage.
We are building this feature using strict Test-Driven Development. Follow the Red-Green-Refactor cycle and do NOT skip steps. The discipline is non-negotiable: no production code gets written before there is a failing test that demands it.
FEATURE / BEHAVIOR TO BUILD:
{{FEATURE}}
TEST FRAMEWORK & COMMAND:
- Framework / runner: {{TEST_FRAMEWORK}}
- Command to run tests: {{TEST_COMMAND}}
Process for EACH behavior (work one behavior at a time, smallest first):
=== RED ===
1. Write exactly ONE focused test for the next small behavior, including the relevant edge cases for that behavior (empty input, boundary values, error paths) where they belong. Do not write the implementation yet.
2. Run `{{TEST_COMMAND}}` and SHOW me the actual output. The new test MUST fail, and it must fail for the RIGHT reason (asserting the missing behavior — not failing due to an import error, typo, or syntax mistake). If it fails for the wrong reason, fix the test and re-run before continuing.
3. State in one line: what behavior this test pins down.
=== GREEN ===
4. Write the MINIMUM production code needed to make that test pass. No extra features, no speculative abstraction, no handling of cases no test covers yet.
5. Run `{{TEST_COMMAND}}` again and SHOW the output. The target test must now pass AND every previously passing test must still pass. If anything else broke, fix it before moving on.
=== REFACTOR ===
6. With the tests green, look for cleanup: duplication, unclear names, dead code, awkward structure. Refactor WITHOUT changing behavior. Run `{{TEST_COMMAND}}` once more and SHOW output to prove everything is still green. If there is nothing worth refactoring, say so explicitly and move on.
Then repeat the cycle for the next behavior.
Hard rules:
- Never write production code in the same step as writing a test.
- Never edit a test just to make a failing implementation pass — if a test is genuinely wrong, say WHY out loud first, then fix the test, then re-run RED.
- Do not stub out tests to always pass, and do not delete assertions to get green. That is cheating and counts as failure.
- Always paste the REAL test runner output, never a summary like 'tests pass'. If a command cannot be run here, say so explicitly instead of pretending.
- Stop after every full cycle and give me a one-line status: which behavior is now done and what the next behavior will be.
Start with RED for the smallest meaningful behavior.See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.claude/skills/tdd-red-green-refactor-loop/SKILL.md and every future session can use it automatically.
mkdir -p ~/.claude/skills/tdd-red-green-refactor-loop && mv ~/Downloads/SKILL.md ~/.claude/skills/tdd-red-green-refactor-loop/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\tdd-red-green-refactor-loop" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\tdd-red-green-refactor-loop\SKILL.md"When to use: Writing a new function/class/module where you want genuinely trustworthy test coverage, not a pile of fake tests bolted on afterward. Also applies to bug fixes (write a failing test that reproduces the bug first). Why it works: TDD is one of the workflows Anthropic officially recommends for Claude Code. Claude Code has a structural weakness—it defaults to implementation-first, writes only the happy path, and ignores edge cases; when TDD is forced within the same context, implementation logic tends to 'leak' into the tests (context pollution). This prompt makes the discipline explicit through three clear gates (see the test fail first, write the minimal implementation, verify again after refactoring) plus hard rules like 'paste the actual test runner output' and 'never modify a test to accommodate the implementation'—turning TDD into default behavior instead of something that depends on willpower. Tips: (1) Fill in {{TEST_COMMAND}} correctly, or the AI has nothing to run and no output to paste. (2) The single most critical step is confirming, during the RED phase, that 'the test failed for the right reason'—a lot of AI's fake TDD is actually a broken import causing the failure, not a genuine behavioral check. (3) For stricter enforcement, you can pair this with a Claude Code Hook (PreToolUse) that blocks writes to implementation files when there's no corresponding failing test—but that requires separate setup and this prompt doesn't depend on it. (4) Do one behavior at a time; don't get greedy and ask it to write ten tests in one go.
=== RED === Wrote 1 test: `slugify('') returns ''` (empty input edge case). Ran `npm test`: FAIL src/slugify.test.ts ✕ slugify('') returns '' (2 ms) ReferenceError: slugify is not defined That is the RIGHT kind of failure (function doesn't exist yet). Behavior pinned: empty string in → empty string out. === GREEN === Added minimal `export function slugify(s: string){ return s.trim().toLowerCase().replace(/\s+/g,'-'); }` Ran `npm test`: PASS src/slugify.test.ts (1 passing) === REFACTOR === Nothing meaningful to refactor at this size — moving on. Status: done = empty-input handling. Next behavior = collapse multiple spaces into one dash.
[FEATURE]要實作的功能或行為描述；可列出你想到的邊界/錯誤情境讓 AI 涵蓋
[TEST_FRAMEWORK]測試框架/執行器，例如 Vitest、Jest、pytest、Go test、JUnit
[TEST_COMMAND]實際跑測試的指令，例如 npm test、pytest -q、go test ./...，AI 會用它跑並貼輸出
填下面的欄位，上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
We are building this feature using strict Test-Driven Development. Follow the Red-Green-Refactor cycle and do NOT skip steps. The discipline is non-negotiable: no production code gets written before there is a failing test that demands it.
FEATURE / BEHAVIOR TO BUILD:
{{FEATURE}}
TEST FRAMEWORK & COMMAND:
- Framework / runner: {{TEST_FRAMEWORK}}
- Command to run tests: {{TEST_COMMAND}}
Process for EACH behavior (work one behavior at a time, smallest first):
=== RED ===
1. Write exactly ONE focused test for the next small behavior, including the relevant edge cases for that behavior (empty input, boundary values, error paths) where they belong. Do not write the implementation yet.
2. Run `{{TEST_COMMAND}}` and SHOW me the actual output. The new test MUST fail, and it must fail for the RIGHT reason (asserting the missing behavior — not failing due to an import error, typo, or syntax mistake). If it fails for the wrong reason, fix the test and re-run before continuing.
3. State in one line: what behavior this test pins down.
=== GREEN ===
4. Write the MINIMUM production code needed to make that test pass. No extra features, no speculative abstraction, no handling of cases no test covers yet.
5. Run `{{TEST_COMMAND}}` again and SHOW the output. The target test must now pass AND every previously passing test must still pass. If anything else broke, fix it before moving on.
=== REFACTOR ===
6. With the tests green, look for cleanup: duplication, unclear names, dead code, awkward structure. Refactor WITHOUT changing behavior. Run `{{TEST_COMMAND}}` once more and SHOW output to prove everything is still green. If there is nothing worth refactoring, say so explicitly and move on.
Then repeat the cycle for the next behavior.
Hard rules:
- Never write production code in the same step as writing a test.
- Never edit a test just to make a failing implementation pass — if a test is genuinely wrong, say WHY out loud first, then fix the test, then re-run RED.
- Do not stub out tests to always pass, and do not delete assertions to get green. That is cheating and counts as failure.
- Always paste the REAL test runner output, never a summary like 'tests pass'. If a command cannot be run here, say so explicitly instead of pretending.
- Stop after every full cycle and give me a one-line status: which behavior is now done and what the next behavior will be.
Start with RED for the smallest meaningful behavior.Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.