$npx -y skills add softspark/ai-toolkit --skill explainExplains code/architecture with Mermaid diagrams and sequence flows. Triggers: what does X do, how does Y work, explain code, sequence diagram.
| 1 | # Explain |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Generates visual architecture explanations. |
| 6 | |
| 7 | ## Output Format |
| 8 | |
| 9 | ### 1. High-Level Role |
| 10 | "This module handles [Responsibility]. It interacts with [Dependencies]." |
| 11 | |
| 12 | ### 2. Dependency Graph (Mermaid) |
| 13 | Generate a graph showing imports/exports. |
| 14 | ```mermaid |
| 15 | graph TD |
| 16 | A[AuthService] -->|uses| B[UserRepo] |
| 17 | A -->|validates| C[Schema] |
| 18 | D[Controller] -->|calls| A |
| 19 | ``` |
| 20 | |
| 21 | ### 3. Key Flows (Sequence) |
| 22 | If logical flows are detected: |
| 23 | ```mermaid |
| 24 | sequenceDiagram |
| 25 | User->>Controller: Login |
| 26 | Controller->>Service: Validate |
| 27 | Service->>DB: Check Creds |
| 28 | DB-->>Service: Result |
| 29 | Service-->>Controller: Token |
| 30 | ``` |
| 31 | |
| 32 | ## Protocol |
| 33 | 1. **Scan**: Read file contents to identify classes and functions. |
| 34 | 2. **Link**: Identify imports to find collaborators. |
| 35 | 3. **Visualize**: Generate standard Mermaid syntax. |
| 36 | |
| 37 | ## Automated Dependency Graph |
| 38 | |
| 39 | Run the bundled script to extract imports and generate a Mermaid diagram: |
| 40 | |
| 41 | ```bash |
| 42 | python3 ${CLAUDE_SKILL_DIR}/scripts/dependency-graph.py src/auth.py |
| 43 | ``` |
| 44 | |
| 45 | ## Rules |
| 46 | |
| 47 | - **MUST** start from what the user already knows — if it is unclear, ask one question before explaining |
| 48 | - **MUST** ground the explanation in the actual code (file:line references), not in generic framework theory |
| 49 | - **NEVER** use an analogy when a direct definition is clearer — analogies add a translation step for the reader |
| 50 | - **NEVER** produce a diagram that the text does not already justify — diagrams illustrate, they do not replace the explanation |
| 51 | - **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. |
| 52 | - **MANDATORY**: if the user asks for a short answer, give a one-paragraph summary without diagrams — not every request needs a Mermaid graph |
| 53 | |
| 54 | ## Gotchas |
| 55 | |
| 56 | - 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. |
| 57 | - `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. |
| 58 | - Sequence diagrams have no notion of async vs sync. Two parallel calls render as sequential; distinguish with a `par` block or a note. |
| 59 | - 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. |
| 60 | - 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. |
| 61 | |
| 62 | ## When NOT to Use |
| 63 | |
| 64 | - To critique or improve the code — use `/review` or `/refactor` |
| 65 | - To find a specific function across the codebase — use `/explore` or `Grep` |
| 66 | - To write the documentation that the explanation turns into — use `/docs` |
| 67 | - For a full architecture audit or redesign — use `/architecture-audit` |
| 68 | - When the user asks "why is this broken" — use `/debug`, not `/explain` |