mermaid-studio
mermaid-studio generates professional Mermaid diagrams from natural language descriptions or code analysis, supporting 20+ diagram types including flowcharts, sequence, C4 architecture, AWS infrastructure, entity relationships, and state diagrams. Use it when users request diagram creation, architecture visualization, syntax validation, batch rendering, or multi-format export to SVG, PNG, or ASCII with customizable themes and styling.
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/mermaid-studio && cp -r /tmp/mermaid-studio/packages/skills-catalog/skills/(tooling)/mermaid-studio ~/.claude/skills/mermaid-studioSKILL.md
# Mermaid Studio
Expert-level Mermaid diagram creation, validation, and multi-format rendering. Creates diagrams from descriptions or code analysis, validates syntax, and renders to SVG, PNG, or ASCII with professional theming.
## Golden Rules — Elegant Diagrams by Default
Every diagram MUST follow these principles. They are not optional — they define the difference between a mediocre diagram and a gold-standard one.
### Rule 1: Always Use an Init Directive for Professional Styling
**NEVER** create a diagram without an `%%{init}` directive or frontmatter config. The default Mermaid theme produces harsh black lines and generic colors. Always apply a curated palette.
**For general diagrams (flowchart, sequence, state, class, ERD):**
```
%%{init: {'theme': 'base', 'themeVariables': {
'primaryColor': '#4f46e5', 'primaryTextColor': '#ffffff',
'primaryBorderColor': '#3730a3', 'lineColor': '#94a3b8',
'secondaryColor': '#10b981', 'tertiaryColor': '#f59e0b',
'background': '#ffffff', 'mainBkg': '#f8fafc',
'nodeBorder': '#cbd5e1', 'clusterBkg': '#f1f5f9',
'clusterBorder': '#e2e8f0', 'titleColor': '#1e293b',
'edgeLabelBackground': '#ffffff', 'textColor': '#334155'
}}}%%
```
**⚠️ Font Warning:** Do NOT set `fontFamily` in theme variables. The Mermaid default font (`trebuchet ms, verdana, arial, sans-serif`) works everywhere. Setting `system-ui`, `Segoe UI`, or `-apple-system` will render as Times New Roman in headless Chromium (used by `mmdc`).
**For C4 diagrams — see the dedicated C4 styling section below.**
**For architecture-beta diagrams — see the dedicated AWS/Architecture section below.**
### Rule 2: Soft Lines, Never Harsh Black
The single biggest visual improvement is using `lineColor: '#94a3b8'` (slate-400) instead of the default black. This creates a modern, breathable diagram. For dark themes, use `lineColor: '#64748b'` (slate-500).
### Rule 3: Limit Density — Breathe
- Maximum 15 nodes per diagram (not 20 — fewer is more elegant)
- Use `subgraph` or boundaries to create whitespace and visual grouping
- Prefer LR (left-right) for process flows — it reads more naturally
- Use invisible links (`A ~~~ B`) to add spacing when the layout is cramped
### Rule 4: Meaningful Labels and Consistent Style
- Node IDs: camelCase (`orderService`, not `s1` or `os`)
- Labels: short, clear natural language (`[Order Service]`)
- Arrows: action verbs with protocol info (`"Sends order via gRPC"`)
- Descriptions: one-line, role-focused (`"Handles order lifecycle"`)
### Rule 5: Color Harmony Over Color Variety
Use max 3-4 colors per diagram. Map colors to meaning:
- **Blue tones** (#4f46e5, #3b82f6) → primary systems, internal services
- **Green tones** (#10b981, #059669) → success states, data stores
- **Amber tones** (#f59e0b, #d97706) → external systems, warnings
- **Slate tones** (#64748b, #94a3b8) → lines, borders, secondary elements
- **Red tones** (#ef4444) → errors ONLY, never as decoration
## Modes of Operation
This skill operates in three modes based on user intent:
| Mode | Trigger | What happens |
| ---------- | ------------------------------------------------- | -------------------------- |
| **Create** | "draw a diagram of...", "visualize my..." | Generates .mmd code only |
| **Render** | "render this mermaid", "convert to SVG/PNG/ASCII" | Renders existing .mmd |
| **Full** | "create and render...", ambiguous requests | Create → Validate → Render |
Default to **Full** mode when intent is unclear.
## Step 1: Understand the Request
Before writing any Mermaid code, determine:
1. **What to diagram** — system, flow, schema, architecture, code structure?
2. **Which diagram type** — use the Decision Matrix below
3. **Output format** — code only, SVG, PNG, or ASCII?
4. **Theme preference** — ask only if rendering; default to `base` theme with curated palette
### Diagram Type Decision Matrix
| User describes... | Diagram Type | Syntax keyword |
| ---------------------------------------------- | ------------- | -------------------- |
| Process, algorithm, decision tree, workflow | Flowchart | `flowchart TD/LR` |
| API calls, message passing, request/response | Sequence | `sequenceDiagram` |
| Database schema, table relationships | ERD | `erDiagram` |
| OOP classes, domain model, interfaces | Class | `classDiagram` |
| State machine, lifecycle, transitions | State | `stateDiagram-v2` |
| High-level system overview (C4 Level 1) | C4 Context | `C4Context` |
| Applications, databases, services (C4 Level 2) | C4 Container | `C4Container` |
| Internal components (C4 Level 3) | C4 Component | `C4Component` |
| Request flows with numbered steps | C4 Dynamic | `C4Dynamic` |
| Infrastructure, cloud deployment | C4 Deployment | `C4Deployment` |
| Cloud services with icons (AWS/GCP/Azure) | Architecture | `architecture-beta` |
| Project timeline, scheduling | Gantt | `gantt` |
| Proportional data, percentages | Pie | `pie` |
| Brainstorming, hierarchical ideas | Mindmap | `mindmap` |
| Historical events, chronology | Timeline | `timeline` |
| Branching strategy, git history | Git Graph | `gitGraph` |
| Flow quantities, resource distribution | Sankey | `sankey-beta` |
| X/Y data visualization | XY Chart | `xychart-beta` |
| Priority matrix, strategic positioning | Quadrant | `quadrantChart` |
| Layout control, grid positioning | Block | `block-beta` |
| Network packets, protocol headersFinds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).
Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).
AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.