Markdown Mermaid Writing

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Mermaid Diagram Style Guide

For AI agents: Read this file for all core styling rules. Then use the diagram selection table to pick the right type and follow its link — each type has its own file with a production-quality exemplar, tips, and a copy-paste template.

For humans: This guide + the linked diagram files provide a starting point for readable diagrams; validate rendering and accessibility in the actual destination. Reference it from your AGENTS.md or contributing guide.

Target platform: Mermaid-capable Markdown; check the particular host and version. Verified renderer: Mermaid 12.0.0. See Current rendering and validation for CLI export, browser APIs, and accessibility results. These are house-style preferences, not Mermaid grammar or universal GitHub guarantees. All business workflows, endpoints, scores, and dates in examples are illustrative. Design goal: Minimal professional styling that renders beautifully in both GitHub light and dark modes, is accessible to screen readers, and communicates clearly with zero visual noise.

Quick Start for Agents

1. Pick the diagram type → Selection table

2. Open that type's file → Copy the template, fill in your content

3. Apply styling from this file → Emoji from approved set, colors from approved palette

4. Add accessibility → accTitle + accDescr (or italic Markdown paragraph for unsupported types)

5. Verify → Renders in light mode, dark mode, and screen reader

Core Principles

Accessibility Requirements

Use both annotations where the renderer supports them:

accTitle: Short Name 3-8 Words
accDescr: One or two sentences explaining what this diagram shows and what insight the reader gains from it

• accTitle — 3–8 words, plain text, names the diagram

• accDescr — 1–2 sentences; single-line form is convenient. Mermaid also supports accDescr { ... } across multiple lines

Mermaid 12.0.0 emits these annotations for flowchart, sequence, class, state, ER, gantt, pie, git graph, journey, requirement, quadrant, XY, architecture, packet, radar, and treemap. Block, kanban, mindmap, and Sankey need a visible text alternative. Timeline accepts annotations but the tested SVG omitted both; C4 omitted the SVG title. ZenUML is a separate plugin. See the tested matrix in Current rendering and validation. A paragraph does not automatically become an SVG accessible name; include meaningful image alt text when exporting, and a data table or detailed equivalent for complex figures.

ZenUML note: ZenUML requires an external plugin and may not render on GitHub. Prefer standard sequenceDiagram syntax.

Theme Configuration

✅ Do: No theme directive (GitHub auto-detects)

flowchart LR
    accTitle: Secure API Request Flow
    accDescr: Three-step API request from authentication through processing to response

    auth[🔐 Authenticate] --> process[⚙️ Process request] --> respond[📤 Return response]

Prefer host defaults unless custom styling is required

%% Custom colors may reduce contrast; inspect both themes
style A fill:#e8f5e9
%%{init: {'theme':'base'}}%%

Approved Emoji Set

One emoji per node, at the start of the label. Same emoji = same meaning across all diagrams in a project.

Systems & Infrastructure

Processes & Actions

People & Roles

Status & Outcomes

Information & Data

Domain-Specific

Emoji Rules

1. Place at start: [🔐 Authenticate] not [Authenticate 🔐]

2. Max one per node — never stack

3. Consistency is mandatory — same emoji = same concept across all diagrams

4. Not every node needs one — use on key nodes that benefit from visual distinction

5. No decorative emoji: 🎉 💯 🔥 🎊 💥 ✨ — they add noise, not meaning

Suggested Color Classes

Use only when you genuinely need color-coding (multi-actor diagrams, severity levels). Prefer shapes + emoji first.

Suggested palette (verify in your target light and dark themes):

Live preview — all 7 classes rendered:

flowchart LR
    accTitle: Color Palette Preview
    accDescr: Visual reference showing all seven approved classDef color classes side by side

    primary[🔵 Primary] ~~~ success[✅ Success] ~~~ warning[⚠️ Warning] ~~~ danger[❌ Danger]
    neutral[ℹ️ Neutral] ~~~ accent[🟣 Accent] ~~~ warm[🟠 Warm]

    classDef primary fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    classDef success fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    classDef warning fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
    classDef danger fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d
    classDef neutral fill:#f3f4f6,stroke:#6b7280,stroke-width:2px,color:#1f2937
    classDef accent fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
    classDef warm fill:#ffedd5,stroke:#ea580c,stroke-width:2px,color:#7c2d12

    class primary primary
    class success success
    class warning warning
    class danger danger
    class neutral neutral
    class accent accent
    class warm warm

Rules:

1. Always include color: (text color) — dark-mode backgrounds can hide default text

2. Use classDef + class where the diagram supports them. style is valid Mermaid syntax; C4 and sequence use different styling mechanisms

3. Max 3–4 color classes per diagram

4. Never rely on color alone — always pair with emoji, shape, or label text

Node Naming & Labels

Node Shapes

Use shapes consistently to convey node type without color:

Bold Text

Flowchart Markdown strings need double quotes around a backtick-delimited label:

flowchart LR
    accTitle: Markdown Label Example
    accDescr: Two pipeline stages, with the first label using Markdown emphasis.
    start["`Run **quality control**`"] --> finish["Review results"]

Plain labels such as node[**text**] do not reliably interpret emphasis. Other diagram types have their own formatting support; prefer plain labels unless tested.

Subgraphs

Subgraphs are the primary tool for organizing complex diagrams. They create visual groupings that help readers parse structure at a glance.

