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/architecture-diagrams.md - Cloud services, infrastructure, CI/CD deployments
- 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
.mmd files 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 layout
layout: elk - Advanced layout for complex diagrams (requires integration)
Look options:
look: classic - Traditional Mermaid style
look: 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-cli then mmdc -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---2name: mermaid-diagrams3description: Create Mermaid diagrams for software architecture, data models, code, processes, and user flows. Use for diagramming, visualization, flow explanations, and class, sequence, ER, C4, state, Git, chart, or timeline representations.4---56# Mermaid Diagramming78Create 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.910## Core Syntax Structure1112All Mermaid diagrams follow this pattern:1314```mermaid15diagramType16 definition content17```1819**Key principles:**20- First line declares diagram type (e.g., `classDiagram`, `sequenceDiagram`, `flowchart`)21- Use `%%` for comments22- Line breaks and indentation improve readability but aren't required23- Unknown words break diagrams; parameters fail silently2425## Diagram Type Selection Guide2627**Choose the right diagram type:**28291. **Class Diagrams** - Domain modeling, OOP design, entity relationships30 - Domain-driven design documentation31 - Object-oriented class structures32 - Entity relationships and dependencies33342. **Sequence Diagrams** - Temporal interactions, message flows35 - API request/response flows36 - User authentication flows37 - System component interactions38 - Method call sequences39403. **Flowcharts** - Processes, algorithms, decision trees41 - User journeys and workflows42 - Business processes43 - Algorithm logic44 - Deployment pipelines45464. **Entity Relationship Diagrams (ERD)** - Database schemas47 - Table relationships48 - Data modeling49 - Schema design50515. **C4 Diagrams** - Software architecture at multiple levels52 - System Context (systems and users)53 - Container (applications, databases, services)54 - Component (internal structure)55 - Code (class/interface level)56576. **State Diagrams** - State machines, lifecycle states587. **Git Graphs** - Version control branching strategies598. **Gantt Charts** - Project timelines, scheduling609. **Pie/Bar Charts** - Data visualization6162## Quick Start Examples6364### Class Diagram (Domain Model)65```mermaid66classDiagram67 Title -- Genre68 Title *-- Season69 Title *-- Review70 User --> Review : creates7172 class Title {73 +string name74 +int releaseYear75 +play()76 }7778 class Genre {79 +string name80 +getTopTitles()81 }82```8384### Sequence Diagram (API Flow)85```mermaid86sequenceDiagram87 participant User88 participant API89 participant Database9091 User->>API: POST /login92 API->>Database: Query credentials93 Database-->>API: Return user data94 alt Valid credentials95 API-->>User: 200 OK + JWT token96 else Invalid credentials97 API-->>User: 401 Unauthorized98 end99```100101### Flowchart (User Journey)102```mermaid103flowchart TD104 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| Dashboard110 Validate -->|No| Error[Show error]111 Error --> Login112```113114### ERD (Database Schema)115```mermaid116erDiagram117 USER ||--o{ ORDER : places118 ORDER ||--|{ LINE_ITEM : contains119 PRODUCT ||--o{ LINE_ITEM : includes120121 USER {122 int id PK123 string email UK124 string name125 datetime created_at126 }127128 ORDER {129 int id PK130 int user_id FK131 decimal total132 datetime created_at133 }134```135136## Detailed References137138For in-depth guidance on specific diagram types, see:139140- **[references/class-diagrams.md](references/class-diagrams.md)** - Domain modeling, relationships (association, composition, aggregation, inheritance), multiplicity, methods/properties141- **[references/sequence-diagrams.md](references/sequence-diagrams.md)** - Actors, participants, messages (sync/async), activations, loops, alt/opt/par blocks, notes142- **[references/flowcharts.md](references/flowcharts.md)** - Node shapes, connections, decision logic, subgraphs, styling143- **[references/erd-diagrams.md](references/erd-diagrams.md)** - Entities, relationships, cardinality, keys, attributes144- **[references/c4-diagrams.md](references/c4-diagrams.md)** - System context, container, component diagrams, boundaries145- **[references/architecture-diagrams.md](references/architecture-diagrams.md)** - Cloud services, infrastructure, CI/CD deployments146- **[references/advanced-features.md](references/advanced-features.md)** - Themes, styling, configuration, layout options147148## Best Practices1491501. **Start Simple** - Begin with core entities/components, add details incrementally1512. **Use Meaningful Names** - Clear labels make diagrams self-documenting1523. **Comment Extensively** - Use `%%` comments to explain complex relationships1534. **Keep Focused** - One diagram per concept; split large diagrams into multiple focused views1545. **Version Control** - Store `.mmd` files alongside code for easy updates1556. **Add Context** - Include titles and notes to explain diagram purpose1567. **Iterate** - Refine diagrams as understanding evolves157158## Configuration and Theming159160Configure diagrams using frontmatter:161162```mermaid163---164config:165 theme: base166 themeVariables:167 primaryColor: "#ff6b6b"168---169flowchart LR170 A --> B171```172173**Available themes:** default, forest, dark, neutral, base174175**Layout options:**176- `layout: dagre` (default) - Classic balanced layout177- `layout: elk` - Advanced layout for complex diagrams (requires integration)178179**Look options:**180- `look: classic` - Traditional Mermaid style181- `look: handDrawn` - Sketch-like appearance182183## Exporting and Rendering184185**Native support in:**186- GitHub/GitLab - Automatically renders in Markdown187- VS Code - With Markdown Mermaid extension188- Notion, Obsidian, Confluence - Built-in support189190**Export options:**191- [Mermaid Live Editor](https://mermaid.live) - Online editor with PNG/SVG export192- Mermaid CLI - `npm install -g @mermaid-js/mermaid-cli` then `mmdc -i input.mmd -o output.png`193- Docker - `docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.png`194195## Common Pitfalls196197- **Breaking characters** - Avoid `{}` in comments, use proper escape sequences for special characters198- **Syntax errors** - Misspellings break diagrams; validate syntax in Mermaid Live199- **Overcomplexity** - Split complex diagrams into multiple focused views200- **Missing relationships** - Document all important connections between entities201202## When to Create Diagrams203204**Always diagram when:**205- Starting new projects or features206- Documenting complex systems207- Explaining architecture decisions208- Designing database schemas209- Planning refactoring efforts210- Onboarding new team members211212**Use diagrams to:**213- Align stakeholders on technical decisions214- Document domain models collaboratively215- Visualize data flows and system interactions216- Plan before coding217- Create living documentation that evolves with code