architecture-diagram-generatorlisted

Most architecture diagrams lie. They were drawn once on a whiteboard, drifted as the code changed, and now mislead the next person who trusts them. This skill draws diagrams *from the repository* — by reading entry points, module boundaries, service calls, and the schema — so the picture reflects what exists today. It picks the single view that answers the question instead of one sprawling everything-diagram, and emits Mermaid, which renders natively in GitHub, GitLab, Obsidian, and most docs tooling with no image pipeline. ## When to use this skill - You're onboarding to an unfamiliar repo and need a map of the services and how they call each other before you start changing anything. - You're documenting a system for a README, ADR, or design doc and want a diagram that won't go stale the moment someone reads the code. - One specific flow is hard to reason about — a checkout, an auth handshake, a webhook fan-out — and you want it laid out as a sequence over time. - You need the data model visible (tables, foreign keys, cardinality) or the lifecycle of a stateful entity (an order, a job, a subscription). ## Instructions 1. **Choose the view before drawing anything.** Pick the *one* diagram type that answers the actual question — they are not interchangeable: - **Container / component (`graph` or `flowchart`)** — "what are the services/modules and who calls whom?" Use for onboarding and system overviews. - **Sequence (`sequenceDiagram`)** — "how does *this one request