Five real prompts for the most common bug-fixing situations — copy, fill in the bracketed part with your actual detail, and use as a starting point rather than staring at a blank prompt.
Prompt 1
A Bug You Can Reproduce
Here's a bug: [describe exactly what you did and what happened instead of what you expected]. Find the root cause before proposing a fix — show me what you find first.
When to use it: you have clear repro steps but haven't looked at the code yet.
Prompt 2
A Bug You Can't Reproduce Reliably
This happens intermittently: [describe the symptom]. Before proposing a fix, help me figure out how to reliably reproduce it first — what conditions or inputs would trigger it consistently?
When to use it: an intermittent issue, before wasting a session guessing at fixes for something you can't confirm is actually fixed.
Prompt 3
A Failing Test
This test is failing: [paste the test name and the error output]. Explain why it's failing before changing anything, then propose the smallest fix that makes it pass without breaking other tests.
When to use it: any red test in CI or locally — this forces an explanation step before a fix, which catches the "just make the test pass" trap.
Prompt 4
A Regression After a Recent Change
[Feature or page] broke after a recent change. Here's what's happening now: [describe]. Check what changed recently that could explain this before assuming it's something else entirely.
When to use it: something that used to work stopped working — grounds the search in what actually changed instead of a fresh guess.
Prompt 5
A Fix You Want Double-Checked
Here's the fix you just proposed for [bug]. Before I approve it: does this address the actual root cause, or just the symptom I described? What's the smallest case where this fix could still fail?
When to use it: right before approving a diff for anything that isn't trivial — a genuinely useful habit, not just a prompt for hard bugs.
New to Claude Code? Start With the Fundamentals
The free guide covers reading a diff and reviewing changes safely — the habit that makes these prompts actually useful.
Do these prompts work for any programming language?
Yes — they're written to describe the situation and the desired review process, not language-specific syntax, so they apply regardless of the stack.
Should I paste these exactly as written?
They're a solid starting point — add the actual file, error message, or symptom in place of the bracketed placeholder for a sharper first response.
Why include a prompt for a bug I can't reproduce?
Because it's one of the most common real situations, and the instinct to guess at fixes without reproducing first is a common source of wasted sessions.