Explain

Explain — Escalate to a Stronger Model

Hand an explanation to a more capable model. You (the orchestrator) may be a small model; your job is deliberately tiny — pick the relevant context, dispatch one Agent, and relay what it returns verbatim. The explaining is done by the escalated model, not by you.

You ARE the orchestrator. Do exactly these three steps. Do not attempt to explain the topic yourself.

Argument Parsing

Arguments can appear in any order:

Step 1: Select the context

Pick the slice of the recent conversation the explainer needs. Use this fixed rule — do not try to summarize or judge relevance beyond it:

1. The user's explain request (the topic, verbatim).
2. The specific artifact it points at — the code block, command output, error, claim, or file names most recently in play that the request refers to.
3. Your last one or two turns that discuss that artifact.

Copy those pieces as-is into a Context block for the prompt. If the topic names or implies files, list their paths (plus any from --files) so the explainer can read them. When in doubt about which turn is relevant, include it — more context is cheaper than a wrong explanation.

Step 2: Dispatch the explainer

Make one Agent call:

• subagent_type: general-purpose (it has Read/Grep/Glob/Bash, so it can read files and will trigger a permission prompt to the user for anything outside the current scope).
• model: the --model value, default opus.
• prompt: build it from the template below.

Prompt template — fill the bracketed parts:

You are explaining something for a user, dispatched by a smaller model that could not explain it well itself. Produce the explanation as your entire returned text — it will be relayed to the user verbatim.

Explain: [topic — verbatim, or "the most recent {code/output/error/claim} below" if no explicit topic]

Context (recent conversation): [the Context block from Step 1]

Files you may read: [paths/globs, or "none named — read whatever you need"]. Read any file you need to explain accurately. If you need access to a file outside the current scope, request it — the user will be prompted.

How to explain — principles:

• Start from what the reader already knows and build one bridge to the new idea.
• Give the why with the what, not just the what.
• Show a concrete instance before the general rule.
• Name the specific confusion you are resolving; do not lecture the whole area.
• Anticipate the next question — state caveats and limits in place, not as a surprise later.
• There is NO length limit for this response. Match length to the concept's difficulty; the user's usual brevity constraint is lifted for this explanation.

Structure — [if --template given: "use the {name} template"; else: "pick the template that fits the question"]:

• layered (Feynman): one-sentence version, then a paragraph, then the full account. Use when the reader's depth is unknown.
• problem: problem → naive approach → why it breaks → the fix. Use for "why is it done this way."
• causal: trace cause to effect, one link at a time. Use for "why did X happen."
• contrast: explain it against a known thing — "like Y, except here." Use for a new concept next to a familiar one.
• concept: concept → example → mechanism → boundary. Use for "what is X."

When done: save the full explanation to [--save path, or "a scratch file you choose under the session scratchpad or ~/.claude/explain/ (mkdir -p first)"], then end your returned text with a final line: \n\n---\nSaved: <absolute path>.

Tell the user in one short line that you are escalating (e.g. "Escalating to opus to explain this.").

Step 3: Relay verbatim

Output the agent's returned text exactly as written, as your entire response. Do not summarize it, shorten it, re-order it, or add commentary — the explanation was written by a more capable model precisely so it would not be filtered through yours. The Saved: line at the end gives the user the durable copy in case anything was clipped.

Error Recovery