Prompt · Coding

Debugging assistant: reproduce, hypothesize, test

A disciplined debugging prompt that makes the assistant reproduce the bug, rank hypotheses by likelihood and propose the smallest test for each before suggesting any fix.

The prompt

You are an experienced debugging partner. Do not jump to a fix. Help me find the root cause first.

The problem:
- Expected behaviour: [WHAT SHOULD HAPPEN]
- Actual behaviour: [WHAT HAPPENS INSTEAD]
- Error message or stack trace: [PASTE EXACTLY, OR "none"]
- When it started / what changed recently: [e.g. "after upgrading library X to 2.0"]
- Environment: [LANGUAGE, VERSION, OS, FRAMEWORK, DATABASE]
- What I have already tried: [LIST]

Relevant code:
```
[PASTE THE SMALLEST CODE THAT SHOWS THE PROBLEM]
```

Work through these steps and label each one:
1. Reproduce: describe the minimal steps or test case that should trigger the bug. Say what information is missing to reproduce it.
2. Hypotheses: list 3-5 possible root causes, ranked from most to least likely, with the evidence for and against each.
3. Tests: for each hypothesis, give the smallest experiment that would confirm or rule it out (a log line, an assertion, a one-line change, a command).
4. Next step: tell me which single test to run first and why.

Only after I report the results, propose a fix and explain how to verify it and how to prevent a regression.
If you are unsure about how a library behaves in my version, say so instead of assuming.

Example output

Example (excerpt):
2. Hypotheses
H1 (most likely): The date is parsed in local time on the server but in UTC in tests. Evidence: fails only in production; error appears near midnight.
H2: The cache returns a stale value after the upgrade. Evidence against: the bug also occurs with cache disabled.

3. Tests
H1: Log `tz` and the raw timestamp before parsing, and run the test with TZ=America/New_York.

4. Next step: Run the H1 test first; it takes one minute and explains both symptoms.

When to use it

Use this prompt when a bug is not obvious: it appears only in some environments, the error message points to the wrong place, or the first two fixes you tried did not work. It is especially useful when you are tempted to paste an error and accept the first suggested change. That approach often fixes the symptom while leaving the cause in place.

How to customize it

[EXPECTED / ACTUAL BEHAVIOUR] should be concrete: inputs, outputs and observed values.
[ERROR MESSAGE OR STACK TRACE] must be pasted exactly. Paraphrased errors lose the details that matter.
[WHAT CHANGED RECENTLY] is often the fastest route to the cause: a dependency upgrade, a config change or a new data source.
[ENVIRONMENT] matters because library behaviour differs between versions.
[WHAT I HAVE ALREADY TRIED] stops the assistant from repeating suggestions you have ruled out.
[CODE] should be the smallest snippet that shows the problem. Trimming it often reveals the bug on its own.

Why it works

The prompt imposes the scientific method on debugging: reproduce, form hypotheses, test, then fix. Splitting the work into labelled steps is a form of chain-of-thought prompting that keeps the reasoning visible, so you can spot a wrong assumption early.

Ranking hypotheses with evidence for and against each forces the model to weigh alternatives instead of committing to the first plausible story. Asking for the smallest test per hypothesis keeps you in control: you run the experiment and report real results, which grounds the next step in facts rather than guesses. Delaying the fix until after the tests is the key constraint of the whole prompt.

Tips and variations

Paste real outputs of each test back into the same conversation; the assistant can then narrow the list.
If the assistant can run code in your tool, ask it to write and run the reproduction itself, but still read what it ran.
For intermittent bugs, add: “Consider concurrency, timing, caching and environment differences explicitly.”
Remove credentials and personal data from logs before pasting them.
When the bug is fixed, ask: “Write a regression test that would have caught this.”

#Debugging #Coding #Root Cause Analysis #Software Engineering

More Coding prompts

View all

Codingintermediate

API reference documentation from your source code

You are a technical writer who documents APIs for developers. Write reference documentation for the code below. API type: [e.g. "REST API in Express", "Python library", "GraphQL resolvers", "CLI commands"] Audience: [e.g. "external developers integrating with us", "internal frontend team"] Output format: [e.g. "Markdown", "OpenAPI 3.1 YAML", "docstrings in Google style"] Conventions we already use: [AUTH METHOD, BASE URL, ERROR FORMAT, NAMING STYLE] Code: """ [PASTE HANDLERS, FUNCTIONS, TYPES OR SCHEMAS] """ For each endpoint or public function, document: 1. Name and one-sentence purpose. 2. Method and path (or signature). 3. Parameters: name, type, required/optional, default, allowed values, description. 4. A realistic request example and a response example. 5. Errors: status codes or exceptions the code can actually raise, and when. 6. Side effects (writes, emails, external calls) and idempotency. Rules: - Document only what the code shows. If behavior is unclear (for example, validation happens elsewhere), write "UNVERIFIED:" and say what to check. - Do not invent endpoints, fields or limits. - End with a "Gaps" list: missing validation, undocumented errors, inconsistent naming.

Works with: ChatGPT, Claude, Gemini, Any LLM

Codingintermediate

Structured code review with a severity checklist

You are a senior [LANGUAGE] engineer doing a code review. Review the code below. Context: - What the code is supposed to do: [PURPOSE] - Where it runs: [e.g. "public web API", "internal batch script"] - Project conventions: [STYLE GUIDE, FRAMEWORK, VERSION] - Focus areas, if any: [e.g. "security", "performance"] Check the code against this list, in order: 1. Correctness: logic errors, edge cases (empty input, null, large values), off-by-one errors. 2. Security: input validation, injection, secrets in code, unsafe deserialization, permissions. 3. Error handling: failures that are swallowed, unclear error messages, missing cleanup. 4. Performance: unnecessary loops, repeated I/O, N+1 queries, memory growth. 5. Readability: naming, function length, duplicated code, missing comments where logic is non-obvious. 6. Tests: what is untested and which test cases you would add. Output format: - A table: # | Severity (blocker/major/minor/nit) | Line(s) | Issue | Suggested fix - Then up to 3 code snippets showing the most important fixes. - Then "What is good": 2-3 things worth keeping. Rules: only report issues you can point to in the code. If something depends on code you cannot see, list it under "Questions for the author" instead of guessing. Code: ``` [PASTE CODE OR DIFF] ```

Works with: ChatGPT, Claude, Gemini, GitHub Copilot Chat

Codingadvanced

Convert code between programming languages idiomatically

You are an engineer fluent in both [SOURCE LANGUAGE] and [TARGET LANGUAGE]. Convert the code below. Target environment: [e.g. "TypeScript 5 on Node 22", "Go 1.23", "Rust stable, no unsafe"] Libraries allowed in the target: [e.g. "standard library only", "pandas and numpy", "anything widely used"] Priority: [e.g. "match behavior exactly", "idiomatic and maintainable", "performance"] Steps: 1. Summarize what the source code does, including inputs, outputs, side effects and error cases. 2. Make a mapping table: source construct or library -> target equivalent, with notes. 3. List semantic differences that could change behavior: integer overflow and division, floating point, string encoding and indexing, null/None handling, exceptions vs error values, mutability, concurrency, sorting stability, date and time zones. 4. Write the converted code in idiomatic [TARGET LANGUAGE], not a line-by-line transliteration. Add comments where behavior is intentionally preserved in a non-obvious way. 5. Write tests in the target language that cover normal cases, edge cases and the differences from step 3. 6. List anything you could not convert faithfully and what decision I need to make. Source code: ``` [PASTE CODE] ```

Works with: ChatGPT, Claude, Gemini, GitHub Copilot Chat