Coding · Fixing code
The Best Prompt for Debugging Code
The best prompt for debugging treats the model as a diagnostician, not a code rewriter. You supply the exact error output, the relevant code, expected versus actual behavior and the environment; the prompt makes the model read the evidence, rank hypotheses, and name a quick check that would confirm or rule out each one. Only then does it propose the smallest fix, explain the root cause, and suggest a regression test. If the cause is not visible in what you pasted, it has to say what else it needs.
Bug Diagnosis Prompt
Give the model the error, the code and what you expected. It ranks likely causes by evidence, tells you how to confirm each, and proposes a minimal fix.
- Works with
- ChatGPT, Claude, Gemini, Cursor
- Difficulty
- Beginner
- Complexity
- Conversation
- Variables
- 7
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
7 variables · fields marked * matter most
# Role You are an experienced engineer helping me find the cause of a bug. Diagnose first and fix second. Do not rewrite code that is not part of the problem. # Evidence Error output or stack trace, exactly as it appeared: [Error output or stack trace] Relevant code: [Relevant code] What I expected: [What you expected] What happens instead: [What happens instead] Environment (language and version, framework, OS, how it is run): [Environment] What changed recently: [What changed recently] What I have already tried: [What you have already tried] # Method 1. Read the evidence. Say in two or three sentences what the error message literally means and which line or call it points to. If the trace points into library code, identify the last frame that belongs to my code. 2. Hypotheses. List up to four candidate causes, most likely first. For each one give: the evidence for it, the evidence against it, and the fastest check that would confirm or eliminate it (a print or log line, a debugger breakpoint, a one-line experiment, a command). 3. Decide. If one hypothesis is clearly supported by what I pasted, say so and continue. If not, stop after step 2, tell me which check to run and what else you need to see (a file, a config value, a log line), and wait for my reply. 4. Fix. Show the smallest change that removes the root cause, as a before and after of only the affected lines. Explain why the original code failed, not just what you changed. 5. Guard. Suggest one test or assertion that would have caught this bug, and name any other place in the pasted code with the same pattern. # Rules - Separate what the evidence shows from what you are inferring. Label each claim CONFIRMED or SUSPECTED. - Do not invent code, files, configuration or log output I have not shown you. - Do not repeat anything listed under what I have already tried unless you explain why it would behave differently now. - No fixes that hide the symptom: no blanket try/except or catch, no deleted assertion, no unexplained retry or sleep. - If the real problem is my expectation and the code is behaving correctly, say so. # Output format Use these headings: What the error says, Hypotheses (as a table), Most likely cause, Fix, Regression guard. Keep explanations short. End with one line stating how confident you are and what would change your mind.
Use it when you are
- Making sense of a stack trace or compiler error you do not recognize
- Tracking down a bug where the code runs but produces the wrong result
- Narrowing a failure that appeared after a dependency upgrade or a recent commit
- Getting a second opinion when your own fixes have not worked
- Working out why code passes locally and fails in CI or production
Why this prompt works
It asks for the evidence a colleague would ask for
A good bug report has the exact error, the code, expected and actual behavior, and the environment. Without them a model can only match your description to common problems. The Evidence block collects all five, plus what changed and what you tried, because those two details are often what separates the real cause from the plausible one.
Hypotheses are ranked, and each comes with a test
A single confident answer is fragile: if it is wrong you are back where you started. A ranked list with evidence for and against, and a specific check for each, mirrors how debugging is actually done. Even when the top guess misses, you leave the first reply with a short list of experiments instead of a dead end.
The model is allowed to stop
Step 3 gives an explicit exit when the cause is not in the pasted code. Without it, a model tends to produce a fix anyway, built on files and settings it has imagined. Telling it to name the check to run and the file it needs turns the conversation into the back-and-forth that hard bugs require.
Symptom-hiding fixes are ruled out by name
Wrapping the failing line in a catch-all handler or adding a retry makes the error disappear and leaves the defect in place. The rules list these patterns specifically, and the fix step demands an explanation of why the original code failed, so a patch without a root cause is visibly incomplete.
Confirmed and suspected are kept apart
Explanations of bugs read convincingly whether or not they are right. Labeling each claim CONFIRMED or SUSPECTED, and closing with a confidence line and what would change it, shows you which parts rest on the trace you pasted and which are inference you should verify before changing code.
How to use it
- Copy the error output as text, complete and unedited. The line numbers and the first and last frames of a trace matter more than the middle.
- Paste the function that fails and whatever calls it. Strip API keys, passwords and personal data before you paste.
- Write expected and actual behavior as observations ("returns 500 when the list is empty"), not conclusions ("the query is broken").
- Fill in what changed recently and what you tried, even if it seems unrelated. It prevents repeated suggestions.
- Run the suggested checks in order and report the results in the same conversation before applying any fix.
- Apply the fix, confirm the original error is gone, then add the suggested regression test so the bug stays fixed.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | When you come back with the result of a check, reply in the same conversation and quote the hypothesis number, so the model updates its ranking instead of starting over. |
| Claude | Expected to work | For long logs and several files, wrap each in its own tag, such as <error>, <file name="..."> and <log>, so the model can tell them apart. Anthropic recommends XML-style tags for structuring pasted material. |
| Gemini | Expected to work | No model-specific adjustment needed. Paste the prompt as written. |
| Cursor | Expected to work | In an editor assistant that can read your project, replace the pasted code with the paths of the files in the stack trace and ask it to open them, and keep the rule about not rewriting unrelated code. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: A developer maintaining a small Flask API sees a crash that only affects some customers.
# Role You are an experienced engineer helping me find the cause of a bug. Diagnose first and fix second. Do not rewrite code that is not part of the problem. # Evidence Error output or stack trace, exactly as it appeared: Traceback (most recent call last): ... File "app/reports.py", line 42, in monthly_summary average = total / len(invoices) ZeroDivisionError: division by zero Relevant code: def monthly_summary(customer_id, month): invoices = get_invoices(customer_id, month) total = sum(i.amount for i in invoices) average = total / len(invoices) return {"total": total, "average": average} What I expected: The summary endpoint returns totals for every customer What happens instead: It returns a 500 error for some customers and works for others Environment (language and version, framework, OS, how it is run): Python 3.11, Flask 3, SQLAlchemy 2, running under gunicorn What changed recently: Onboarded a batch of new customers this week What I have already tried: Restarted the service; confirmed the database is reachable # Method 1. Read the evidence. Say in two or three sentences what the error message literally means and which line or call it points to. If the trace points into library code, identify the last frame that belongs to my code. 2. Hypotheses. List up to four candidate causes, most likely first. For each one give: the evidence for it, the evidence against it, and the fastest check that would confirm or eliminate it (a print or log line, a debugger breakpoint, a one-line experiment, a command). 3. Decide. If one hypothesis is clearly supported by what I pasted, say so and continue. If not, stop after step 2, tell me which check to run and what else you need to see (a file, a config value, a log line), and wait for my reply. 4. Fix. Show the smallest change that removes the root cause, as a before and after of only the affected lines. Explain why the original code failed, not just what you changed. 5. Guard. Suggest one test or assertion that would have caught this bug, and name any other place in the pasted code with the same pattern. # Rules - Separate what the evidence shows from what you are inferring. Label each claim CONFIRMED or SUSPECTED. - Do not invent code, files, configuration or log output I have not shown you. - Do not repeat anything listed under what I have already tried unless you explain why it would behave differently now. - No fixes that hide the symptom: no blanket try/except or catch, no deleted assertion, no unexplained retry or sleep. - If the real problem is my expectation and the code is behaving correctly, say so. # Output format Use these headings: What the error says, Hypotheses (as a table), Most likely cause, Fix, Regression guard. Keep explanations short. End with one line stating how confident you are and what would change your mind.
What a good response should contain
- A plain reading of the error: line 42 divides by the number of invoices, which is zero for the failing calls
- A hypothesis table led by "customer has no invoices in that month", linked to the recent onboarding, with a one-line check such as logging len(invoices) for a failing customer
- A lower-ranked alternative, for example a filter in get_invoices excluding rows unexpectedly, with a note that the function was not shown
- A two- or three-line fix that handles the empty case explicitly and a question about what average should be when there are no invoices
- A suggested test calling monthly_summary for a customer with zero invoices, and a closing confidence statement
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- The model sees only what you paste. Causes that live in configuration, data, other files or the network will show up as requests for more information, not answers.
- A diagnosis can sound certain and still be wrong. Run the suggested check before you change code, particularly for anything labeled SUSPECTED.
- Intermittent problems such as race conditions, memory leaks and timing-dependent failures are hard to diagnose from a single snapshot of code and output.
- Error logs often contain tokens, file paths and customer data. Redact them before pasting into any AI tool, and follow your organization's rules on sharing source code.
- The proposed fix has not been executed unless your tool can run code. Re-run the failing case yourself.
Alternative prompts
Coding
Behavior-Preserving Refactoring Prompt
Restructures code in small, named steps while holding its observable behavior fixed, and reports anything it could not prove equivalent.
- ChatGPT
- Claude
- Gemini
- Cursor
Coding
Unit Test Writing Prompt
Produces a case inventory first, then readable tests that check behavior at the boundaries, with suspected bugs flagged instead of encoded as passing.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Development
Pull Request Code Review Prompt
Reviews a diff the way a careful senior engineer would: intent first, findings ranked by severity, each tied to a line with a suggested fix.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Development
Core Web Vitals Diagnosis Prompt
Works from your own field and lab data to rank likely causes of poor LCP, INP or CLS, with a way to confirm each one before you change code.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Technical guide
Prompt Chaining: Breaking a Task Into Linked Prompts
How to split a large task into a sequence of focused prompts, design the handoffs between them, and debug the chain when a step goes wrong.
Guide
How to Write a Good AI Prompt
The five parts of a complete prompt (goal, context, task, constraints, output format), with a worked rewrite and a pre-send checklist.
Frequently asked questions
What if there is no error message, just the wrong output?
Write "No error - wrong result" in the error field and be precise in the expected and actual fields: give one concrete input, the output you got and the output you wanted. A single reproducible example gives the model something to trace through the code line by line, which is how logic errors are usually found.
How much code should I paste?
Start with the function where the error occurs and the function that calls it. Add type or model definitions if the error mentions an attribute or field. Pasting an entire codebase tends to bury the relevant lines; if more is needed, the prompt instructs the model to ask for a specific file.
Why does it sometimes ask me to run something instead of giving the fix?
Because the evidence did not single out one cause. That is intended. Running a thirty-second check and reporting back is faster than applying a guessed fix, finding it did not work, and no longer knowing which of your changes matter.
Can I use this for failing tests?
Yes. Paste the test runner output as the error, and include both the test and the code under test. Say whether the test is new or used to pass, because a failing new test may mean the test is wrong and not the code.
Sources and references
- Prompt engineering overview — Anthropic
- Prompt engineering guide — OpenAI
Was this prompt useful?
No account needed. Do not include personal information.