Explain Deeply

Read the source of truth before explaining. Walk top-down from the biggest-picture frame to the specific question, layer by layer, with diagrams as the spine.

This skill overrides default output formatting (lead-with-the-answer, bullet-first, terse fragments) while the user is building understanding. Write in paragraphs. Revert to default output when they shift to action, diagnosis, or a new subject.

Instructions

1 — Reframe and ground

1. Decide what to read. For each check below, ask: would reading change the explanation? If no, skip it.

   • Specific to this project (a feature, function, flow, or doc in this repo) → read those files. The codebase is the source of truth, not your training.
   • Version-sensitive or current (a library's recent API, a current spec, a fast-moving tool) → fetch external info.
   • General, stable concept (e.g., "what is idempotency") → use training directly.

   The first two compose — "how does our app use Stripe's new API" needs both repo code and current docs.

2. Restate what the user is asking, as a specific commitment. Not "you want to know about auth" but "you want to understand how OAuth tokens flow from login through the middleware to the protected route." If their premise is wrong, say so and redirect. If they already framed it, sharpen — don't restart. For atomic definition questions ("what is a closure"), one line is enough.