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.
Pasting an error message and asking an AI to fix it usually produces a confident guess that treats the symptom. Real debugging has an order to it. You reproduce the failure so you can tell when it's actually gone. You trace it back to the real cause instead of the first suspicious line. You make sure you understand the code you're about to change. And you fix it behind a test, so the same bug can't quietly return three commits later. This workflow runs those steps with the coding tools you already have.
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
Reproduce the failure first
Before any fixing, get a reliable repro — the smallest sequence that triggers the bug every time. A reproduction is what tells you later whether the fix actually worked, and it stops the AI from theorizing about a problem it can't see.
Trace it to a root cause
Give the AI the stack trace, the repro, and the surrounding code, and push it past the first plausible line to the cause underneath. You're after the why, not the where.
Understand the code you're about to change
If the faulty code isn't obvious, get a plain explanation of what it really does before you touch it. A good share of bad fixes come from changing code the author misread.
Fix it behind a failing test
Write the test that fails because of the bug, then change code until it passes. Now the fix is provable, and the bug can't slip back in unnoticed later.
Tidy the fix if it left a scar
Quick fixes often leave an awkward conditional or a duplicated branch behind. If yours did, clean just that one spot — no broader rewrite in the middle of a bugfix.
The bug is reproduced, traced to its real cause, fixed, and locked behind a test that fails without the fix. You're left with a change you can defend in review — not a guess that happened to make the error message disappear.
A debugging prompt analyzes one error in isolation; this workflow is the ordered sequence around it. You reproduce the failure, trace it to a root cause, understand the code, then fix behind a failing test, so you land on the real problem instead of the first plausible line.
You end with a minimal reproduction, a documented root cause backed by evidence, and a code fix locked behind a regression test that fails without the fix and passes with it. The deliverable is a change you can defend in review, not a guess that only silenced the error message.
Work the five steps in order in your own AI coding tool: get a reliable repro, feed the stack trace and code to trace the root cause, explain unfamiliar code before touching it, write a failing test then fix until it passes, and tidy any scar. NewPrompt supplies the prompts and step order; you run them.
Verify the root cause against your reproduction from step 1: a correct cause should predict exactly when the bug fires and disappears. If a fix built on it doesn't make your failing test pass, the diagnosis was symptom-level. Push the AI past the first plausible line and re-trace with fresh evidence. The final judgment is yours.
Use that one when something is broken in production right now and the first job is to stop the bleeding and communicate. This workflow is for fixing a bug properly once you have the time to do it right.
Steps 1, 2, and 4 are the backbone. Step 3 only matters when the code is unfamiliar, and step 5 only when the fix left the code messier than it found it.
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.
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.
Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.
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.
Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.
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.