Explain

---
name: explain
description: "Explains code/architecture with Mermaid diagrams and sequence flows. Triggers: what does X do, how does Y work, explain code, sequence diagram."
user-invocable: true
effort: medium
argument-hint: "[file or module path]"
agent: code-archaeologist
context: fork
allowed-tools: Read, Grep, Glob
---

# Explain

$ARGUMENTS

Generates visual architecture explanations.

## Output Format

### 1. High-Level Role
"This module handles [Responsibility]. It interacts with [Dependencies]."

### 2. Dependency Graph (Mermaid)
Generate a graph showing imports/exports.
```mermaid
graph TD
    A[AuthService] -->|uses| B[UserRepo]
    A -->|validates| C[Schema]
    D[Controller] -->|calls| A
```

### 3. Key Flows (Sequence)
If logical flows are detected:
```mermaid
sequenceDiagram
    User->>Controller: Login
    Controller->>Service: Validate
    Service->>DB: Check Creds
    DB-->>Service: Result
    Service-->>Controller: Token
```

## Protocol
1. **Scan**: Read file contents to identify classes and functions.
2. **Link**: Identify imports to find collaborators.
3. **Visualize**: Generate standard Mermaid syntax.

## Automated Dependency Graph

Run the bundled script to extract imports and generate a Mermaid diagram:

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/dependency-graph.py src/auth.py
```

## Rules

- **MUST** start from what the user already knows — if it is unclear, ask one question before explaining
- **MUST** ground the explanation in the actual code (file:line references), not in generic framework theory
- **NEVER** use an analogy when a direct definition is clearer — analogies add a translation step for the reader
- **NEVER** produce a diagram that the text does not already justify — diagrams illustrate, they do not replace the explanation
- **CRITICAL**: when the code base is large, scope the explanation to one entry point plus its immediate collaborators. Explaining "the whole system" in one pass fails for any non-trivial project.
- **MANDATORY**: if the user asks for a short answer, give a one-paragraph summary without diagrams — not every request needs a Mermaid graph

## Gotchas

- Mermaid renders differently across GitHub, VS Code preview, and static generators. Features added post-2023 (e.g., class diagram relations, `accTitle`) may render as raw text on older renderers. Stick to the basic subset unless you know the target.
- `dependency-graph.py` parses imports statically; dynamic imports (`__import__`, `importlib.import_module`, JavaScript `await import()`) are invisible. Note explicitly when the generated graph is likely incomplete.
- Sequence diagrams have no notion of async vs sync. Two parallel calls render as sequential; distinguish with a `par` block or a note.
- Architectural explanations that name "the service layer" or "the controller" leak framework jargon. If the project does not use those terms, use the project's own names — otherwise the reader is translating twice.
- Long Mermaid graphs wrap awkwardly on narrow screens. For >20 nodes, split into a high-level graph and drill-down graphs rather than one giant diagram.

## When NOT to Use

- To critique or improve the code — use `/review` or `/refactor`
- To find a specific function across the codebase — use `/explore` or `Grep`
- To write the documentation that the explanation turns into — use `/docs`
- For a full architecture audit or redesign — use `/architecture-audit`
- When the user asks "why is this broken" — use `/debug`, not `/explain`