Decode an error message or stack trace into a plain-English cause, the exact fix, and how to prevent it. Use when asked to explain an error, debug a stack trace, figure out why code is throwing, or make sense of a cryptic exception. Produces a structured diagnosis: what the error means, the most likely cause, a concrete fix with code, and a prevention tip.
Start a fresh conversation. Replace the highlighted placeholders.
Use error-decoder to diagnose [error message or stack trace], identify the most likely cause, provide a concrete fix, and give one prevention step.
Required inputs
[error message or stack trace]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: error-decoderdescription: "Decode an error message or stack trace into a plain-English cause, the exact fix, and how to prevent it. Use when asked to explain an error, debug a stack trace, figure out why code is throwing, or make sense of a cryptic exception. Produces a structured diagnosis: what the error means, the most likely cause, a concrete fix with code, and a prevention tip."
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"
Assumptions about language/context are labelled
Anti-Patterns
Do not just paraphrase the error — explain what it means and why it happened
Do not give a generic "try reinstalling" answer when the trace points to a specific cause
Do not invent file names or code that wasn't given — infer and label, or ask for the one missing thing only if truly blocking
Do not stop at the fix — always add the one prevention step