Claude Code Bug-Fix Loop: Reproduce, Isolate, Fix, Verify
Corrects Claude Code's tendency to 'see an error and start randomly editing' into a disciplined 4-step debugging process: reliably reproduce the bug first, isolate the true root cause (not just the symptom) through minimization, write a regression test that fails, apply the smallest possible fix, then run the full test suite to prove it's fixed without breaking anything else.
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/bug-repro-isolate-fix-verify/SKILL.md and every future session can use it automatically.
mkdir -p ~/.claude/skills/bug-repro-isolate-fix-verify && mv ~/Downloads/SKILL.md ~/.claude/skills/bug-repro-isolate-fix-verify/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\bug-repro-isolate-fix-verify" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\bug-repro-isolate-fix-verify\SKILL.md"When to use: Any concrete bug report—an error, incorrect behavior, an intermittent failure. Especially good for cases where 'the AI already tried to fix this and made it messier,' because it forces reproduction and root-causing before any changes. Why it works: This mirrors Claude Code's real, widely-recommended 4-step debugging methodology—reproduce the problem → locate the root cause → apply a fix → verify against regressions. The core rule of community debugging skills is 'no fix without a failing test.' A regression test is called 'your seatbelt': it first proves the bug exists, then tells you exactly when it's truly fixed. Running the 'full' suite rather than a single test at the end matters because a narrow fix can still break something elsewhere. Tips: (1) Give {{CONTEXT}} as much detail as possible—stack trace, when it happens, what changed recently, how often it occurs—diagnostic accuracy scales directly with this. (2) Phase 2 suggests offloading heavy read-only investigation to an Explore subagent (a real Claude Code read-only exploration agent, via the Task/Agent tool), so that reading through lots of files doesn't pollute the main conversation's context; this is a genuine feature, but for small tasks where you don't want to split off work, the AI can investigate directly in the main thread just as well. (3) The rule 'minimal fix, don't casually touch unrelated code' is the key safeguard against the AI turning one bug into three. (4) For UI/environment issues that can't be covered by automated tests, at minimum require explicit manually-reproducible steps plus expected vs. actual behavior.
=== PHASE 1: REPRODUCE === Wrote failing test `cart total with 0-qty item`. Ran `npm test`: ✕ cart total ignores 0-qty lines — expected 100, got NaN Reproduced reliably. === PHASE 2: ISOLATE === Root cause: `lineTotal()` divides by qty to derive unit price, so qty=0 yields NaN which poisons the sum. Symptom is 'total shows NaN'; root cause is the unguarded division at cart.ts:42. (Candidates considered: rounding bug, currency parse — ruled out by the repro.) === PHASE 3: FIX === Guard qty=0 lines before the division at cart.ts:42 — narrowest change that removes the NaN source. === PHASE 4: VERIFY === Repro test now passes. Full suite `npm test`: 214 passing, 0 failing. Summary — Root cause: division by qty=0 at cart.ts:42. Fix: skip 0-qty lines. Regression test: 'cart total with 0-qty item' (committed). Noted but NOT touched: cart.ts also lacks negative-qty handling — separate issue.
[BUG_REPORT]Bug 描述:預期行為 vs 實際行為、觸發步驟、錯誤訊息
[CONTEXT]已知線索:完整 stack trace、發生時機與頻率、最近的相關改動或部署
[RUN_COMMAND]如何跑專案/測試的指令,例如 npm test、pytest、make test,AI 會用它驗證修復
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
You are fixing a bug. Follow this four-phase loop strictly: REPRODUCE → ISOLATE → FIX → VERIFY. The rule is: no fix without a failing test first, and the fix must be the narrowest change that addresses the ROOT CAUSE, not the symptom.
BUG REPORT:
{{BUG_REPORT}}
KNOWN CONTEXT (stack trace, when it happens, what changed recently, how often):
{{CONTEXT}}
HOW TO RUN THE PROJECT / TESTS:
{{RUN_COMMAND}}
=== PHASE 1: REPRODUCE ===
- First, reproduce the bug reliably. Determine the exact steps, inputs, or command that triggers it.
- If you can, write a failing automated test (or a minimal script/command) that demonstrates the bug. Run it and SHOW the actual failing output.
- If you genuinely cannot reproduce it, STOP and tell me precisely what information or access you are missing. Do not guess at a fix for a bug you cannot trigger.
=== PHASE 2: ISOLATE (root cause) ===
- Narrow down where the defect actually lives. Read the relevant code paths; trace the data/flow from the trigger to the failure. Minimize the reproduction to the smallest case that still fails.
- State the ROOT CAUSE in plain language: the specific line(s)/logic responsible and WHY it produces the observed behavior. Distinguish the root cause from the symptom.
- If recent changes are suspected, inspect the relevant history. List 1-3 candidate causes ranked by likelihood, then commit to the most likely one with your reasoning. If you are uncertain, say so rather than asserting.
- Heavy read-only investigation (searching, reading many files, tracing) is a good place to delegate to a read-only Explore subagent so it doesn't bloat this conversation — but the root-cause conclusion must come back here.
=== PHASE 3: FIX ===
- Make the SMALLEST change that fixes the root cause. Do not refactor unrelated code, do not 'improve' things nearby, do not widen scope. If you spot other issues, note them separately at the end — don't fix them now.
- Explain in one or two lines why this change addresses the root cause identified in Phase 2.
=== PHASE 4: VERIFY ===
- Run the failing test/repro from Phase 1 and SHOW it now passes.
- Run the FULL test suite (not just the one test) via {{RUN_COMMAND}} and SHOW the output, to prove you didn't break anything else.
- Keep the regression test in place permanently — it documents the bug and prevents it from coming back. Confirm it is committed alongside the fix.
Output discipline:
- Always paste REAL command output, never 'it passes now'. If a command can't be run in this environment, say so explicitly.
- End with a short summary: root cause (1 line), the fix (1 line), the regression test added, and any unrelated issues you noticed but deliberately did NOT touch.
- Do not declare the bug fixed unless Phase 1's repro passes AND the full suite is green.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.