Claude Code Prompts for Debugging

The failure mode of AI-assisted debugging is obvious: you paste an error, the model confidently patches a symptom, and the bug moves somewhere else. These prompts prevent that. Each one forces Claude Code through a phase structure — reproduce, hypothesize, experiment, then fix — so the fix lands on the actual cause. The "Explain-Then-Fix Contract" is worth setting once at the start of every debugging session; the rest are situational.

Act as my senior debugging partner. I will paste an error message and the relevant code. Do NOT suggest a fix yet. Instead: (1) restate the failure precisely in one sentence; (2) list the top 3 hypotheses for the root cause, ranked by likelihood, each with a one-line reason; (3) for each hypothesis, propose the cheapest possible experiment that would confirm or kill it. Wait for my experiment results before we move to fixing.

Below is a bug report and the suspected module. Produce a minimal standalone reproduction: the smallest possible file(s) and steps that trigger the bug with no external dependencies. If you cannot reproduce it logically, tell me exactly what information is missing before writing any code.

Here are application logs from a failed session. Do a structured triage: (1) timeline of significant events; (2) the first anomaly in the timeline and why it is anomalous; (3) which of ERROR/WARN lines are symptoms vs. causes; (4) the single most likely root cause and what log line I should add next to prove it. Keep each section under 5 bullets.

This feature worked before and is broken now. Walk a git-bisect-style investigation with me: (1) ask me for the last known-good commit and the first known-bad commit (or help me find them); (2) list the commits in that range grouped by subsystem; (3) identify the 3 most suspicious commits and why; (4) propose the bisect test we should run at each step. Do not modify code until we have isolated the commit.

For every bug I give you, follow this contract: PHASE 1 — explain the bug mechanism in plain language, including why the code was ever written this way (what assumption broke). PHASE 2 — propose at least two fixes: a minimal safe patch and a proper structural fix, with trade-offs. PHASE 3 — only after I choose, implement it, and add one regression test that fails on the old code. Never skip Phase 1 even if the fix seems obvious.

The bug only appears intermittently. Assume a concurrency cause until proven otherwise. (1) Map every async boundary in the suspect flow (awaits, timers, event handlers, network callbacks) in order; (2) mark each pair of operations whose order is NOT guaranteed; (3) for each unguaranteed pair, describe the exact interleaving that would produce the symptom; (4) suggest the minimal logging or assertion that would catch the interleaving in the act.