curiositech/some_claude_skills

mermaid-graph-renderer

Renders Mermaid diagrams to SVG, PNG, and PDF in both web and offline contexts. Covers client-side lazy loading, SSR trade-offs, CLI batch export, and native Rust rendering. Use when exporting diagrams to images, optimizing Mermaid rendering performance on web pages, setting up CI/CD diagram pipelines, or choosing a rendering library. Activate on "render mermaid", "export diagram", "mermaid to png", "mermaid to svg", "mermaid performance", "diagram export". NOT for writing Mermaid syntax (use m…

First seen Mar 9, 2026

Installation

$ npx skills add curiositech/some_claude_skills --skill mermaid-graph-renderer

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from curiositech/some_claude_skills · top by installs.

npx skills add curiositech/some_claude_skills

Browse all from curiositech/some_claude_skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 216
License LICENSE
Default branch main
Open issues 37
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Allowed toolsRead,Write,Edit,Bash
More metadata
category
Content & Writing
tags
[]
0
mermaid
1
graph
2
renderer
3
render-mermaid
4
export-diagram
pairs-with
[]
5
skill: mermaid-graph-writer
reason
Rendered Mermaid diagrams are embedded in generated PDF documentation
6
skill: diagramming-expert
7
skill: document-generation-pdf

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 10,092 B
  • docs SUMMARY.md 608 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 135 installs

SKILL.md

Mermaid Graph Renderer

Renders Mermaid diagrams to production-quality SVG, PNG, and PDF in web and offline contexts. Covers the full spectrum from lazy-loaded client-side rendering to 1000x-faster native Rust batch export.

Core Constraint

Mermaid.js requires browser APIs (document.createElement, SVGTextElement.getBBox()) to compute text dimensions. Every non-browser rendering path must either embed a headless browser or reimplement the renderer from scratch. This constraint shapes every decision below.


When to Use

Use for:

  • Rendering Mermaid diagrams on web pages (performance-optimized)
  • Exporting diagrams to SVG, PNG, or PDF (offline/CLI)
  • Setting up CI/CD pipelines that generate diagram images
  • Choosing between rendering libraries for a project
  • Optimizing Mermaid load time on documentation sites

NOT for:

  • Writing Mermaid syntax (use mermaid-graph-writer)
  • Rendering non-Mermaid formats (PlantUML, GraphViz — see Kroki)
  • General image processing or manipulation

Rendering Decision Tree

flowchart TD
  A{Where are you rendering?} -->|Browser| B{Performance matters?}
  A -->|CLI / CI| C{Volume?}
  A -->|Server-side| D{Must avoid client JS?}

  B -->|Yes| E[Lazy-load mermaid.js]
  B -->|No| F[CDN script tag]

  C -->|1-10 diagrams| G[mermaid-cli]
  C -->|10-100 diagrams| H{Need multiple formats?}
  C -->|100+ diagrams| I[mmdr Rust renderer]

  H -->|Mermaid only| G
  H -->|Multiple languages| J[Kroki]

  D -->|Yes, zero JS| K[Build-time with Puppeteer]
  D -->|Some JS OK| E
  K -->|Slow builds warning| L[rehype-mermaid + Playwright]

Web Rendering

Option 1: Lazy-Loaded mermaid.js (Recommended)

Best for documentation sites, blogs, and apps where only some pages have diagrams.

How it works: Check for .mermaid elements before loading the library. The ~480 KB cost is only paid on pages that actually need it.

// Lazy load pattern — only loads mermaid.js when diagrams exist
function initMermaid() {
  const diagrams = document.querySelectorAll('.mermaid');
  if (diagrams.length === 0) return;

  const script = document.createElement('script');
  script.src = 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.min.js';
  script.onload = () => {
    mermaid.initialize({ startOnLoad: false, theme: 'neutral' });
    mermaid.run({ nodes: diagrams });
  };
  document.head.appendChild(script);
}

// Handle initial load + SPA navigation
document.addEventListener('DOMContentLoaded', initMermaid);
// For SPA route changes: call initMermaid() after navigation

Key detail: Handle both initial page load AND client-side navigation (SPA route changes) by re-running mermaid.run() when new diagram content appears.

Aspect Value
Bundle size ~480 KB (core + lazy diagram chunks)
Render time ~50-200 ms per diagram (client)
Diagram coverage Full (all Mermaid types)
Best for Docs sites, blogs, apps with occasional diagrams

Option 2: @mermaid-js/tiny

Pre-bundled subset for CDN use. All diagram types included upfront (no lazy-loading of diagram chunks). Smaller total but loaded eagerly.

Use when: You know exactly which 1-2 diagram types you need and want a single-file import.

Option 3: Build-Time SSR (Usually Not Worth It)

Render SVGs at build time using Puppeteer/Playwright. Sounds appealing; painful in practice.

Costs:

  • Adds ~280 MB to node_modules (Puppeteer + Chromium)
  • ~2-3 seconds per diagram to spin up and render
  • A 5-second build becomes 45 seconds for ~30 diagrams
  • Docker/CI headaches (Chrome needs to be installed)

When actually worth it: Strict zero-JS requirements, or sites with hundreds of diagrams where you want to eliminate client-side rendering entirely.

Tools: rehype-mermaid (uses Playwright), rehype-mermaid-cli (wraps official CLI).

Verdict: Unless you have strict zero-JS requirements, lazy-loaded client-side rendering is the better trade-off.


Offline / CLI Rendering

Option 1: mermaid-cli (Official)

The canonical CLI tool. Launches headless Chromium, renders, captures output.

# Install
npm install -g @mermaid-js/mermaid-cli

# Basic usage
mmdc -i input.mmd -o output.svg
mmdc -i input.mmd -o output.png -b transparent
mmdc -i input.mmd -o output.pdf

# With config
mmdc -i input.mmd -o output.svg -t dark --configFile mermaid.config.json

# Batch: process Markdown with embedded diagrams
mmdc -i document.md -o document-with-images.md

# Docker
docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.svg
Aspect Value
Speed ~3000 ms per diagram (Chromium overhead)
Output SVG, PNG, PDF
Size ~280 MB (Puppeteer + Chromium)
Coverage Full (all Mermaid types, 100% parity)
Best for 1-50 diagrams, when accuracy matters most

SVG gotcha: Output SVGs contain <foreignObject> elements that break in Inkscape and rsvg-convert. Fix: set "htmlLabels": false in config, or export to PNG instead.

Option 2: Kroki (Multi-Format Gateway)

Unified HTTP API that routes diagram source to appropriate rendering engine. Supports 25+ languages (Mermaid, PlantUML, GraphViz, D2, Excalidraw, etc.).

# Render via HTTP (self-hosted or kroki.io)
curl -X POST https://kroki.io/mermaid/svg \
  -H 'Content-Type: text/plain' \
  -d 'flowchart LR
    A --> B --> C' \
  -o diagram.svg

# Self-host via Docker Compose
# docker-compose.yml needs: yuzutech/kroki + yuzutech/kroki-mermaid
Aspect Value
Speed ~500-2000 ms (network + render)
Output SVG, PNG, PDF, JPEG
Languages 25+ (Mermaid, PlantUML, GraphViz, D2, etc.)
Best for Multi-language pipelines, CI/CD, documentation generators

When Kroki wins: You need multiple diagram languages in one pipeline. When it doesn't: Simple "render one Mermaid diagram" — overkill.

Option 3: mmdr (Native Rust — Fastest)

Native Rust reimplementation. No browser, no Node.js. ~1000x faster than mermaid-cli.

# Install (Rust toolchain required)
cargo install mmdr

# Usage
mmdr input.mmd -o output.svg
mmdr input.mmd -o output.png  # via resvg, no browser
Aspect Value
Speed ~3 ms per diagram (1000x faster)
Output SVG (native), PNG (via resvg)
Size ~5-10 MB binary
Coverage 13 diagram types (partial parity)
Best for Batch processing 100+ diagrams, CI/CD speed

Trade-off: Not all Mermaid features are supported yet. Flowcharts and sequence diagrams are mature; other types vary. Accept imperfection for speed, or fall back to mermaid-cli for edge cases.

No <foreignObject> issue: Uses native SVG text, so output works with Inkscape and other SVG tools.


Comparison Matrix

Criterion mermaid.js CDN mermaid-cli Kroki mmdr (Rust)
Runtime Browser Node + Puppeteer Docker Native binary
Speed/diagram ~100 ms ~3000 ms ~1000 ms ~3 ms
SVG quality Excellent Excellent Excellent Good (improving)
PNG quality N/A Good Good Good (resvg)
PDF export N/A Yes Yes Not yet
Install size ~480 KB ~280 MB ~1 GB (Docker) ~5-10 MB
Diagram coverage Full Full Full 13 types
CI/CD fit Poor Moderate Good Excellent
Multi-language No No Yes (25+) No

Recommendations by Use Case

Use Case Recommendation Why
Docs site with occasional diagrams Lazy-loaded mermaid.js Only loads on pages that need it
Next.js / SSR app Dynamic import, ssr: false Don't fight build-time rendering
CI/CD generating static docs (Mermaid only) mmdr for speed, mermaid-cli for accuracy 1000x faster vs. 100% feature parity
CI/CD with multiple diagram languages Kroki One API for PlantUML + Mermaid + GraphViz
Batch export for print/PDF (100+ diagrams) mmdr + mermaid-cli fallback Fast for most, accurate for edge cases
Desktop apps (Electron/Obsidian/VS Code) Built-in mermaid.js Chromium already embedded

Anti-Patterns

SSR Obsession

Wrong: Spending 3 days setting up Puppeteer in CI to avoid 480 KB of client JS. Right: Lazy-load mermaid.js. The 480 KB is only fetched on pages with diagrams. Most users won't notice.

foreignObject Surprise

Wrong: Exporting SVGs from mermaid-cli and wondering why Inkscape can't open them. Right: Set "htmlLabels": false in config, or export to PNG directly.

One Tool for Everything

Wrong: Using mermaid-cli for 500 diagrams in CI (25 minutes of build time). Right: Use mmdr for batch, mermaid-cli for the few diagrams that need full parity.