Explain this error properly

Understand what actually broke and why, instead of pasting the first fix that compiles.

Use it for: Any developer staring at a stack trace they don't recognise.

The default loop with an unfamiliar error is: paste it, get a fix, apply it, move on. It usually works, and it teaches you nothing — so the next error in the same family costs exactly as much as this one did.

This prompt costs about thirty extra seconds and changes that. It asks for the causal chain before the fix, insists on the distinction between the error's trigger and its cause, and asks what class of bug this belongs to — which is the part that makes the next one cheaper.

Fill in

{{error}} — The full error message or stack trace{{context}} — What you were doing and roughly what the code does

Prompt

Here's an error I don't understand:

```
{{error}}
```

Context: {{context}}

Explain it in this order, and don't skip to the fix:

1. **What the error literally means** — decode the message itself, including
   any jargon in it. Assume I don't know the terms.
2. **The causal chain** — what happened, in order, that ended here. Distinguish
   clearly between the *trigger* (what I did) and the *cause* (what was
   already wrong).
3. **Why here and not elsewhere** — what's specific about this code path that
   made it surface here.
4. **The fix**, with the reason it works stated in one sentence.
5. **The class** — what family of bug is this, and what's the general shape of
   "code that's vulnerable to this"? Give me one other place it commonly bites.

If the trace is ambiguous about the cause, say which parts are inference
rather than presenting a confident guess as fact.

Why it works

Ordering is the whole trick. Asking for the fix last means the model has to construct the explanation first, and an explanation written before a conclusion is far more likely to be a real diagnosis than a rationalisation of a guess it already made.

Trigger versus cause is the distinction that separates a patch from a fix. Guarding the .map call stops the crash; understanding that the fetch returns undefined on a 404 fixes the bug. Naming both forces the model to show which one it's addressing.

Asking for the bug class is what makes the time pay back. One error explained is one error; one error class understood is every future instance of it recognised in seconds.

Common mistakes

×Pasting only the last line of the trace. The useful frames are usually in the middle.
×Omitting context, so the model guesses your framework and explains the wrong runtime's semantics.
×Applying the fix without reading section 5, which is the part with compounding value.

Variation: It's intermittent

When: The error only appears sometimes

Variation prompt

Same explanation, but this error is intermittent — it happens roughly
{{frequency}}. Add: what has to line up for it to occur, why it doesn't
happen every time, and what I could log to catch it in the act. An
explanation that doesn't account for the intermittency is incomplete.

Follow-ups

Show me the minimal reproduction of this error, so I can confirm we agree on the cause.
What would a test that catches this regression look like?

Did this work?

You can explain to someone else what caused the error and why the fix works — without re-reading the answer.

Tested on claude-opus-5. Evidence status is draft; it moves to battle-tested only on recorded runs, never by hand.

Our sponsor

Consense — Big decision? Compare and combine multiple LLM responses.