subgraph name ["📋 Descriptive Title"]
    node1 --> node2
end

Subgraph rules:

• Quoted titles with emoji: ["🔍 Code Quality"]

• Group by stage, domain, team, or layer — whatever creates the clearest mental model

• 2–6 nodes per subgraph is ideal; up to 8 if tightly related

• Subgraphs can connect to each other via edges between their internal nodes

• One level of nesting is acceptable when it genuinely clarifies hierarchy (e.g., a "Backend" subgraph containing "API" and "Workers" subgraphs). Avoid deeper nesting.

• Give every subgraph a meaningful ID and title — subgraph deploy ["🚀 Deployment"] not subgraph sg3

Connecting subgraphs — choose the right level of detail:

Use subgraph-to-subgraph edges when the audience needs the high-level flow and internal details would be noise:

subgraph build ["📦 Build"]
    compile --> package
end
subgraph deploy ["🚀 Deploy"]
    stage --> prod
end
build --> deploy

Use internal-node-to-internal-node edges when the audience needs to see exactly which step hands off to which:

subgraph build ["📦 Build"]
    compile --> package
end
subgraph deploy ["🚀 Deploy"]
    stage --> prod
end
package --> stage

Pick based on your audience:

Managing Complexity

Not every diagram is simple, and that's fine. The goal is clarity at every scale — a 5-node flowchart and a 30-node system diagram should both be immediately understandable. Use the right strategy for the complexity level.

Complexity tiers

When to use subgraphs vs. split into multiple diagrams

Use subgraphs when:

• The connections between groups are essential to understanding (splitting would lose that)

• A reader needs to see the full picture in one place (e.g., deployment pipeline, request lifecycle)

• Each group has 2–6 nodes and there are 3–5 groups total

Split into multiple diagrams when:

• Groups are mostly independent (few cross-group connections)

• The single diagram would exceed ~30 nodes even with subgraphs

• Different audiences need different views (overview for leadership, detail for engineers)

• The diagram is too wide/tall to read without scrolling

Use overview + detail pattern when:

• You need both the big picture AND the details

• The overview shows subgraph-level blocks with key connections

• Each detail diagram zooms into one subgraph with full internal structure

• Link them: "See Managing complexity for the full scaling guidance."

Best practices at any scale

• One primary flow direction per diagram — TB for hierarchies/processes, LR for pipelines/timelines. Mixed directions confuse readers.

• Decision points — keep to ≤3 per subgraph. If a single subgraph has 4+ decisions, it deserves its own focused diagram.

• Edge crossings — minimize by grouping tightly-connected nodes together. If edges are crossing multiple subgraphs chaotically, reorganize the groupings.

• Labels stay concise regardless of diagram size — 3–6 words per node, 1–4 words per edge. Complexity comes from structure, not verbose labels.

• Color-code subgraph purpose — in complex diagrams, use classDef classes to visually distinguish layers (e.g., all "data" nodes in one color, all "API" nodes in another). Max 3–4 classes even in large diagrams.

Composing multiple diagrams

When a single diagram isn't enough — multiple audiences, overview + detail needs, or before/after migration docs — see Composing Complex Diagram Sets for patterns and production-quality examples showing how to combine flowcharts, sequences, ER diagrams, and more into cohesive documentation.

Choosing the Right Diagram

Read the "best for" column, then follow the link to the type file for the exemplar diagram, tips, and template.

Pick the most specific type. Don't default to flowcharts — match your content to the diagram type that was designed for it. A sequence diagram communicates service interactions better than a flowchart ever will.

Known Parser Gotchas

These will save you debugging time:

Quality Checklist

Every Diagram

• [ ] accTitle + accDescr present (or italic Markdown paragraph for unsupported types)

• [ ] Complexity managed: ≤10 nodes flat, 10–30 with subgraphs, 30+ split into multiple diagrams

• [ ] Subgraphs used if >10 nodes (grouped by stage, domain, team, or layer)

• [ ] ≤3 decision points per subgraph

• [ ] Semantic snake_case IDs

• [ ] Labels: 3–6 words, active voice, sentence case

• [ ] Edge labels: 1–4 words

• [ ] Consistent shapes for consistent meanings

• [ ] Single primary flow direction (TB or LR)

• [ ] Per-type style syntax and readable contrast verified

• [ ] Minimal edge crossings (reorganize groupings if chaotic)

If Using Color/Emoji/Bold

• [ ] Colors from approved palette using classDef + class

• [ ] Text color: included in every classDef

• [ ] ≤4 color classes

• [ ] Emoji from approved set, max 1 per node

• [ ] Bold on max 1–2 words per node

• [ ] Meaning never conveyed by color alone

Before Merge

• [ ] Renders in GitHub light mode

• [ ] Renders in GitHub dark mode

• [ ] Emoji meanings consistent across all diagrams in the document

Testing

1. Destination: Preview in the actual host and toggle its light/dark appearance. Do not publish solely to run a rendering test.

2. Local: Run the pinned CLI examples in Current rendering and validation. Editor preview extensions may bundle another Mermaid version.

3. Live editor: mermaid.live — paste and toggle themes

4. Screen reader: Verify accTitle/accDescr announced (VoiceOver, NVDA, JAWS)

Resources

• Markdown Style Guide — Formatting, citations, and document structure for the markdown that wraps your diagrams

• Mermaid Docs · Live Editor · Accessibility · GitHub Support · Mermaid CLI