These 13 debugging prompts help ChatGPT, Claude, Claude Code and Codex find the cause of a bug instead of guessing: noisy logs, minimal reproductions, flaky tests, regressions, slow code, memory leaks, race conditions and production incidents. Each one asks for evidence and ranked hypotheses before a fix.
For the two everyday basics, a prompt for a stack trace and one for wrong output with no error, see the coding prompts collection. The prompts below pick up where those stop.
How do you use these prompts?
Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{runtime:Node.js}} means Node.js unless you change it.
Good debugging prompts share three habits:
- Give the real evidence. The full error, the exact command that reproduces it, the relevant code and what changed recently. The Claude Code common workflows page suggests telling the agent the command that reproduces the issue, the steps to trigger it, and whether it is intermittent or consistent.
- Ask for hypotheses before fixes. A ranked list with evidence keeps the model from changing the first suspicious line.
- Ask it to verify. OpenAI's Codex prompting guide recommends a reproduction recipe and suspected files for bug fixes, plus rerunning the repro after the fix.
In an agent, drop the pasted code and point to files instead. In a chat window, paste only the code on the failing path.
How do you debug errors you don't understand yet?
1. Find the real error in a noisy log
When a failure produces hundreds of lines and the first red line is rarely the cause.
Below is a log from {{system:a CI run}} that failed. Many lines look like
errors, but most are side effects.
1. Find the first error that is a cause, not a consequence, and quote it.
2. Explain the chain from that error to the final failure in a few steps.
3. List the lines I can safely ignore and why.
4. Tell me what to look at next to confirm the cause.
Log:
{{log}}
2. Build a minimal reproduction
A small repro turns a vague bug into one you can test. It is also what maintainers ask for in an issue.
I have a bug in {{language:TypeScript}} that I can only trigger inside the
full app. Help me cut it down to a minimal reproduction.
Bug: {{bug}}
How I trigger it now: {{steps}}
Relevant code: {{code}}
Propose the smallest standalone script or test that should show the same
bug. Remove every dependency you can, and list what you removed. If the
repro might not fail, tell me which removed piece is the most likely
reason, so I add it back first.
3. Plan experiments, cheapest first
For bugs where you have no strong lead. It turns "try things" into a short list of tests that each rule something out.
Here is what I know about a bug. Don't propose a fix yet.
Symptom: {{symptom}}
When it started: {{when:unknown}}
What I already ruled out: {{ruled_out:nothing yet}}
Environment: {{environment}}
List up to five hypotheses. For each one give: the evidence for it, the
evidence against it, and one quick experiment that would confirm or rule
it out. Order the experiments from cheapest to most expensive to run.
How do you fix flaky tests?
4. Diagnose a flaky test
A test that passes and fails on the same code usually has one of a few causes. This prompt makes the model pick one with evidence.
This {{framework:Vitest}} test fails about {{rate:1 in 10}} runs with no code
change.
Test:
{{test}}
Code under test:
{{code}}
Failure output from a few runs:
{{failures}}
Classify the most likely cause: timing or unawaited async work, test
order or shared state, real clock or time zone, randomness, network or
external services, or resource limits in CI. Point to the lines that
support your answer. Then give a change that makes the failure happen
every time, so I can confirm the cause before fixing it.
5. Tests pass alone but fail together
The classic sign of state leaking between tests.
{{test_name}} passes when I run it alone and fails when I run the whole
file or suite with {{framework:Vitest}}.
Failing output:
{{output}}
Test file and setup code:
{{code}}
Find state that one test leaves behind for another: module-level
variables, singletons, mocks that are never restored, database rows,
environment variables, timers or files. Name the test most likely to
leak it and show the cleanup that fixes it, in the setup or teardown
hooks this framework uses.
How do you find the commit that broke something?
6. Write a git bisect script
git bisect searches your history for the first bad commit. With git bisect run, a script decides each step. Per the git bisect documentation, the script exits 0 for good, 1 to 127 (except 125) for bad, and 125 to skip a commit that can't be tested.
Something broke between {{good:v1.4.0}} and {{bad:HEAD}}. Write a shell
script for `git bisect run` that checks whether this bug is present:
Bug: {{bug}}
How I check it by hand: {{check}}
Build or install command: {{build:npm ci}}
Rules: exit 0 if the commit is good, exit 1 if the bug is present, exit
125 if the commit can't be built or tested so bisect skips it. Keep the
check fast and specific to this bug. Then show the exact git bisect
commands to start, run and reset the session.
How do you debug slow code?
7. Find why an endpoint is slow
Guessing about performance wastes days. This prompt works from measurements, not intuition.
{{endpoint:GET /api/orders}} takes {{slow:about 2 seconds}} and should take
{{target:under 300 ms}}.
Profile or trace output:
{{profile}}
Handler code:
{{code}}
From the measurements, rank where the time goes. For the top item, say
whether the fix is less work, less waiting (I/O, network, locks) or
caching, and show the change. List anything you'd need measured that the
profile doesn't show. Don't suggest micro optimizations that the
profile doesn't support.
8. Fix a slow query or N+1 pattern
For database time that dominates a request. Paste the plan output, not just the SQL.
This {{database:PostgreSQL}} query is slow in production.
Query:
{{query}}
Query plan output:
{{plan}}
Table sizes: {{sizes}}
ORM code that issues it, if any: {{orm_code:none}}
Explain what the plan shows in plain words. Say whether the problem is a
missing index, a bad join order, too many rows read, or the same query
running once per row (N+1). Give the fix, the index definition if one
is needed, and how to check the improvement safely.
How do you track down a memory leak?
9. Read a heap snapshot comparison
Take one snapshot at startup and one after the leak grows, then compare. The Chrome DevTools guide on recording heap snapshots explains the Comparison view, and the Node.js docs cover heap snapshots for Node.
My {{runtime:Node.js}} process grows from {{start:200 MB}} to {{end:1.5 GB}}
over {{period:a day}} and never drops.
Comparison of two heap snapshots (top object types by size delta):
{{comparison}}
Retainer path for the largest growing object:
{{retainers}}
Relevant code:
{{code}}
Identify which code is keeping these objects alive. Common causes to
check: caches with no size limit or expiry, event listeners never
removed, timers never cleared, closures holding large objects, and
global collections. Show the fix and a quick way to confirm memory
stays flat afterwards.
10. Find a race condition
For bugs that appear under load or only on some runs, with two things touching the same data.
I suspect a race condition in this {{language:TypeScript}} code. Symptom:
{{symptom}}. It happens {{frequency:under load}}.
{{code}}
List every piece of shared state and every place it is read or written.
Find interleavings of two concurrent requests that produce the symptom,
step by step. Suggest the smallest fix (a lock, an atomic update, a
unique constraint, idempotency) and a test that runs the operations
concurrently to show the bug before the fix.
How do you handle a production incident?
11. Triage the first 15 minutes
During an incident, stopping the damage comes before finding the cause. This prompt keeps that order.
Production incident in progress.
Symptoms: {{symptoms}}
Started at: {{start_time}}
Recent changes (deploys, config, flags, traffic): {{changes}}
Dashboards and error samples: {{evidence}}
1. Ways to stop the damage now (rollback, disable a flag, scale, block a
bad client), ranked by speed and risk.
2. The three most likely causes, with the evidence for each.
3. The next three checks to run, with the exact question each answers.
Keep it short. I'll paste results as I get them.
12. Add logging to catch it next time
For intermittent bugs you can't reproduce. The goal is that the next occurrence explains itself.
This bug happens rarely in production and I can't reproduce it:
{{bug}}
Code on the path:
{{code}}
Propose logging or metrics that would explain the cause the next time
it happens. For each log line give the location, the fields to include
and the level. Avoid logging secrets or personal data. Keep the volume
reasonable for {{traffic:about 100 requests per second}}.
13. Draft a blameless postmortem
After the fix ships, write it down while the timeline is fresh.
Write a blameless postmortem from these notes. Focus on systems and
decisions, not individuals.
Timeline: {{timeline}}
Impact: {{impact}}
Root cause: {{root_cause}}
How it was fixed: {{fix}}
Sections: summary, impact, timeline, root cause, what went well, what
went poorly, where we got lucky, and action items with an owner role and
a type (prevent, detect, mitigate). Mark anything the notes don't
support with "Check:".
Which debugging prompts should you turn into skills?
Prompts you reach for every week work better as skills, so the agent applies them on its own. The flaky test and bisect prompts are good candidates. Paste one into the free SKILL.md generator to get a valid SKILL.md. For a ready-made approach, the systematic debugging skill and the diagnosing bugs skill both make an agent find the root cause before it edits code. Once you have a failing case, the unit test prompts help turn it into a regression test, and the Claude Code best practices guide covers giving the agent a check it can run.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks such as {{runtime:Node.js}} stay as fill-in fields, you can tag prompts and find them with Cmd+K, and skills you keep there install into Claude Code or Codex with one npx skills add command.