agentleFS
qa-amanqa-aman/claude-skills/skills/shared/diagram-generator/SKILL.md

diagram-generator

Skill24 starsChanged 9 months agoMITView on GitHub

Generate diagrams of any kind from a description, ticket, spec, or file. Outputs Mermaid syntax (renders natively in GitHub, Notion, Confluence, Obsidian, Slack with apps) plus an optional single-file HTML preview that renders the diagram in the browser.

16 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use attack-chain, binary-diff and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • DorianGalloSkill

    attack-chain

    Also in 6 projects that use this

  • DorianGalloSkill

    binary-diff

    跨版本符号迁移与二进制差分。当你有旧版本的符号/逆向结果,需要快速迁移到新版本时使用。 适用场景:内核缺 PDB 用旧版符号推导、程序更新后批量迁移函数名、应用更新后快速定位新偏移。 核心方法:用 LLM 做结构化差异比对,程序化输入输出,成本极低(200 函数 ~1 元)。 触发关键词:符号迁移、bindiff、跨版本、PDB 缺失、函数偏移迁移、symbol migration、binary diff、版本对比。

    Also in 6 projects that use this

  • Roshu18Skill

    pentest-tools

    Tool selection policy for BearStrike based on target type, scan risk, and signal strength.

    Also in 7 projects that use this

  • hardw00tSkill

    llm-security

    LLM and AI application security testing skill for prompt injection (direct, indirect, multimodal), system-prompt extraction, RAG poisoning, memory poisoning, MCP server injection, skill-file injection, agentic tool misuse, computer-use UI injection, and excessive agency. Authorization required — this skill tests AI systems you are explicitly permitted to assess. Triggers on requests to test LLM / AI-agent / RAG / MCP / computer-use security, perform prompt injection, extract system prompts, poison RAG or memory, audit agent tool use, or evaluate AI guardrails.

    Also in 6 projects that use this

  • +8 more from DorianGallo

The file

Show its rules and text

We split this skill into the rules it gives an agent

