How do I install the Error Decoder skill?

Run npx skillmds@latest add gabrielmoreira/error-decoder in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Error Decoder safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: CAUTION, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Error Decoder?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Error Decoder free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Error Decoder?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Error Decoder by gabrielmoreira — Agent Skill

Name: Error Decoder
Rating: 4.2 (5 reviews)
Author: gabrielmoreira

Error Decoder

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.

gabrielmoreira Updated Sep 9, 2026 17 repo stars

File contents

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

---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

Frequently asked questions