Resource
Debug Performance Problems
Measure before reasoning: find WHERE the time goes, separate latency from memory from throughput, and think at production scale.
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.
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
Resource
Debug a Production Incident
Stabilize, then diagnose: impact first, rollback options before intervention, timeline from the deploy history — forensic discipline under fire.
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.
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.
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.
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.
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.
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.
Resource
Root Cause Analysis Prompt
Forensic-grade RCA: most likely cause plus alternatives, each with supporting AND contradicting evidence — and unknowns that stay unknown.
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.
Workflow
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.
Workflow
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.
Workflow
AI Performance Optimization Workflow
Speed up code that works but drags — find the actual hot path instead of guessing, understand why it's slow, optimize it, and prove with tests that you changed the speed and nothing else.
Project
Modernize a Legacy Codebase with AI
The full path to taming an inherited codebase — understand it, document its architecture, pin its behavior with tests, then refactor, modernize, review, speed up, and ship it without breaking what works.
Guides for this tool
Guide
Get AI to Debug Without Chasing the Wrong Cause
Paste an error, say "fix this," and AI patches the first thing it sees — the symptom clears, the real cause stays. Here's how to run a debugging pass that works from symptoms and evidence to a root cause, and holds off on a fix until the evidence points at one.
Guide
How to Write an Incident Postmortem With AI
The incident's over and you've got a channel full of messages and logs, so "summarize this" returns a blamey story with an invented root cause. Here's how to turn your real notes into a blameless incident postmortem: confirmed timeline, evidence-backed factors, owned actions.
Guide
How to Analyze a Stack Trace With AI Without Trusting the Top Line
A stack trace is precise about where execution stopped and nearly silent about why it started going wrong. Here is how to analyze a stack trace with AI: read the exception chain inside out, find the frames you own, and separate what the trace proves from what it merely suggests.
Guide
How to Reproduce a Bug With AI
You click the thing twenty times, it works every time, and you close the ticket "cannot reproduce" — while it keeps happening to users. Here is how to reproduce a bug with AI: turn a vague report into conditions that make the failure appear and disappear on demand, without inventing the ones you were not given.
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.
Best for
- Turning symptoms, environment, and repro steps into a root-cause-first debugging prompt
- Stopping the model from guessing a fix before it understands the cause
- Systematic investigation of a specific failure
Not for
- A broad quality review of working code — that is the Code Review Prompt Generator
- Restructuring code that already works — that is the Refactor Prompt Builder
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.
Are the logs and stack traces I paste sent anywhere?
No — the tool assembles a debugging prompt in your browser, so the symptoms, logs, and stack traces you paste are not sent to a server or an AI model here. It doesn't investigate or fix the bug; you take the generated prompt to your own AI tool, so scrub any secrets before pasting it there.