27 rules. 0 are common, 13 are distinctive, and 14 are very specific to this project.

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 14

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the input is unambiguous, pick directly.

    line 30
  2. Distinctive:

    If multiple distinct scenarios exist (e.g., happy path + error path), produce SEPARATE diagrams rather than one mega-diagram.

    line 63
  3. Distinctive:

    Always wrap output in:

    line 67
  4. Distinctive:

    Follow the type-specific rules below.

    line 74
  5. Distinctive:

    After printing the Mermaid block, ask: *"Want me to generate a single-file HTML preview that renders this locally?"*

    line 78
  6. Very specific:

    If yes, write diagram.html to the current directory using the template under "HTML preview template" below.

    line 80
  7. Very specific:

    Line breaks in labels: ALWAYS <br>, NEVER \n.

    line 86
  8. Very specific:

    Use participant X as Display Name to set readable labels.

    line 107
  9. Very specific:

    Use ->> for sync, -->> for async, --x for failed.

    line 108
  10. Very specific:

    Use Note over X,Y: text for callouts.

    line 109
  11. Very specific:

    Use loop, alt / else, par, opt for control flow.

    line 110
  12. Very specific:

    Use activate X / deactivate X to show lifelines.

    line 111
  13. Very specific:

    Use [*] --> StateName for start, StateName --> [*] for end.

    line 115
  14. Very specific:

    Use state ChoiceName <<choice>> for branching.

    line 116
  15. Very specific:

    Use composite states for nesting: state Group { ...

    line 117
  16. Distinctive:

    Use lowercase plural entity names.

    line 122
  17. Very specific:

    Always start with dateFormat YYYY-MM-DD.

    line 141
  18. Distinctive:

    No header. Comma-separated.

    line 148
  19. Distinctive:

    If multiple diagrams (e.g., happy + error paths), use a header per diagram and render each separately.

    line 180
  20. Distinctive:

    When the user asks for a local preview, write this single file (no build, no npm.

    line 184
  21. Distinctive:

    Don't pick the wrong diagram type to "force fit" the input — ask if it's ambiguous.

    line 221
  22. Distinctive:

    Don't cram multiple scenarios into one diagram.

    line 222
  23. Very specific:

    Don't use \n for line breaks in flowchart node labels — always <br>.

    line 223
  24. Distinctive:

    Don't put quotes, colons, or pipes inside node labels (they break Mermaid).

    line 224
  25. Very specific:

    Don't skip the style lines on flowcharts — color coding makes diagrams scannable.

    line 225
  26. Very specific:

    Don't reach for D3, ReactFlow, or custom HTML.

    line 226
  27. Distinctive:

    Don't auto-generate the HTML preview unless the user asks — most users just want the Mermaid block.

    line 227

“Common” is measured: kept by at least 6 in 10 of the 14 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Diagram Generator

Turn any input into a clean diagram. Supports the full Mermaid diagram set so one skill handles flowcharts, sequence diagrams, state machines, ER diagrams, journeys, mindmaps, timelines, gantt charts, sankey, quadrants, class diagrams, and git graphs.

Inputs

  • Ticket / PRD / spec — read it and pick the right diagram type.
  • File path — read the file and diagram from contents.
  • Verbal description — diagram directly from the prompt.
  • Existing diagram — refactor / restyle / fix.

Workflow

Step 1 — Pick the diagram type

If the input is unambiguous, pick directly. Otherwise ask which fits best:

User intentMermaid type
Process flow, decision tree, "if X then Y"flowchart
API calls, message passing, who-talks-to-whom over timesequenceDiagram
Object lifecycle, finite-state machinestateDiagram-v2
Database schema, entities + relationshipserDiagram
End-to-end customer/user experience with sentimentjourney
Hierarchical brainstorm, taxonomy, idea treemindmap
Dated events, milestonestimeline
Project schedule with durations + dependenciesgantt
Flow of quantity between sources/targetssankey-beta
2x2 categorization (importance/urgency, effort/impact)quadrantChart
OOP class hierarchy with methodsclassDiagram
Git branching strategygitGraph

Step 2 — Extract the diagram content

From the input, pull out the right primitives for the chosen type:

  • Flowchart: decision points, actions, states, edge cases, scenarios.
  • Sequence: actors, messages, ordering, async vs sync.
  • State: states, transitions, triggers, terminal states.
  • ER: entities, attributes, relationships, cardinality.
  • Journey: stages, tasks per stage, sentiment scores.
  • Mindmap: root concept + branches.
  • Timeline: sections + events per section.
  • Gantt: sections + tasks with dates/durations + dependencies.
  • Sankey: source → target → value rows.
  • Quadrant: axis labels + items with (x, y) scores.
  • Class: classes + members + inheritance/composition.
  • GitGraph: branches, commits, merges.

If multiple distinct scenarios exist (e.g., happy path + error path), produce SEPARATE diagrams rather than one mega-diagram.

Step 3 — Emit Mermaid syntax

Always wrap output in:

```mermaid
{type-specific code}
```

Follow the type-specific rules below.

Step 4 — Offer a preview file (optional)

After printing the Mermaid block, ask: "Want me to generate a single-file HTML preview that renders this locally?"

If yes, write diagram.html to the current directory using the template under "HTML preview template" below.

Type-specific rules

Flowchart

  • Line breaks in labels: ALWAYS <br>, NEVER \n.
  • Node shapes:
    • ([text]) — start / end (stadium)
    • [text] — action / process
    • {text} — decision
    • [[text]] — subroutine
    • [(text)] — database
    • ((text)) — circle (event)
  • Direction: flowchart TD for processes, flowchart LR for timelines/pipelines.
  • Edge labels: -- text --> for conditional paths.
  • Colors (apply via style lines at the end):
    • fill:#4CAF50,color:#fff — success / start (green)
    • fill:#EF5350,color:#fff — error / blocked (red)
    • fill:#FF9800,color:#fff — warning / modified (orange)
    • fill:#2196F3,color:#fff — informational (blue)
  • Subgraphs: group related items with subgraph Name ... end.
  • No special characters (quotes, colons, pipes) inside node labels.
  • Node text: max 4 lines.

Sequence diagram

  • Use participant X as Display Name to set readable labels.
  • Use ->> for sync, -->> for async, --x for failed.
  • Use Note over X,Y: text for callouts.
  • Use loop, alt / else, par, opt for control flow.
  • Use activate X / deactivate X to show lifelines.

State diagram (v2)

  • Use [*] --> StateName for start, StateName --> [*] for end.
  • Use state ChoiceName <<choice>> for branching.
  • Use composite states for nesting: state Group { ... }.

ER diagram

  • Cardinality glyphs: ||--o{ (one-to-many), }o--o{ (many-to-many), ||--|| (one-to-one).
  • Use lowercase plural entity names.
  • Attribute lines: {type} attributeName "comment".

Journey

  • Three columns per task: Task name: <score 1-5>: Actor1, Actor2.
  • Group tasks under section Name.

Mindmap

  • Indentation defines hierarchy.
  • Node shapes: ((text)), [text], (text), {{text}}.

Timeline

  • section Name then events as : YYYY : event text.

Gantt

  • Always start with dateFormat YYYY-MM-DD.
  • Tasks: Name :status, id, start, duration or Name :status, id, after otherId, duration.
  • Status keywords: done, active, crit.

Sankey-beta

  • One source-target-value row per line: Source,Target,42.
  • No header. Comma-separated. Values numeric.

Quadrant chart

  • Required: title, x-axis Low --> High, y-axis Low --> High, four quadrant labels.
  • Items: Item Name: [x, y] where x and y are 0-1.

Class diagram

  • Class : +method() for public, - private, # protected.
  • Relationships: <|-- inherits, *-- composition, o-- aggregation, --> association.

GitGraph

  • commit, branch name, checkout name, merge name.
  • Order matters; reads top-to-bottom.

Output structure

## {Diagram Title}

**Summary:** {one-line description of what the diagram shows}

```mermaid
{code}

Key callouts:

  • {anything non-obvious about the diagram}

If multiple diagrams (e.g., happy + error paths), use a header per diagram and render each separately.

## HTML preview template

When the user asks for a local preview, write this single file (no build, no npm; mermaid loaded from CDN):

```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Diagram preview</title>
<style>
  body{margin:0;padding:48px;font:16px/1.5 system-ui,sans-serif;background:#F5F1EA;color:#15140F}
  .wrap{max-width:1100px;margin:0 auto}
  h1{font-weight:500;font-size:28px;margin:0 0 24px}
  .mermaid{background:#fff;border:1px solid #D8D2C5;border-radius:10px;padding:24px;overflow:auto}
</style>
</head>
<body>
  <div class="wrap">
    <h1>{TITLE}</h1>
    <pre class="mermaid">
{MERMAID_CODE}
    </pre>
  </div>
  <script type="module">
    import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';
    mermaid.initialize({ startOnLoad: true, theme: 'base', themeVariables: {
      primaryColor: '#F5F1EA', primaryTextColor: '#15140F', primaryBorderColor: '#15140F',
      lineColor: '#15140F', fontFamily: 'system-ui, sans-serif'
    }});
  </script>
</body>
</html>

Replace {TITLE} and {MERMAID_CODE} with the actual content. Preview opens directly in the browser (file:// works; no server needed).

Anti-Patterns

  • Don't pick the wrong diagram type to "force fit" the input — ask if it's ambiguous.
  • Don't cram multiple scenarios into one diagram; split them.
  • Don't use \n for line breaks in flowchart node labels — always <br>.
  • Don't put quotes, colons, or pipes inside node labels (they break Mermaid).
  • Don't skip the style lines on flowcharts — color coding makes diagrams scannable.
  • Don't reach for D3, ReactFlow, or custom HTML; Mermaid is the right tool for almost every case. (If the user wants the magazine-grade animated process flow, point them to the interactive-flowchart-builder skill instead.)
  • Don't auto-generate the HTML preview unless the user asks — most users just want the Mermaid block.

Quality Checklist

  • Picked the right diagram type for the input (flowchart vs sequence vs state vs ...).
  • Mermaid syntax parses cleanly (no unescaped special chars in labels).
  • Distinct scenarios split into separate diagrams.
  • Color/style applied where the diagram type supports it (flowchart, sequence highlights, journey scores).
  • Node text is concise (≤4 lines).
  • Summary line + key callouts included with the diagram.
  • If preview requested, single-file HTML written and opens directly in browser.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.