c4-modellisted

Create or review C4 model architecture documentation (official c4model.com notation) as diagrams-as-code in Markdown — C4-PlantUML where the target renders it (GitLab.com does; verify Self-Managed instances), Mermaid flowchart/sequence conventions otherwise. Use whenever the user wants to visualize or document the architecture of a system or codebase — even if they never say "C4" — for requests like "diagram this service", "document the architecture", "how do the pieces of this repo fit together", "draw the system/containers/components", or when reviewing existing C4/Mermaid architecture diagrams for correctness. Covers system context, system landscape, container, component, dynamic, and deployment views. Do not use for generic flowcharts, ER diagrams, standalone Kubernetes topology, API contract documentation (OpenAPI/AsyncAPI), or architecture prose without diagrams.
mryll/skills · ★ 4 · AI & Automation · score 78

Install: claude install-skill mryll/skills

# C4 Architecture Documentation Generate C4 model architecture documentation as diagrams-as-code embedded in Markdown — in the selected notation — following the official guidance at c4model.com. The point of C4 is a small set of precise abstractions and views that stay consistent with each other — most of this skill exists to protect that precision. ## Workflow 1. **Read the repository's conventions first**: documentation language, existing architecture docs and where they live. 2. **Confirm purpose, audience, and scope.** Which views add value for this request? Context + Container is the recommended default set. Never generate every level by default — and if the user asks for one specific view, produce only that one. 3. **Separate current architecture from target architecture.** Mixing them in one view produces an ambiguous model; make two views when both are needed. 4. **Collect evidence before modeling** an existing codebase: read `references/codebase-analysis.md` and follow it. Never invent protocols, ownership, or elements the evidence does not support. 5. **Build one canonical model first**: the list of people, software systems, containers, components, and relationships — one name per element. Every view reuses these exact names; that is what makes the zoom between levels traceable. 6. **Choose the views.** Scope rules and abstraction definitions live in `references/c4-model-rules.md` — read it before modeling anything non-trivial. 7. **Generate each view** in the se