skills/explain/SKILL.md
Explains features, terms, and concepts from a codebase. Use whenever the user asks to explain, describe, or understand something ("explain X", "what is X", "how does X work"). Also use when starting an implementation, refactor, or test task — invoke as `depth:pamphlet <concept>` before writing code, `depth:novella <concept>` before designing an approach, or `depth:novel <concept>` before a deep refactor. Agent-triggered mode (depth: prefix) skips the interview and returns a structured WHAT/WHERE/HOW/CONNECTS TO block instead of a narrative.
npx skillsauth add rolemodel/rolemodel-skills explainInstall 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.
Does the input start with depth:pamphlet, depth:novella, or depth:novel?
YES → This is an agent call. Do the following and nothing else:
architecture.md, pattern questions → pattern.md, technology or named-library questions → technology.md, everything else → default.md.WHAT: one-sentence definition
WHERE: key file paths
HOW: core flow or logic
CONNECTS TO: related concepts/models
For depth:novella or depth:novel, expand each field to a paragraph. Each playbook also adds fields:
default.md / architecture.md: add DATA MODEL: key attributes and associationspattern.md: add DATA MODEL (base classes/concerns/gems the pattern depends on) and EXAMPLES: 2–3 real file pathstechnology.md: add CONFIGURATION: how the library is initialized and USAGE PATTERN: the canonical call pattern (no DATA MODEL)NO → Continue reading below and run the full interview.
Ask these three questions one at a time, waiting for the answer before proceeding to the next. Do not ask multiple questions at once — the interview pace matters because each answer shapes what you ask next.
AskUserQuestion with the question "How much detail do you need?" (header: "Detail level"), offering these options:
AskUserQuestion): "What are you trying to do? Is there a specific area or feature you are trying to understand? (e.g., get a general orientation, understand something before making a change)"Use the answers to calibrate depth and vocabulary throughout. A backend developer writing docs should get thorough model/relationship coverage. A frontend developer making a UI change should get more focus on API surface and data shape.
Based on the user's question, follow the appropriate playbook:
design.mdtechnology.mdarchitecture.mdpattern.mddefault.mdWhen in doubt between technology and pattern: if the user named a specific library or gem, route to technology.md. If they named a coding convention or approach without naming a library, route to pattern.md.
If unclear, default to default.md.
Tailoring by intent (all levels):
These format constraints apply to all playbooks. Each playbook defines what content to include — these rules define how much and in what form to write it.
Tailor the explanation to the user's profile. Read it from ~/.claude/PROFILE.md if it exists, and use any stated preferences to shape vocabulary, tone, and emphasis. For example, if they say they prefer concise explanations, skip the analogies and narrative flourishes and get straight to the point. If they say they like thorough explanations, include more context, examples, and details. Use their role and experience to focus on things that are specific to this project and avoid over-explaining things they likely already know.
Pamphlet — 2–5 sentences as a single plain paragraph. No headings, no bullet points, no code blocks, no diagrams, no jargon. Pure prose.
Novella — 1–2 paragraphs. Light on code snippets, heavy on concepts. Use subheadings only when there are clearly distinct parts that need separation — otherwise, keep it as flowing prose.
Novel — A full technical walkthrough organized with headings. Include file references as clickable markdown links in [file:line](path/to/file#Lline) format (e.g. [app/models/user.rb:42](app/models/user.rb#L42)) so they open directly in VS Code. Cover every section the playbook specifies; omit a section only if it genuinely doesn't apply (e.g. no background jobs exist for this area).
Always end with a short follow-up block. Write 2–3 specific suggestions based on what you just covered — not generic options. Each suggestion should reflect something a reader of this particular explanation would naturally want to explore next. Examples of what "specific" looks like:
Format the block as:
Want to go deeper?
Or ask for a different depth — Pamphlet (brief), Novella (overview), Novel (full deep-dive).
Each playbook may add one additional suggestion specific to its domain — append it to this list.
If ~/.claude/PROFILE.md was not found when you read it at the start of Phase 1, append this line after the follow-up block (do not add it if the profile already exists):
Want to customize explanations to your preferences? Use
/create-profile
When this skill is invoked by another agent (not a user explicitly running /explain), skip Phase 1 entirely and produce a condensed output optimized for model consumption rather than human reading.
Prefix the input with a depth tag, then the topic:
depth:pamphlet retainer drawdowns
depth:novella harvest sync architecture
depth:novel partner model
Omitting the prefix defaults to depth:pamphlet.
Return a structured block with these fields (omit any that are not applicable):
WHAT: one-sentence definition
WHERE: key file paths (model, service, controller, etc.)
HOW: brief description of the core flow or logic
CONNECTS TO: comma-separated list of related concepts/models
For depth:novella or depth:novel, expand each field to a short paragraph rather than a single line. Each playbook adds additional fields:
| Playbook | Extra fields for novella/novel |
|---|---|
| default.md | DATA MODEL: key attributes and associations (column names, foreign keys, enums) |
| architecture.md | DATA MODEL: key models and their relationships in plain text |
| pattern.md | DATA MODEL: base classes, concerns, or gems the pattern depends on (or n/a) + EXAMPLES: 2–3 real file paths that best illustrate the pattern |
| technology.md | CONFIGURATION: how the library is initialized or configured in this app + USAGE PATTERN: the canonical way the library is called in this codebase |
The goal is a tight information packet the calling agent can reason over, not a walkthrough a developer would read.
User-triggered:
where is this in the app? → design.mdwhich files control this page → design.mdwhat does the partner card look like → design.mdwhat fonts and colors does the app use → design.mdexplain retainer drawdowns → default.mdexplain SHM novel → default.mdwhat is a partner? → default.mdgive me a pamphlet on booked time → default.mdhow does harvest sync work → architecture.mdexplain the structure of the billing feature → architecture.mdI'm new here, give me an overview → architecture.mdhow are service objects structured here → pattern.mdexplain the policy pattern → pattern.mdwhat's our convention for background jobs → pattern.mdhow does Pundit work in this app → technology.mdhow are we using StimulusJS → technology.mdexplain how Turbo is set up here → technology.mdhow is Harvest integrated → technology.mdwhat gems handle authorization → technology.mdAgent-triggered:
depth:pamphlet retainer drawdowns → default.md, structured block outputdepth:novella harvest sync → architecture.md, expanded structured blockdepth:novel partner model → default.md, full structured block with DATA MODEL fielddepth:pamphlet service object pattern → pattern.md, structured block outputdepth:pamphlet Pundit → technology.md, structured block outputdepth:novella StimulusJS → technology.md, expanded structured blocktesting
Verify what Ruby versions actually exist and install a specific Ruby via rbenv. Use BEFORE asserting that any Ruby version does or doesn't exist (e.g., "Ruby 4.0 isn't out yet", "the latest Ruby is 3.x", "Ruby X.Y.Z doesn't exist"). Also use when the user asks "what's the latest Ruby", "is Ruby X out", "does Ruby X.Y exist", "install Ruby", "switch to Ruby X", "what Ruby is installed", or mentions a specific Ruby version you're unsure about. Claude's training data may be out of date — run `check.sh` first.
development
Trace code through the stack — upward to entry points, downward to data, or laterally across boundaries. Use when the user asks "where does this get called from", "what calls this method", "trace this through the stack", "how does this request flow", "where does this data come from", "follow this through the code", or pastes/selects a piece of code and wants to understand where it fits in the larger system.
tools
Pick the single highest-priority unresolved Sentry issue and hand it off to a fixer skill. Use when triaging Sentry errors, running automated issue triage, or when asked to fix the top Sentry issue in a project.
tools
Find and fix issues from Sentry using MCP. Use when asked to fix Sentry errors, debug production issues, investigate exceptions, or resolve bugs reported in Sentry. Methodically analyzes stack traces, breadcrumbs, traces, and context to identify root causes.