Mermaid Diagrams
Create effective, syntactically valid mermaid diagrams for product documents.
When to Use
- Creating mermaid diagrams for PRDs, specs, roadmaps, or stakeholder presentations
- Choosing which of 15 diagram types fits a specific communication need
- Debugging mermaid code that won't render or renders incorrectly
- Reviewing diagrams for clarity, accuracy, and accessibility
When NOT to Use
- Exporting diagrams to image files (PNG/SVG) - that's a rendering tool concern
- Using non-mermaid diagramming tools (Figma, Lucidchart, draw.io)
- Creating purely decorative visuals with no informational purpose
- Producing a full customer-journey artifact (stages, touchpoints, emotional curve, pain points) rather than a standalone diagram - use
discover-journey-map, which composes this skill for its timeline or flowchart section
The Cardinal Rule
Don't diagram what a list can say.
Diagrams earn their place when they reveal relationships, branching, or flow that prose flattens. Before creating any diagram, ask:
Does this show branching, relationships, or flow that a list or table would flatten?
- Yes → proceed with a diagram
- No → use a numbered list, bullet list, or table instead
A 5-step linear process is a list. A 5-step process with two decision points and a retry loop is a diagram.
Diagram Selection Guide
| I need to show... |
Use |
Also consider |
| A decision or approval process |
Flowchart |
State |
| Multi-service or multi-party interactions |
Sequence |
Flowchart |
| Feature lifecycle or status transitions |
State |
Flowchart |
| Work stages or pipeline status |
Kanban |
State |
| Release or sprint timeline with dependencies |
Gantt |
Timeline |
| Version history or chronological milestones |
Timeline |
Gantt |
| 2D prioritization (effort/impact, risk/value) |
Quadrant |
- |
| Allocation breakdown or composition |
Pie |
Treemap |
| Problem decomposition or brainstorming |
Mindmap |
- |
| Domain models or data relationships |
ER |
Class |
| API or object contracts |
Class |
ER |
| System topology or infrastructure |
Architecture |
Flowchart |
| Flow quantities or budget allocation |
Sankey |
Pie |
| Hierarchical proportional data |
Treemap |
Pie |
| Trends or time-series metrics |
XY-Chart |
- |
For worked examples organized by PM task, see references/pm-use-cases.md.
For full syntax and options per type, see references/diagram-catalog.md.
Syntax Validity Principles
Six rules that prevent most rendering failures:
- Quote labels - Any label containing spaces, parentheses, brackets, colons, commas, or reserved words must be quoted with double quotes
- Escape special characters - Characters with mermaid or markdown meaning (
>, <, - at line start, #) need escaping or quoting
- Declare before referencing - Define a node before using it in an edge; referencing an undeclared node causes silent failures in some types
- Respect limits - Each diagram type has a maximum node/participant count beyond which readability collapses (see
references/diagram-catalog.md for per-type limits)
- Comment your intent - Use
%% comments to document non-obvious choices (why this layout direction, why this grouping)
- Test before shipping - Paste into a mermaid renderer (mermaid.live, VS Code preview, or your target environment) and verify it renders correctly
For the complete syntax reference, see references/syntax-guide.md.
Instructions
- Identify what you're communicating - What relationship, flow, hierarchy, or proportion needs to be visible? Who is the audience?
- Apply the cardinal rule - Confirm a diagram adds value over a list or table
- Select a diagram type - Use the selection guide above, browse
references/pm-use-cases.md by task, or browse references/diagram-catalog.md by type
- Plan the diagram - Fill out the planning worksheet in
references/TEMPLATE.md: purpose, audience, node inventory, type rationale
- Write the mermaid code - Follow
references/syntax-guide.md rules; start with the minimal syntax example from references/diagram-catalog.md and expand
- Validate - Run through the quality checklist below
- Embed - Place the validated mermaid code block in your document
Output Contract
- Planning artifact: A completed diagram planning worksheet (
references/TEMPLATE.md)
- Final output: A syntactically valid mermaid code block embedded in the target document
- Quality gate: All items in the quality checklist pass
Quality Checklist
References
| File |
Purpose |
references/TEMPLATE.md |
Diagram planning worksheet - fill out before writing mermaid code |
references/EXAMPLE.md |
Worked example: PM creating 4 diagrams for a product launch |
references/diagram-catalog.md |
All 15 diagram types: syntax, PM examples, limits, pitfalls |
references/pm-use-cases.md |
PM task → diagram type mapping with mini worked examples |
references/syntax-guide.md |
Complete syntax validity rules, escaping, styling, and validation checklist |
1---
2name: utility-mermaid-diagrams
3description: Teaches PMs to create syntactically valid mermaid diagrams by selecting the right diagram type for their communication need, following syntax validity rules, and validating before shipping. Covers all 15 mermaid diagram types with PM-relevant examples and a dual-lens navigation system.
4license: Apache-2.0
5metadata:
6 classification: utility
7 version: "1.1.0"
8 updated: 2026-07-05
9 category: documentation
10 frameworks:
11 - mermaid
12 author: product-on-purpose
13---
14
15<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
16
17# Mermaid Diagrams
18
19Create effective, syntactically valid mermaid diagrams for product documents.
20
21## When to Use
22
23- Creating mermaid diagrams for PRDs, specs, roadmaps, or stakeholder presentations
24- Choosing which of 15 diagram types fits a specific communication need
25- Debugging mermaid code that won't render or renders incorrectly
26- Reviewing diagrams for clarity, accuracy, and accessibility
27
28## When NOT to Use
29
30- Exporting diagrams to image files (PNG/SVG) - that's a rendering tool concern
31- Using non-mermaid diagramming tools (Figma, Lucidchart, draw.io)
32- Creating purely decorative visuals with no informational purpose
33- Producing a full customer-journey artifact (stages, touchpoints, emotional curve, pain points) rather than a standalone diagram - use `discover-journey-map`, which composes this skill for its timeline or flowchart section
34
35## The Cardinal Rule
36
37> Don't diagram what a list can say.
38
39Diagrams earn their place when they reveal **relationships**, **branching**, or **flow** that prose flattens. Before creating any diagram, ask:
40
41*Does this show branching, relationships, or flow that a list or table would flatten?*
42
43- **Yes** → proceed with a diagram
44- **No** → use a numbered list, bullet list, or table instead
45
46A 5-step linear process is a list. A 5-step process with two decision points and a retry loop is a diagram.
47
48## Diagram Selection Guide
49
50| I need to show... | Use | Also consider |
51|-------------------|-----|---------------|
52| A decision or approval process | Flowchart | State |
53| Multi-service or multi-party interactions | Sequence | Flowchart |
54| Feature lifecycle or status transitions | State | Flowchart |
55| Work stages or pipeline status | Kanban | State |
56| Release or sprint timeline with dependencies | Gantt | Timeline |
57| Version history or chronological milestones | Timeline | Gantt |
58| 2D prioritization (effort/impact, risk/value) | Quadrant | - |
59| Allocation breakdown or composition | Pie | Treemap |
60| Problem decomposition or brainstorming | Mindmap | - |
61| Domain models or data relationships | ER | Class |
62| API or object contracts | Class | ER |
63| System topology or infrastructure | Architecture | Flowchart |
64| Flow quantities or budget allocation | Sankey | Pie |
65| Hierarchical proportional data | Treemap | Pie |
66| Trends or time-series metrics | XY-Chart | - |
67
68For worked examples organized by PM task, see `references/pm-use-cases.md`.
69For full syntax and options per type, see `references/diagram-catalog.md`.
70
71## Syntax Validity Principles
72
73Six rules that prevent most rendering failures:
74
751. **Quote labels** - Any label containing spaces, parentheses, brackets, colons, commas, or reserved words must be quoted with double quotes
762. **Escape special characters** - Characters with mermaid or markdown meaning (`>`, `<`, `-` at line start, `#`) need escaping or quoting
773. **Declare before referencing** - Define a node before using it in an edge; referencing an undeclared node causes silent failures in some types
784. **Respect limits** - Each diagram type has a maximum node/participant count beyond which readability collapses (see `references/diagram-catalog.md` for per-type limits)
795. **Comment your intent** - Use `%%` comments to document non-obvious choices (why this layout direction, why this grouping)
806. **Test before shipping** - Paste into a mermaid renderer (mermaid.live, VS Code preview, or your target environment) and verify it renders correctly
81
82For the complete syntax reference, see `references/syntax-guide.md`.
83
84## Instructions
85
861. **Identify what you're communicating** - What relationship, flow, hierarchy, or proportion needs to be visible? Who is the audience?
872. **Apply the cardinal rule** - Confirm a diagram adds value over a list or table
883. **Select a diagram type** - Use the selection guide above, browse `references/pm-use-cases.md` by task, or browse `references/diagram-catalog.md` by type
894. **Plan the diagram** - Fill out the planning worksheet in `references/TEMPLATE.md`: purpose, audience, node inventory, type rationale
905. **Write the mermaid code** - Follow `references/syntax-guide.md` rules; start with the minimal syntax example from `references/diagram-catalog.md` and expand
916. **Validate** - Run through the quality checklist below
927. **Embed** - Place the validated mermaid code block in your document
93
94## Output Contract
95
96- **Planning artifact**: A completed diagram planning worksheet (`references/TEMPLATE.md`)
97- **Final output**: A syntactically valid mermaid code block embedded in the target document
98- **Quality gate**: All items in the quality checklist pass
99
100## Quality Checklist
101
102- [ ] Diagram renders without error in target environment
103- [ ] Cardinal rule satisfied - a list or table would not communicate this more clearly
104- [ ] No linear sequences without branching, relationships, or hierarchy
105- [ ] All labels with spaces or special characters are properly quoted
106- [ ] Special characters escaped where needed
107- [ ] Node/participant count within type-specific limits
108- [ ] Colors are accessible (WCAG AA 3:1 contrast minimum, black text on light backgrounds)
109- [ ] Color is never the sole differentiator - shapes and labels also distinguish elements
110- [ ] Diagram has a descriptive title or surrounding prose context
111- [ ] `%%` comments document any non-obvious layout or grouping choices
112
113## References
114
115| File | Purpose |
116|------|---------|
117| `references/TEMPLATE.md` | Diagram planning worksheet - fill out before writing mermaid code |
118| `references/EXAMPLE.md` | Worked example: PM creating 4 diagrams for a product launch |
119| `references/diagram-catalog.md` | All 15 diagram types: syntax, PM examples, limits, pitfalls |
120| `references/pm-use-cases.md` | PM task → diagram type mapping with mini worked examples |
121| `references/syntax-guide.md` | Complete syntax validity rules, escaping, styling, and validation checklist |
product-on-purpose