Debug Performance Problems
Measure before reasoning: find WHERE the time goes, separate latency from memory from throughput, and think at production scale.
View Resource →Coding Workflows
Debugging Prompt Generator
"Fix this error" gets guesses. Describe the symptoms, environment, and evidence — and get an investigation contract: a ten-stage framework, fact/assumption/hypothesis discipline, root-cause rules with alternatives, and a forensic mode where unknowns stay unknown. Runs entirely in your browser.
What problem is being investigated? E.g. "Diagnose why invoice totals are wrong since the last release."
What is observably happening — observations, not interpretations.
If you can't reproduce it, leave this empty — the prompt will demand "Information Needed To Reproduce" instead of pretending.
Paste raw — the detector recognizes stack traces and error messages, and the prompt carries them verbatim.
Investigation Preview (live — detected inputs and the contract's shape)
Debugging Prompt
Debug a Production Incident
Stabilize, then diagnose: impact first, rollback options before intervention, timeline from the deploy history — forensic discipline under fire.
View Resource →Debugging Prompt — the Investigation Contract
"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.
View Resource →Debugging with AI — Done Right
AI is a strong debugging partner and a confident wrong one: the fast-investigation contract that keeps its speed and removes its overconfidence.
View Resource →Error Analysis Prompt
An exception is a symptom, not a diagnosis: trace from the throw site back to the root trigger, with the runtime checklist on the table.
View Resource →Investigate Intermittent Bugs
It fails once in twenty runs: the occurrence pattern IS the evidence. Hunt the difference between failing and passing runs — forensically.
View Resource →Investigate Runtime Errors
The error only happens for some inputs: find the implicit contract those inputs violate, with the runtime checklist as the suspect list.
View Resource →Reproduce Software Bugs — Bug Report to Reliable Repro
Support says it happens; nobody can make it happen. Turn a vague bug report — symptoms, environment, expected vs actual — into a reproduction strategy.
View Resource →Root Cause Analysis Prompt
Forensic-grade RCA: most likely cause plus alternatives, each with supporting AND contradicting evidence — and unknowns that stay unknown.
View Resource →Stack Trace Analysis Prompt
Read the trace bottom-up, find the frame where the bad value entered, and name what made it bad — the trace is a map, not an answer.
View Resource →AI Debugging Workflow
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
View Playbook →AI Production Incident Workflow
Work a live production incident in the right order — triage and stabilize first, then find the cause, then write the summary and postmortem — so the fire is out before the writeup begins.
View Playbook →How it works
State the debugging objective, pick the problem type — Runtime Error, Functional Bug, Performance Problem, Production Incident, or Intermittent Problem — and fill the investigation inputs: symptoms, expected vs actual behavior, reproduction steps, and raw logs or stack traces. Each problem type is a different investigation strategy with its own checklist of candidate causes; the detector recognizes stack traces and error messages in your logs, and the live preview shows what evidence the contract will work with. Choose the investigation mode — Forensic is the flagship: every conclusion must cite evidence, and unknowns remain unknown — and the environment, where Production adds impact assessment, rollback planning, and observability review. Click Generate Debugging Prompt for the full investigation contract: a ten-stage framework from symptoms to post-fix verification, fact/assumption/hypothesis discipline, and root-cause rules that demand alternatives and contradicting evidence. Nothing leaves your browser.
Use cases
- Turning "fix this error" into a structured root cause investigation
- Running production incidents with impact-first, evidence-first discipline
- Working a stack trace back from the throw site to the root trigger
- Pinning down intermittent bugs by their occurrence patterns
Pro tips
- Leave reproduction steps empty when you genuinely can't reproduce — the contract then demands "Information Needed To Reproduce" instead of letting the model pretend. A fabricated repro is worse than none.
- Use Forensic mode when the cost of a wrong conclusion is high: production incidents, data integrity bugs, anything that gets escalated. Its rule that assumptions may only appear as questions changes the entire answer.
- Paste logs raw — timestamps, noise, and all. The model needs the evidence as it exists; a cleaned-up summary is already an interpretation.
- The fact/assumption/hypothesis discipline is the part worth learning, not just using: "the database is probably down" labeled as an ASSUMPTION gets verified; stated as a fact, it derails the whole investigation.
FAQ
Does this tool fix my bug?
No — it builds the investigation. The generated prompt's explicit rule is "do not jump directly to a solution before identifying the most likely root cause." The goal is not "give me a fix"; it's "determine what is actually happening." The fix recommendation comes at stage nine of ten — after causes, evidence, and validation.
What happened to the Bug Report Prompt Builder?
It became this tool's input structure. Symptoms, environment, reproduction steps, expected and actual behavior, severity — the fields of a good bug report are exactly the inputs a good investigation starts from. They're investigation inputs now, not a separate document-writing tool.
What makes Forensic mode different?
Rigor that changes the output. Every conclusion must cite its specific evidence — the log line, the stack frame, the reproduction result. Unknowns are written as "insufficient evidence", never papered over with plausible guesses. And assumptions are forbidden in conclusions entirely — they may only appear in MISSING INFORMATION as questions to resolve. Fast mode allows labeled assumptions; Forensic doesn't.
Why does the prompt separate facts, assumptions, and hypotheses?
Because confusing them is how debugging goes wrong. "The application returned HTTP 500" is a FACT. "The database is probably down" is an ASSUMPTION — believed without evidence, and it must be verified or discarded. "A failed database connection may be causing the 500" is a HYPOTHESIS — a testable causal claim that comes with its test. Most failed investigations promoted an assumption to a fact somewhere.
How is this different from the Code Review Prompt Generator?
Different verbs. Review EVALUATES code that may be fine — it judges quality against criteria. Debugging INVESTIGATES a problem that definitely exists — it works from symptoms and evidence to a root cause. Review can run on any code; debugging needs a failure. And in this category: Refactor changes, Test Case validates, Code Explanation teaches — Debugging investigates.
What does choosing Production as the environment change?
It adds production discipline to the contract: assess customer impact first (scope, severity, ongoing or not), review rollback options before intervening, review the deployment history for the symptom window, check what monitoring caught and missed — and after any fix, verify recovery in monitoring rather than in the absence of complaints.