Mermaid diagrams skill
Comprehensive guide for creating software diagrams using Mermaid syntax.
by davila7·MIT license·★ 32,299 Stars on the repo·GitHub ↗
npx degit davila7/claude-code-templates/cli-tool/components/skills/creative-design/mermaid-diagrams#main ~/.claude/skills/mermaid-diagramsChecked ·commit main
Files of Mermaid diagrams
Show the full text217 lines
Mermaid Diagramming
Create professional software diagrams using Mermaid's text-based syntax. Mermaid renders diagrams from simple text definitions, making diagrams version-controllable, easy to update, and maintainable alongside code.
Core Syntax Structure
All Mermaid diagrams follow this pattern:
diagramType
definition content
Key principles:
- First line declares diagram type (e.g.,
classDiagram,sequenceDiagram,flowchart) - Use
%%for comments - Line breaks and indentation improve readability but aren't required
- Unknown words break diagrams; parameters fail silently
Diagram Type Selection Guide
Choose the right diagram type:
Class Diagrams - Domain modeling, OOP design, entity relationships
- Domain-driven design documentation
- Object-oriented class structures
- Entity relationships and dependencies
Sequence Diagrams - Temporal interactions, message flows
- API request/response flows
- User authentication flows
- System component interactions
- Method call sequences
Flowcharts - Processes, algorithms, decision trees
- User journeys and workflows
- Business processes
- Algorithm logic
- Deployment pipelines
Entity Relationship Diagrams (ERD) - Database schemas
- Table relationships
- Data modeling
- Schema design
C4 Diagrams - Software architecture at multiple levels
- System Context (systems and users)
- Container (applications, databases, services)
- Component (internal structure)
- Code (class/interface level)
State Diagrams - State machines, lifecycle states
Git Graphs - Version control branching strategies
Gantt Charts - Project timelines, scheduling
Pie/Bar Charts - Data visualization
Quick Start Examples
Class Diagram (Domain Model)
classDiagram
Title -- Genre
Title *-- Season
Title *-- Review
User --> Review : creates
class Title {
+string name
+int releaseYear
+play()
}
class Genre {
+string name
+getTopTitles()
}
Sequence Diagram (API Flow)
sequenceDiagram
participant User
participant API
participant Database
User->>API: POST /login
API->>Database: Query credentials
Database-->>API: Return user data
alt Valid credentials
API-->>User: 200 OK + JWT token
else Invalid credentials
API-->>User: 401 Unauthorized
end
Flowchart (User Journey)
flowchart TD
Start([User visits site]) --> Auth{Authenticated?}
Auth -->|No| Login[Show login page]
Auth -->|Yes| Dashboard[Show dashboard]
Login --> Creds[Enter credentials]
Creds --> Validate{Valid?}
Validate -->|Yes| Dashboard
Validate -->|No| Error[Show error]
Error --> Login
ERD (Database Schema)
erDiagram
USER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
PRODUCT ||--o{ LINE_ITEM : includes
USER {
int id PK
string email UK
string name
datetime created_at
}
ORDER {
int id PK
int user_id FK
decimal total
datetime created_at
}
Detailed References
For in-depth guidance on specific diagram types, see:
- references/class-diagrams.md - Domain modeling, relationships (association, composition, aggregation, inheritance), multiplicity, methods/properties
- references/sequence-diagrams.md - Actors, participants, messages (sync/async), activations, loops, alt/opt/par blocks, notes
- references/flowcharts.md - Node shapes, connections, decision logic, subgraphs, styling
- references/erd-diagrams.md - Entities, relationships, cardinality, keys, attributes
- references/c4-diagrams.md - System context, container, component diagrams, boundaries
- references/advanced-features.md - Themes, styling, configuration, layout options
Best Practices
- Start Simple - Begin with core entities/components, add details incrementally
- Use Meaningful Names - Clear labels make diagrams self-documenting
- Comment Extensively - Use
%%comments to explain complex relationships - Keep Focused - One diagram per concept; split large diagrams into multiple focused views
- Version Control - Store
.mmdfiles alongside code for easy updates - Add Context - Include titles and notes to explain diagram purpose
- Iterate - Refine diagrams as understanding evolves
Configuration and Theming
Configure diagrams using frontmatter:
---
config:
theme: base
themeVariables:
primaryColor: "#ff6b6b"
---
flowchart LR
A --> B
Available themes: default, forest, dark, neutral, base
Layout options:
layout: dagre(default) - Classic balanced layoutlayout: elk- Advanced layout for complex diagrams (requires integration)
Look options:
look: classic- Traditional Mermaid stylelook: handDrawn- Sketch-like appearance
Exporting and Rendering
Native support in:
- GitHub/GitLab - Automatically renders in Markdown
- VS Code - With Markdown Mermaid extension
- Notion, Obsidian, Confluence - Built-in support
Export options:
- Mermaid Live Editor - Online editor with PNG/SVG export
- Mermaid CLI -
npm install -g @mermaid-js/mermaid-clithenmmdc -i input.mmd -o output.png - Docker -
docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.png
Common Pitfalls
- Breaking characters - Avoid
{}in comments, use proper escape sequences for special characters - Syntax errors - Misspellings break diagrams; validate syntax in Mermaid Live
- Overcomplexity - Split complex diagrams into multiple focused views
- Missing relationships - Document all important connections between entities
When to Create Diagrams
Always diagram when:
- Starting new projects or features
- Documenting complex systems
- Explaining architecture decisions
- Designing database schemas
- Planning refactoring efforts
- Onboarding new team members
Use diagrams to:
- Align stakeholders on technical decisions
- Document domain models collaboratively
- Visualize data flows and system interactions
- Plan before coding
- Create living documentation that evolves with code
| 1 | |
| 2 | name mermaid-diagrams |
| 3 | description Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts, gantt charts, or any other diagram type. Triggers include requests to "diagram", "visualize", "model", "map out", "show the flow", or when explaining system architecture, database design, code structure, or user/application flows. |
| 4 | |
| 5 | |
| 6 | # Mermaid Diagramming |
| 7 | |
| 8 | Create professional software diagrams using Mermaid's text-based syntax. Mermaid renders diagrams from simple text definitions, making diagrams version-controllable, easy to update, and maintainable alongside code. |
| 9 | |
| 10 | ## Core Syntax Structure |
| 11 | |
| 12 | All Mermaid diagrams follow this pattern: |
| 13 | |
| 14 | |
| 15 | diagramType |
| 16 | definition content |
| 17 | |
| 18 | |
| 19 | **Key principles:** |
| 20 | First line declares diagram type (e.g., `classDiagram`, `sequenceDiagram`, `flowchart`) |
| 21 | Use `%%` for comments |
| 22 | Line breaks and indentation improve readability but aren't required |
| 23 | Unknown words break diagrams; parameters fail silently |
| 24 | |
| 25 | ## Diagram Type Selection Guide |
| 26 | |
| 27 | **Choose the right diagram type:** |
| 28 | |
| 29 | **Class Diagrams** - Domain modeling, OOP design, entity relationships |
| 30 | Domain-driven design documentation |
| 31 | Object-oriented class structures |
| 32 | Entity relationships and dependencies |
| 33 | |
| 34 | **Sequence Diagrams** - Temporal interactions, message flows |
| 35 | API request/response flows |
| 36 | User authentication flows |
| 37 | System component interactions |
| 38 | Method call sequences |
| 39 | |
| 40 | **Flowcharts** - Processes, algorithms, decision trees |
| 41 | User journeys and workflows |
| 42 | Business processes |
| 43 | Algorithm logic |
| 44 | Deployment pipelines |
| 45 | |
| 46 | **Entity Relationship Diagrams (ERD)** - Database schemas |
| 47 | Table relationships |
| 48 | Data modeling |
| 49 | Schema design |
| 50 | |
| 51 | **C4 Diagrams** - Software architecture at multiple levels |
| 52 | System Context (systems and users) |
| 53 | Container (applications, databases, services) |
| 54 | Component (internal structure) |
| 55 | Code (class/interface level) |
| 56 | |
| 57 | **State Diagrams** - State machines, lifecycle states |
| 58 | **Git Graphs** - Version control branching strategies |
| 59 | **Gantt Charts** - Project timelines, scheduling |
| 60 | **Pie/Bar Charts** - Data visualization |
| 61 | |
| 62 | ## Quick Start Examples |
| 63 | |
| 64 | ### Class Diagram (Domain Model) |
| 65 | |
| 66 | classDiagram |
| 67 | Title -- Genre |
| 68 | Title *-- Season |
| 69 | Title *-- Review |
| 70 | User --> Review : creates |
| 71 | |
| 72 | class Title { |
| 73 | +string name |
| 74 | +int releaseYear |
| 75 | +play() |
| 76 | } |
| 77 | |
| 78 | class Genre { |
| 79 | +string name |
| 80 | +getTopTitles() |
| 81 | } |
| 82 | |
| 83 | |
| 84 | ### Sequence Diagram (API Flow) |
| 85 | |
| 86 | sequenceDiagram |
| 87 | participant User |
| 88 | participant API |
| 89 | participant Database |
| 90 | |
| 91 | User->>API: POST /login |
| 92 | API->>Database: Query credentials |
| 93 | Database-->>API: Return user data |
| 94 | alt Valid credentials |
| 95 | API-->>User: 200 OK + JWT token |
| 96 | else Invalid credentials |
| 97 | API-->>User: 401 Unauthorized |
| 98 | end |
| 99 | |
| 100 | |
| 101 | ### Flowchart (User Journey) |
| 102 | |
| 103 | flowchart TD |
| 104 | Start([User visits site]) --> Auth{Authenticated?} |
| 105 | Auth -->|No| Login[Show login page] |
| 106 | Auth -->|Yes| Dashboard[Show dashboard] |
| 107 | Login --> Creds[Enter credentials] |
| 108 | Creds --> Validate{Valid?} |
| 109 | Validate -->|Yes| Dashboard |
| 110 | Validate -->|No| Error[Show error] |
| 111 | Error --> Login |
| 112 | |
| 113 | |
| 114 | ### ERD (Database Schema) |
| 115 | |
| 116 | erDiagram |
| 117 | USER ||--o{ ORDER : places |
| 118 | ORDER ||--|{ LINE_ITEM : contains |
| 119 | PRODUCT ||--o{ LINE_ITEM : includes |
| 120 | |
| 121 | USER { |
| 122 | int id PK |
| 123 | string email UK |
| 124 | string name |
| 125 | datetime created_at |
| 126 | } |
| 127 | |
| 128 | ORDER { |
| 129 | int id PK |
| 130 | int user_id FK |
| 131 | decimal total |
| 132 | datetime created_at |
| 133 | } |
| 134 | |
| 135 | |
| 136 | ## Detailed References |
| 137 | |
| 138 | For in-depth guidance on specific diagram types, see: |
| 139 | |
| 140 | **[references/class-diagrams.md]** - Domain modeling, relationships (association, composition, aggregation, inheritance), multiplicity, methods/properties |
| 141 | **[references/sequence-diagrams.md]** - Actors, participants, messages (sync/async), activations, loops, alt/opt/par blocks, notes |
| 142 | **[references/flowcharts.md]** - Node shapes, connections, decision logic, subgraphs, styling |
| 143 | **[references/erd-diagrams.md]** - Entities, relationships, cardinality, keys, attributes |
| 144 | **[references/c4-diagrams.md]** - System context, container, component diagrams, boundaries |
| 145 | **[references/advanced-features.md]** - Themes, styling, configuration, layout options |
| 146 | |
| 147 | ## Best Practices |
| 148 | |
| 149 | **Start Simple** - Begin with core entities/components, add details incrementally |
| 150 | **Use Meaningful Names** - Clear labels make diagrams self-documenting |
| 151 | **Comment Extensively** - Use `%%` comments to explain complex relationships |
| 152 | **Keep Focused** - One diagram per concept; split large diagrams into multiple focused views |
| 153 | **Version Control** - Store `.mmd` files alongside code for easy updates |
| 154 | **Add Context** - Include titles and notes to explain diagram purpose |
| 155 | **Iterate** - Refine diagrams as understanding evolves |
| 156 | |
| 157 | ## Configuration and Theming |
| 158 | |
| 159 | Configure diagrams using frontmatter: |
| 160 | |
| 161 | |
| 162 | |
| 163 | config: |
| 164 | theme: base |
| 165 | themeVariables: |
| 166 | primaryColor: "#ff6b6b" |
| 167 | |
| 168 | flowchart LR |
| 169 | A --> B |
| 170 | |
| 171 | |
| 172 | **Available themes:** default, forest, dark, neutral, base |
| 173 | |
| 174 | **Layout options:** |
| 175 | `layout: dagre` (default) - Classic balanced layout |
| 176 | `layout: elk` - Advanced layout for complex diagrams (requires integration) |
| 177 | |
| 178 | **Look options:** |
| 179 | `look: classic` - Traditional Mermaid style |
| 180 | `look: handDrawn` - Sketch-like appearance |
| 181 | |
| 182 | ## Exporting and Rendering |
| 183 | |
| 184 | **Native support in:** |
| 185 | GitHub/GitLab - Automatically renders in Markdown |
| 186 | VS Code - With Markdown Mermaid extension |
| 187 | Notion, Obsidian, Confluence - Built-in support |
| 188 | |
| 189 | **Export options:** |
| 190 | [Mermaid Live Editor] - Online editor with PNG/SVG export |
| 191 | Mermaid CLI - `npm install -g @mermaid-js/mermaid-cli` then `mmdc -i input.mmd -o output.png` |
| 192 | Docker - `docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.png` |
| 193 | |
| 194 | ## Common Pitfalls |
| 195 | |
| 196 | **Breaking characters** - Avoid `{}` in comments, use proper escape sequences for special characters |
| 197 | **Syntax errors** - Misspellings break diagrams; validate syntax in Mermaid Live |
| 198 | **Overcomplexity** - Split complex diagrams into multiple focused views |
| 199 | **Missing relationships** - Document all important connections between entities |
| 200 | |
| 201 | ## When to Create Diagrams |
| 202 | |
| 203 | **Always diagram when:** |
| 204 | Starting new projects or features |
| 205 | Documenting complex systems |
| 206 | Explaining architecture decisions |
| 207 | Designing database schemas |
| 208 | Planning refactoring efforts |
| 209 | Onboarding new team members |
| 210 | |
| 211 | **Use diagrams to:** |
| 212 | Align stakeholders on technical decisions |
| 213 | Document domain models collaboratively |
| 214 | Visualize data flows and system interactions |
| 215 | Plan before coding |
| 216 | Create living documentation that evolves with code |
| 217 |
Discussion
Alternatives
Browse more free Claude skills or everything in Development.