How

How

Explore the codebase to answer "how does X work?" questions. Produce clear architectural explanations at the level of a senior engineer onboarding onto a subsystem. Enough to build a working mental model, not annotated source code.

Dispatch contract. Resolve every configured role through provider-dispatch.md. Values are provider-qualified descriptors; the parent chooses native versus external execution. On Codex, resolve remaining Claude tool names via codex-tools.md.

Two modes:

1. Explain (default). Explore the codebase and produce a clear explanation
2. Critique. Explain first, then spawn multiple models to independently identify architectural issues

Explain Mode

Step 1. Understand the Question and Assess Complexity

Parse what the user is asking about:

• "How does the rate limiter work?", a subsystem
• "How do we handle billing for on-demand usage?", a feature flow
• "How is the auth service structured?", an architectural overview
• "Walk me through what happens when a user submits a form", a runtime trace

Identify the scope. If ambiguous, state your best-guess interpretation before exploring. Don't ask. Let the user redirect if you're off.

Assess complexity to decide the approach:

• Simple (a single module, a small utility, a narrow question like "how does function X work"): skip explorer agents; the explainer explores and explains in a single pass. Go to Step 2b.
• Complex (a subsystem spanning multiple files/services, a cross-cutting feature, a full architectural overview): spawn parallel explorer agents first, then hand off to the explainer. Go to Step 2a.

When in doubt, lean simple. You can always spawn explorers if the explainer hits a wall.

Step 2a. Explore (complex questions only)

Decompose the question into 2-4 parallel exploration angles, each a distinct slice of the subsystem so explorers don't duplicate work. Example split for "how does the rate limiter work?":

• Explorer 1: data model and state management
• Explorer 2: request path and enforcement
• Explorer 3: configuration and metrics infrastructure

The right decomposition depends on the question. Use your judgment. Narrow questions: 2 explorers is fine. Broad subsystems: up to 4.

Start all explorers in one fan-out phase through provider dispatch. Use your configured how-explorer descriptor (default grok:grok-4.6@xhigh) in read-only mode. A native lane uses the parent subagent primitive; an external lane uses the launcher directly.

Each explorer gets the same base prompt from references/explorer-prompt.md plus a specific exploration angle naming its slice. Each explorer should:

• Start broad: Glob for relevant directories, Grep for key types/interfaces/class names
• Follow the thread: from an entry point, trace the call chain (callers, callees, data flow, type definitions)
• Read the actual code, don't guess from file names
• Stop when it can describe the full path from input to output (or trigger to effect) without hand-waving any step
• Note things that are surprising, non-obvious, or that a newcomer would get wrong

Each explorer returns structured findings: components found, flow traced, files read, anything non-obvious. Overlap between explorers is fine; the explainer reconciles.

Then proceed to Step 3.

Step 2b. Direct Explain (simple questions)

Dispatch one read-only lane that explores and explains in one pass using your configured how-explainer descriptor (default claude:fable@max).

The agent does its own exploration (Glob, Grep, Read) and writes the explanation directly. Read references/explainer-prompt.md for the communication style and output format. Same structure, just no explorer findings as input.

Proceed to Step 4.

Step 3. Synthesize (complex questions only)

Once all explorers return, dispatch one read-only lane to synthesize their findings into one coherent explanation using your configured how-explainer descriptor (default claude:fable@max).

The explainer gets all explorers' findings and writes the human-facing explanation (output format below). Read references/explainer-prompt.md for the full prompt template. The explainer reconciles overlapping findings, resolves contradictions, and weaves the slices into a unified picture.

Step 4. Present

Present the explainer's output to the user. You may lightly edit for clarity or add context from the conversation, but don't substantially rewrite. The explainer's communication is the product.

Output Format

Follow this structure, adapted to the question. Not every section is needed for every question.

Overview. 1-2 paragraphs. What it is, what it does, why it exists. Enough to decide whether to keep reading.

Key Concepts. The important types, services, or abstractions. Brief definition of each. Not exhaustive, just the ones needed to understand the rest.

How It Works. The core of the explanation. Walk through the flow: what triggers it, what happens step by step, where data goes, the decision points. Prose, not pseudocode. Reference specific files and functions so the reader can go look, but don't dump code blocks unless a snippet is genuinely necessary.

Where Things Live. A brief map of the relevant files/directories. Not every file, just the ones needed to start working in this area.

Gotchas. Non-obvious or surprising things that would trip someone up. Historical context that explains why something looks weird. Known sharp edges.

Critique Mode

Triggered when the user asks for architectural issues, problems, or improvements, not just understanding.

Step 1. Explain First

Run the full explain flow above (Steps 1-4). You must understand the architecture before critiquing it.

Step 2. Spawn Critics

After the explanation is complete, start one architectural critic per descriptor in your configured how-critics list (defaults claude:fable@max, codex:gpt-5.6-sol@max, grok:grok-4.6@xhigh, claude:opus@xhigh) in one fan-out phase.

Route each critic descriptor in read-only mode. These are minimum reasoning levels. The lead may raise effort within the same current-frontier model when the architecture warrants it, but must not substitute providers silently.

Read references/critic-prompt.md for the prompt template. Each critic gets:

1. The explanation from Step 1 (so they don't re-explore)
2. The relevant file paths (so they can read the actual code)
3. The architectural critique rubric from references/critique-rubric.md

Step 3. Lead Judgment

Same framework as the interrogate skill. You're a pragmatic lead, not an aggregator.

Categorize findings:

• Act on. Architectural problems worth fixing now
• Consider. Real concerns, but the cost/benefit is unclear
• Noted. Valid observations, low priority
• Dismissed. Wrong, missing context, or style preference

Present the explanation first (from Step 1), then the critique verdict below it. The explanation should stand on its own; someone who just wants to understand the system shouldn't wade through critique.