Ten Claude Code prompt templates for debugging: stack-trace autopsy, flaky tests, memory leaks, performance regressions, and the bisect-without-bisect prompt. Copy and paste.
Debugging prompts work best when they specify the diagnostic approach, not just the symptom. "Fix this bug" gets you a guess. "Trace execution frame by frame, show variable values, identify root cause" gets you a diagnosis.
Here is a stack trace and the failing input:
[PASTE FULL TRACE]
[PASTE INPUT or test command]
Trace the exact execution path from entry point to the throwing line.
At each frame, show:
- file:line
- the value of the variable that caused the next frame to be invoked
End with:
- Root cause in 1 sentence
- Minimal patch (unified diff)
- Why your current tests didn't catch this (1 sentence)This worked in commit [GOOD_HASH] and broke in [BAD_HASH] or later.
Read the diff between them: git diff [GOOD_HASH]..[BAD_HASH]
For each changed hunk:
- Could it plausibly cause [SYMPTOM]? (yes/no/maybe + 1-sentence why)
Output: ranked list of suspect hunks (most likely first).
Do NOT propose a fix yet — I want to verify the diagnosis manually.This is faster than `git bisect` when there are 5–20 commits between known-good and known-bad and the bug is non-deterministic (so bisect's "does this commit have the bug?" answer is unreliable).
Test [TEST_NAME] in [FILE] fails roughly 1 in 5 runs.
Without running it yet, list the top 5 likely causes:
- Timing (sleeps, awaits without sync, retries on timeout)
- Shared state (module globals, singletons, test registries)
- IO leakage (fs/network/socket not cleaned up between tests)
- Randomness (uncontrolled seeds, time.now, uuid)
- Test ordering (passes alone, fails with siblings)
For each cause:
- exact code reading that confirms or rules out (file:line)
- deterministic fix
- cost of the fix (lines, perf impact)
Rank by likelihood given THIS test's contents. Don't generic-list.This process grows from [X]MB to [Y]MB over [DURATION].
The leaking workload: [DESCRIBE].
Without running profiling yet, scan [FILES] for the top 5 leak sources:
1. Caches without eviction
2. Closures retaining large args
3. Long-lived listeners/subscribers never removed
4. Module-level mutable collections that grow
5. Streams/generators never closed (open file handles)
For each: file:line, what accumulates, eviction or cleanup strategy.
Then suggest ONE small instrumentation change (logging or a metric) that
would confirm which source is dominant. I'll add that, run, and report back.P99 latency on [ENDPOINT] doubled between deploys [A] and [B].
Diff between deploys: git diff [A]..[B]
Scan for performance regressions:
- New synchronous calls in a hot path
- N+1 query patterns (loop with DB call inside)
- New JSON serialization of large objects
- Lock contention (new mutex, expanded critical section)
- Cache invalidation that now misses on every request
- Algorithmic complexity changes (was O(n), now O(n²))
Per finding: file:line, why it's slow, expected impact, minimal fix.
Rank by likelihood of being the dominant cause.This works locally but fails in [staging/prod/CI] with [ERROR].
Without code changes yet, list the environment differences that could
matter:
- OS/arch (linux/amd64 vs darwin/arm64?)
- Library versions (lockfile present and committed?)
- File paths (case sensitivity? path separators?)
- Environment variables present/missing
- Network reachability (egress restrictions?)
- Timezone (UTC vs local?)
- Permissions (write to /tmp vs /var?)
- Resource limits (RAM, file descriptors, processes)
For each plausible cause: a one-command diagnostic to run in the failing
environment. Output them as a checklist I can run.Suspected race condition: [DESCRIBE SYMPTOM].
Suspect file: [FILE]
Identify the shared mutable state in this file (file:line list).
For each:
- What threads/coroutines/processes access it?
- Is there a lock? Is the lock held during all reads AND writes?
- Could a context switch between read-modify-write produce the symptom?
Then write a deterministic reproducer:
- Use threading or asyncio to interleave operations
- Use barriers or sleeps to force the bad ordering
- Run 100 iterations; expect >50% failure with the bug present
If the reproducer doesn't catch it, the symptom is likely not a race — say so.Query in [FILE:LINE] returns wrong rows (expected [X], got [Y]).
Step 1: Reproduce the issue. Run the query against the test DB with
captured fixtures. Show me input and output.
Step 2: Walk through the SQL logic:
- Each JOIN: what's the join key? does it match expected cardinality?
- Each WHERE clause: does it eliminate rows you expect to keep?
- Each GROUP BY: are there ungrouped non-aggregate columns?
- Any LIMIT/OFFSET that could hide rows?
Step 3: Show the minimal SQL fix and the corresponding ORM change.
Run the test again to confirm.Production logs from [TIMESTAMP_RANGE] show [PATTERN].
Paste relevant log lines: [PASTE]
Extract:
- Sequence of events (timestamped)
- Which service/component each line came from
- The "first cause" line (earliest anomaly)
- The "user-visible failure" line (what surfaced as the incident)
Hypothesize 2-3 root causes consistent with this sequence.
For each: the code path responsible, and a follow-up log statement
that would have made the cause unambiguous (so we add it for next time).I have a bug in [FILE] reproduced by the failing test [TEST_NAME].
The current test is 80 lines. Help me extract a minimal reproducer:
- Strip setup unrelated to the bug
- Use the simplest possible input that still triggers
- Remove any assertions other than the one that fails on the bug
- The reproducer must fit in under 20 lines
- Include the exact failing assertion
Output as a standalone runnable script (no test framework).Minimal reproducers are gold for filing upstream bugs and for asking for help on forums. They're also a forcing function — if you can't extract one, you don't fully understand the bug yet.
These 10 prompts are the debugging chapter of the Claude Code Power Prompts PDF. The full pack covers six categories: review, debugging, testing, architecture, docs, devops. £3 launch price tonight (first 10 buyers), then £5. 8-page PDF. Paste into CLAUDE.md, debug faster.