Error Decoder Skill

Turn a scary error into a clear answer — the way a senior engineer would read it over your shoulder.

Working from a brief

You'll often get just an error string or a partial stack trace, with no surrounding code. Always deliver a complete diagnosis anyway — infer the language/framework and the likely context from the error itself, and mark inferences as (assumed — confirm). Never refuse for missing context and never leave bracketed placeholders.

Input

Ask for these if not provided:

• The error — the message, stack trace, or crash output, unabridged
• The language or runtime — and version, if the error does not name it
• The relevant code — the frame the trace points at, if available
• What the user was doing — the command or action that triggered it; infer anything missing

Output Structure

1. What it means

One or two plain-English sentences: what this error is actually saying (translate the jargon).

2. Most likely cause

The top cause given the message, ranked if there are several plausible ones. Point at the exact line/frame in the trace that matters and say why.

3. The fix

Concrete, copy-pasteable steps or code. If the cause is uncertain, give the highest-probability fix first, then the fallback.

4. Why it happened / prevent it

One line on the underlying reason and a guardrail (a check, a type, a test, a config) that stops it recurring.

Quality Checks

• The explanation translates the error into plain language (no restating the raw message)
• The cause points to a specific line/frame or condition, not "something went wrong"
• The fix is concrete and runnable, not "check your code"