Utility Mermaid Diagrams

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

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

• [ ] Diagram renders without error in target environment
• [ ] Cardinal rule satisfied - a list or table would not communicate this more clearly
• [ ] No linear sequences without branching, relationships, or hierarchy
• [ ] All labels with spaces or special characters are properly quoted
• [ ] Special characters escaped where needed
• [ ] Node/participant count within type-specific limits
• [ ] Colors are accessible (WCAG AA 3:1 contrast minimum, black text on light backgrounds)
• [ ] Color is never the sole differentiator - shapes and labels also distinguish elements
• [ ] Diagram has a descriptive title or surrounding prose context
• [ ] %% comments document any non-obvious layout or grouping choices

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 |