claude/skills/explain-this/SKILL.md
Explain whatever the user is pointing at right now in plain language: a pending question, a piece of code, an error, a command output, or an artifact like a plan or findings report. Use when the user asks to "explain this", "what am I being asked", "what's happening right now", "help me understand this", "what does this mean", "what does this error mean", "what is this code doing", or "what do these options mean".
npx skillsauth add tobihagemann/turbo explain-thisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Take whatever the user is pointing at and translate it into plain language. "This" is usually the most recent assistant output or something pasted as an argument: a multi-option prompt, a free-form question, a code block, an error, a command output, or an artifact like a plan, findings report, or diff.
Pick the subject in priority order:
Read whatever makes the explanation concrete, no more:
SKILL.md when a skill-specific question is being askedgit status and git diff --stat when the subject involves staged or unstaged changesThe reader is an experienced developer who may not be fluent in every tech stack or acronym but doesn't need concepts from first principles. Skip ELI5. Use plain language; strip skill-internal jargon, or define it inline when the jargon is what the user needs explained (for example, "P1 peer" becomes "priority 1 finding from the peer reviewer").
Go beyond "what this does" and surface the trade-offs: pros and cons per choice, benefits and costs, whether the thing reads as clean and elegant or redundant and overcomplicated. Be honest about red flags; be honest about solid work.
Shape the output to match the subject. Use the branch that applies; drop the rest.
Question with discrete options — restate the question plainly, then enumerate options using this template:
**What you're being asked:** <plain-language restatement>
### Your Options
**1. <label as shown>** — <concrete effect: files changed, next step, what is lost>
- **Pros:** <what you gain>
- **Cons:** <what it costs>
**2. <label>** — <concrete effect>
- **Pros:** <...>
- **Cons:** <...>
### When Each Fits
- Pick **<option>** if your goal is <goal>.
- Pick **<option>** if your goal is <other goal>.
Apply these option-specific rules:
auth-v2 and updates the 3 import sites in src/."AskUserQuestion, re-invoke AskUserQuestion after the explanation with the same question, header, and options so the user can answer inline without losing the dialog. Preserve any "(Recommended)" label verbatim. Otherwise (plain-text prompt from the assistant), end by noting the question is still pending and the user should reply to the original prompt directly.Free-form question — restate the question plainly, say what the answer will be used for (which file gets written, which step consumes it), and call out what makes a good answer versus a problematic one. End by noting the question is still pending.
Code, error, or command output — say what it does or means, likely cause or purpose, and what action is typically expected. Judge the design: is it clean and idiomatic, or are there smells like redundant guards, tangled control flow, or unnecessary abstraction?
Artifact (plan, findings, diff, PR) — summarize its contents, the decisions it represents, and what step comes next. Flag strengths and weaknesses: over-engineering, missing cases, clear wins.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".