Decode a stack trace and pinpoint the likely root cause
Reads a stack trace frame by frame to explain the failure and pinpoint the most likely root cause with next steps.
A stack trace looks intimidating, but it's a precise map—if you read it in the right order and separate your code from framework noise. This prompt reads the trace from the innermost frame outward, explains the relevant frames in plain English, and—most importantly—names the single most likely root cause rather than the surface symptom. (A NullPointerException at line 80 is the symptom; the real cause is usually three frames down where a value was never set.) It distinguishes your code from library frames so you focus where you can act, and it ends with two or three concrete confirmation steps: a log to add, an input to inspect, or a minimal repro to build. Paste the full trace, a one-line description of what you were doing when it happened, and any relevant code—context dramatically sharpens the diagnosis. Tell it the language and runtime so it interprets framework frames correctly. Treat its root-cause call as a strong hypothesis to confirm, not gospel.
You are an expert debugger fluent in [LANGUAGE] and its runtime. I will paste a stack trace and a short description of what I was doing. Read the trace from the innermost frame outward, explain in plain English what each relevant frame is telling us, and identify the single most likely root cause—not just the symptom. Distinguish my code from library/framework frames. List two or three concrete next steps to confirm the cause (logs to add, inputs to check, a minimal repro). Relevant code context if helpful: [CODE_CONTEXT]. What I was doing: [WHAT_HAPPENED]. Stack trace: [STACK_TRACE] Return the frame-by-frame reading, the most likely root cause, and a confirmation checklist.
What you can expect back
Frame reading (innermost first): - `reports.js:42` (your code): the actual throw—something is `undefined` and you tried to read `.total` on it. - `dashboard.js:11` (your code): the route handler called `summarize(...)`; this is where the bad value originates. - `express/lib/router/layer.js` (framework): just Express invoking your handler—not the problem. Most likely root cause: For a brand-new user with no orders, the value passed into `summarize` (probably the latest order or an orders array element) is `undefined`, so `order.total` throws. The symptom is line 42, but the cause is the empty-orders case not being handled at the call site in dashboard.js. Confirmation checklist: 1. Log the argument at dashboard.js:11 right before calling summarize. 2. Reproduce with a user that has zero orders. 3. Add a guard for the empty/undefined case and confirm the error disappears.
Illustrative example — your results will vary by tool and inputs.
Get sharper results
- 01Paste the WHOLE trace, including the exception type and message—truncating hides the real origin.
- 02Add the [CODE_CONTEXT] for the named frames; it turns a good guess into a precise diagnosis.
- 03Describe what you were doing—the trigger ('new user, no orders') often points straight at the cause.
- 04Treat the root cause as a hypothesis; run the confirmation steps before changing code.
Adapt it for your case
Add 'This is an async stack trace; account for lost async context and tell me where to add async stack capture.'
Add 'After diagnosing, propose a minimal code change that fixes the root cause without masking other errors.'
Common questions
Why read the trace innermost-first?
The innermost frame is where the error was thrown; reading outward shows the call chain that led there, separating symptom from cause.
Do I need to share my code?
Not required, but pasting the frames it names sharply improves accuracy—otherwise the root cause is a best-effort inference.
Will it just fix it for me?
By default it diagnoses and gives confirmation steps. Use the 'Suggest the fix' variation to also get a minimal proposed change.
You may also need
Generate table-driven unit tests for a function with edge cases
Produces a table-driven unit test suite covering happy paths, boundaries, and error conditions for a given function.
Explain a cryptic regex and rewrite it to be readable
Decodes a confusing regex token by token, surfaces edge cases and backtracking risk, then rewrites it readably.
Port a code snippet to another language idiomatically
Translates a snippet into idiomatic code in a target language and flags cross-language correctness pitfalls.
Explain Complex Code in Simple Terms
Turn confusing code into a clear, junior-friendly explanation with edge-case notes.