mermaid-diagram skill

Mermaid Diagram Generator

Generate high-quality Mermaid diagram code based on user requirements, with file output and verification.

Constants

• OUTPUTDIR = figures/** — Output directory for all generated files
• MAXITERATIONS = 3** — Maximum refinement rounds for syntax errors

Workflow: MUST EXECUTE ALL STEPS

Step 0: Pre-flight Check

# Create output directory
mkdir -p figures

Step 1: Understand Requirements & Select Diagram Type

Parse the input: $ARGUMENTS

1. Analyze user description to determine the most suitable diagram type
2. Read the corresponding syntax reference documentation (see Diagram Type Reference below)
3. If the diagram involves mathematical notation (formulas, equations, Greek letters, subscripts, superscripts, fractions, matrices, etc.), apply the math syntax rules from the Math Formulas in Diagrams section below
4. Identify all components, connections, and data flow
5. Plan the diagram structure

Step 2: Read Documentation

Select the appropriate diagram type based on the use case. Use your built-in knowledge of Mermaid syntax, or fetch up-to-date docs via the context7 MCP server if needed.

Configuration & Themes

• Theming - Custom colors and styles
• Directives - Diagram-level configuration
• Layouts - Layout direction and spacing
• Configuration - Global settings
• Math - LaTeX math support (see Math Formulas in Diagrams section below)

Step 3: Generate Mermaid Code & Save Files

Generate the Mermaid code following the reference specification, then save TWO files:

File 1: figures/.mmd — Raw Mermaid source

The .mmd file contains ONLY the raw Mermaid code (no markdown fences). Example:

flowchart TD
    A[Start] --> B{Condition}
    B -->|Yes| C[Execute]
    B -->|No| D[End]
    C --> D

File 2: figures/.md — Markdown with embedded Mermaid

The .md file wraps the same code in a mermaid code block for preview rendering, plus a title and description. Example:

# Diagram Title

Brief description of what this diagram shows.

​```mermaid
flowchart TD
    A[Start] --> B{Condition}
    B -->|Yes| C[Execute]
    B -->|No| D[End]
    C --> D
​```

Naming convention: Use a descriptive kebab-case name derived from the user's request (e.g., auth-flow, system-architecture, database-er).

Step 4: Verify Mermaid Syntax (MANDATORY)

Claude MUST verify the generated Mermaid code by running the Mermaid CLI (mmdc).

# Check if mermaid-cli is available
if command -v mmdc &> /dev/null; then
    # Render to PNG to verify syntax is correct
    mmdc -i figures/<diagram-name>.mmd -o figures/<diagram-name>.png -b transparent
    echo "✅ Syntax valid — PNG rendered to figures/<diagram-name>.png"
else
    # Try npx as fallback
    npx -y @mermaid-js/mermaid-cli@latest -i figures/<diagram-name>.mmd -o figures/<diagram-name>.png -b transparent
    echo "✅ Syntax valid — PNG rendered to figures/<diagram-name>.png"
fi

If the verification fails:

1. Read the error message carefully
2. Fix the syntax issue in both .mmd and .md files
3. Re-run verification
4. Repeat up to MAX_ITERATIONS (3) times

Step 5: Claude STRICT Visual Review & Scoring (MANDATORY)

After successful rendering, Claude MUST read the generated PNG and perform a STRICT review:

## Claude's STRICT Review of <diagram-name>

### What I See
[Describe the rendered diagram in DETAIL - every block, every arrow, every label]

### Files Generated
- `figures/<diagram-name>.mmd` — Raw Mermaid source
- `figures/<diagram-name>.md` — Markdown with embedded diagram
- `figures/<diagram-name>.png` — Rendered PNG (if mmdc available)

### ═══════════════════════════════════════════════════════════════
### STRICT VERIFICATION CHECKLIST (ALL must pass for score ≥ 9)
### ═══════════════════════════════════════════════════════════════

#### A. File Correctness
- [ ] `.mmd` file contains valid Mermaid syntax (no markdown fences)
- [ ] `.md` file has the mermaid code wrapped in ```mermaid``` fences
- [ ] `.mmd` and `.md` contain IDENTICAL Mermaid code
- [ ] Diagram renders without errors (via mmdc)

#### B. Arrow Correctness Verification (CRITICAL - any failure = score ≤ 6)
Check EACH arrow:
- [ ] Arrow 1: [Source] → [Target] — Does it point to the CORRECT target?
- [ ] Arrow 2: [Source] → [Target] — Does it point to the CORRECT target?
- [ ] ... (check ALL arrows)

#### C. Block Content Verification (any failure = score ≤ 7)
Check EACH block/node:
- [ ] Block 1 "[Name]": Has cor

If FIX: apply corrections to both .mmd and .md files, re-render, and re-verify. Loop until ACCEPT or MAXITERATIONS reached.**

Step 6: Final Output Summary

When accepted, present to user:

✅ Mermaid diagram generated successfully!

Files:
  figures/<diagram-name>.mmd  — Raw Mermaid source (use with mmdc, editors, CI)
  figures/<diagram-name>.md   — Markdown preview (renders on GitHub, VS Code, etc.)
  figures/<diagram-name>.png  — Rendered image (if mmdc was available)

To re-render manually:
  mmdc -i figures/<diagram-name>.mmd -o figures/<diagram-name>.png

Architecture Diagram Best Practices

When generating architecture-beta diagrams, apply these layout techniques for complex diagrams:

Use Junctions for Layout Control

Think of the diagram as an invisible grid. Use junction nodes as virtual anchor points on that grid to precisely control where each component is placed. This is especially useful when a direct edge between two services produces unexpected positioning.

Instead of connecting services directly:

lb:R --> L:scim
lb:R --> L:webapi

Route through junctions to control vertical/horizontal placement:

junction j_lb_r
lb:R -- L:j_lb_r
junction j_scim_l
j_lb_r:T -- B:j_scim_l
j_scim_l:R --> L:scim
junction j_webapi_l
j_lb_r:B -- T:j_webapi_l
j_webapi_l:R --> L:webapi

Place junctions on all four sides of components to anchor them logically on the grid.

Use Edges out of Groups for Floating Components

For services that have no logical connection to other nodes (e.g. a deployment tool, a monitoring agent), use a junction combined with the {group} modifier to position them without adding a semantically incorrect edge:

junction j_acd_t
j_algolia_proc_b{group}:B -- T:j_acd_t
j_acd_t:B -- T:acd

This anchors acd below its intended neighbor without implying a real relationship.

CVPR/ICLR/NeurIPS Style Guide (for Academic Diagrams)

When the diagram is intended for academic papers, apply these style standards:

Visual Standards

• Clean white background — No decorative patterns or gradients (unless subtle)
• Sans-serif fonts — Arial, Helvetica, or Computer Modern; minimum 14pt
• Subtle color palette — Not rainbow colors; use 3-5 coordinated colors
• Print-friendly — Must be readable in grayscale (many reviewers print papers)
• Professional borders — Thin (2-3px), solid colors, not flashy

Layout Standards

• Horizontal flow — Left-to-right is the standard for pipelines
• Clear grouping — Use subtle background boxes to group related modules
• Consistent sizing — Similar components should have similar sizes
• Balanced whitespace — Not cramped, not sparse

Arrow Standards (MOST CRITICAL)

• Thick strokes — 4-6px minimum (thin arrows disappear when printed)
• Clear arrowheads — Large, filled triangular heads
• Dark colors — Black or dark gray (#333333); avoid colored arrows
• Labeled — Every arrow should indicate what data flows through it
• No crossings — Reorganize layout to avoid arrow crossings
• CORRECT DIRECTION — Arrows must point to the RIGHT target!

Color Palette (Academic Professional)

• Inputs: Green (#10B981 / #34D399)
• Encoders: Blue (#2563EB / #3B82F6)
• Fusion: Purple (#7C3AED / #8B5CF6)
• Outputs: Orange (#EA580C / #F97316)
• Arrows: Black or dark gray (#333333 / #1F2937)
• Background: Pure white (#FFFFFF)

What to AVOID

• Rainbow color schemes (too many colors)
• Thin, hairline arrows
• Heavy drop shadows or glowing effects
• 3D effects / perspective
• Excessive decorative icons
• Small text that's unreadable when printed