architect-diagramlisted

# Skill: architect-diagram Produce Mermaid diagrams that survive enterprise wiki rendering and stay readable at a glance. Structural discipline (boundaries, technology labels, trust zones) beats pretty. ## Mode detection — pick one at entry Read the user's message and route once. Don't ask the user to flag intent. | Signal | Mode | | --- | --- | | Vague idea, no code or paths in scope. "Draw me how a checkout flow could look." | **design** | | Repo path, file list, or "the system as it is today" in scope. | **document** | | Diagram pasted into the conversation + "is this ok / what's wrong". | **review** | | Existing diagram + a diff request ("add a caching layer", "remove X"). | **update** | If two modes plausibly fit, ask once which the user wants. - **design** — generate from the user's words. Fabricate component names only where the user hasn't named one; flag fabrications. - **document** — read the code or paths first; only diagram what is actually there. Never invent names. - **review** — quick rubric pass against `references/diagram-rubric.md`; if the user wants severity-tagged findings, route to the `architect-review` skill (if installed) for the full critique. - **update** — apply the requested diff. Surface side-effects the user didn't ask for (orphaned nodes, broken trust boundaries). ## Procedure 1. **Route by mode** (above). For *document* mode, read before drawing. 2. **Pick the notation from intent.** Always load `references/notation-routin