Diagrams
Generate diagrams and visuals from code or descriptions. Use when the user needs a rendered diagram, code visualization, or architecture image. Subcommands — excalidraw (hand-drawn), drawio (formal XML), paper (academic illustrations), gitdiagram (repo architecture), yoshida (atmospheric Hiroshi Yoshida woodblock hero art).From its SKILL.md
npx -y skills add SamyakJhaveri/loam --skill diagramsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.1 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it
Diagrams — The Visual Stack
Generate diagrams using one of several specialized tools, each suited to different use cases.
Arguments
$ARGUMENTS — one of:
excalidraw <description>— hand-drawn Excalidraw diagrams with visual self-validationdrawio [format] <description>— native draw.io XML diagrams with optional PNG/SVG/PDF exportpaper <description>— publication-quality academic illustrations via PaperBananagitdiagram <github-url>— interactive architecture diagram from any GitHub repoyoshida <concept-slug>— render a Yoshida-style Track B atmospheric hero image for a concept defined indocs/diagrams/concepts.yaml<free-form text>— auto-classify intent and route to the appropriate tool
Output Convention
All outputs go to docs/diagrams/. Run mkdir -p docs/diagrams before writing any output.
Phase 1: Parse & Route
Parse $ARGUMENTS and match the FIRST word:
excalidraw→ Phase 2Adrawio→ Phase 2Bpaper→ Phase 2Cgitdiagram→ Phase 2Dyoshida→ Phase 2F- Anything else → Phase 2E (free-form classification)
Subcommand dispatch is deterministic — do not use LLM reasoning when a keyword is present.
Phase 2A: Excalidraw (Layer 3)
Generate hand-drawn style Excalidraw diagrams. Two integration paths:
Path 1: Cloud Excalidraw MCP (if available — no setup required)
Check if Excalidraw MCP tools are available in the current environment (look for create_view, export_to_excalidraw). These are provided automatically by claude.ai — no local setup needed.
If available:
- Call the MCP's
read_metool once to load the element format reference (color palette, element types, camera control, dark mode) - Use
create_viewto generate the diagram — elements stream in with draw-on animations - Optionally use
export_to_excalidrawto upload to excalidraw.com for a shareable/editable link - Use
save_checkpoint/read_checkpointfor iterative refinement across turns
Path 2: Local excalidraw-diagram skill (fallback)
If no cloud MCP is available, check for the local skill:
ls .claude/skills/excalidraw-diagram/SKILL.md 2>/dev/null || echo "Not installed"
If not installed, tell the user:
Install with:
git clone https://github.com/coleam00/excalidraw-diagram-skill.git /tmp/eds && mkdir -p .claude/skills/excalidraw-diagram && cp -r /tmp/eds/SKILL.md /tmp/eds/references .claude/skills/excalidraw-diagram/ && cd .claude/skills/excalidraw-diagram/references && uv sync && uv run playwright install chromium
If installed, delegate to the excalidraw-diagram skill directly — it handles the full workflow: concept mapping → JSON generation → PNG rendering → visual validation → iterative refinement.
Phase 2B: Draw.io (MCP or CLI — Layer 1/2)
Generate native .drawio XML diagrams. Two integration paths:
Path 1: MCP server (if drawio MCP is configured)
Generate the XML, then open it in the draw.io editor using MCP tools:
open_drawio_xml— opens native draw.io/mxGraph XML in the editoropen_drawio_csv— converts CSV tabular data into a diagramopen_drawio_mermaid— converts Mermaid syntax into an editable draw.io diagram
All three accept a content string and optional lightbox (read-only) and dark mode params.
Path 2: Direct XML generation (no MCP needed)
- Generate draw.io mxGraphModel XML directly.
- Write to
docs/diagrams/<subject>.drawio. - If the user requested a format (png, svg, pdf), export:
# macOS /Applications/draw.io.app/Contents/MacOS/draw.io --export --format png --embed-diagram docs/diagrams/<subject>.drawio # Linux drawio --export --format png --embed-diagram docs/diagrams/<subject>.drawio - The
--embed-diagramflag keeps the XML inside the exported file so it remains editable in draw.io.
Critical draw.io XML rules:
- Never include XML comments
- Escape special characters:
&,<,>," - Unique
idfor everymxCell - Every edge needs a child
<mxGeometry>element - Root requires cells
id="0"(root) andid="1"(default parent)
See reference.md for the XML generation guide and shape reference.
Phase 2C: PaperBanana (Track A — manual, external tool — Layer 3)
External tool — Claude Code cannot run it directly. Direct the user to the HuggingFace Space for zero-setup use, or to the GitHub repo for self-hosting. See reference.md §3.
Phase 2D: GitDiagram (web service — Layer 3)
External web service — Claude Code cannot run it directly. Tell the user to replace hub with diagram in any GitHub URL (e.g. gitdiagram.com/user/repo). See reference.md §4.
Phase 2E: Free-form Classification (Layer 3)
When no subcommand prefix is matched, classify intent:
| Signal | Route to |
|---|---|
| Hand-drawn, sketch, whiteboard, Excalidraw | excalidraw |
| Flowchart, ER, sequence, architecture, export to PNG/SVG/PDF, draw.io | drawio |
| Academic, paper, publication, scientific illustration, research figure | paper (research projects only — ask user to confirm) |
| GitHub repo URL, repo architecture, codebase overview | gitdiagram |
If ambiguous, ask the user to clarify.
Phase 2F: Yoshida (Track B — Layer 3)
The automated Track B path: atmospheric hero art in Hiroshi Yoshida's shin-hanga
woodblock style, rendered via the Gemini Image API (gemini-3-pro-image). This is the
automated counterpart to PaperBanana's manual Track A in Phase 2C — here the render runs from
a committed repo script rather than a human in a browser.
Invocation:
uv run .claude/skills/diagrams/scripts/render-yoshida.py --concept <slug> --candidates 2
GEMINI_API_KEYmust be set. If it is unset, the script prints a clearSKIPline and exits cleanly with no render (the scaffold stays intact). Set the key before a real render.- References are optional. They come from a local
yoshida_hiroshi/directory (gitignored) — the prose prompt carries the style on its own, but local references boost fidelity when present. The model accepts at most 6 references per concept; the script hard-fails rather than silently truncate a longer list, and warns (without failing) on a missing file. - Label discipline. Yoshida prints carry almost no text. For label-heavy concepts, get the
labels from Track A (PaperBanana) or a
drawio/excalidrawvector overlay, not the image model — deterministic text belongs in a deterministic layer. - Full method. See
design-language.mdfor the two-track design language, the canonical Yoshida preamble, the style principles, label discipline, the reference-image guidance, and the Track A 3-field recipe. - Quality gate. See
quality-gate.mdfor the concept contract, label-strategy routing, and candidate critique rubric used before marking renders as keep.
render-yoshida.py is a committed repo script, not generated at runtime, so invoking it does
not trip Rule 1 below. It does make a real, paid Gemini API call once GEMINI_API_KEY is set
— run it only with the user's awareness.
Rules
- Never execute user-generated or AI-generated scripts without explicit user confirmation
- All diagram outputs go to
docs/diagrams/— create the directory if it doesn't exist - Subcommand dispatch is deterministic — do not use LLM reasoning when a keyword is present
- If a required tool is not installed, tell the user how to install it and stop — do not attempt workarounds
- For draw.io XML, validate structure before writing (unique IDs, proper escaping, required root cells)
What ships with it: 5 files
30.0 KB alongside SKILL.md, 1 of them executable
scripts/
- render-yoshida.pyruns8.3 KB
- concepts.template.yaml3.1 KB
- design-language.md9.1 KB
- quality-gate.md2.2 KB
- reference.md7.3 KB