Diagram

Generate diagrams from descriptions with Mermaid, PlantUML, or ASCII for architecture, flows, sequences, and data models.

Security Scan

The skill's instructions and requirements are internally consistent with a diagram-generation helper; nothing requests credentials or strange system access, though the docs recommend running remote tooling (npx) which is a normal but noteworthy runtime action.

Purpose & Capability

Name/description match the instructions: the SKILL.md describes producing Mermaid/PlantUML/ASCII diagrams and gives examples. Minor inconsistency: the doc shows invoking mermaid-cli via `npx` (which requires Node/npm) but the skill's required-binaries list is empty — the author didn't declare Node as a prerequisite.

Instruction Scope

Instructions stay on-topic: choose diagram type, produce Mermaid/PlantUML/ASCII, render to image or HTML. The document does not instruct reading unrelated files, environment variables, or exfiltrating data. Example commands (npx mmdc) are the only external runtime actions suggested.

Install Mechanism

There is no install spec (instruction-only), which is low risk. However the SKILL.md recommends using `npx @mermaid-js/mermaid-cli` which will fetch and execute code from the npm registry at runtime — a common workflow but one that pulls remote code when executed.

Credentials

The skill requests no environment variables, credentials, or config paths. That is proportionate for a diagram helper.

Persistence & Privilege

always:false and no install or config changes are declared. The skill does not request persistent presence or elevated privileges.

Assessment

This skill is coherent and only provides instructions for producing diagrams. Before running commands the skill suggests (for example `npx @mermaid-js/mermaid-cli`), be aware those commands will download and run code from the npm registry and require Node/npm installed on the host. If you or your agent will execute shell commands, prefer installing and vetting the mermaid-cli package in advance (or use a trusted renderer/service) rather than blindly running on-demand `npx` installs. No credentials are requested by the skill, but as always be cautious about allowing any agent to execute arbitrary shell commands or install third-party packages.

Principle

Diagrams should clarify, not complicate. Start simple, add detail only when needed. A 5-box flowchart beats a 50-node sprawl.

When User Describes a System or Flow

1. Identify diagram type — Is this a flow, architecture, sequence, or data model?
2. Choose format — Mermaid (default), PlantUML (complex), ASCII (inline), SVG (custom)
3. Draft minimal version — Core elements only, no decoration
4. Iterate — Add detail based on feedback

Diagram Types

Type	Use For	Format
Flowchart	Processes, decisions, workflows	Mermaid flowchart
Sequence	API calls, interactions, protocols	Mermaid sequenceDiagram
Architecture	System components, infrastructure	Mermaid flowchart or C4
ER/Data model	Database schemas, relationships	Mermaid erDiagram
Class	Object structure, inheritance	Mermaid classDiagram
State	Lifecycles, status transitions	Mermaid stateDiagram-v2
Timeline	Project phases, history	Mermaid timeline
Mindmap	Brainstorming, concept mapping	Mermaid mindmap

Output Methods

Method	When
Mermaid code block	User can render (docs, GitHub, Notion)
Render to PNG/SVG	User needs image file
ASCII inline	Quick sketch in chat
HTML + Mermaid.js	Interactive viewing

Rendering Mermaid to Image

# Using mmdc (mermaid-cli)
npx -y @mermaid-js/mermaid-cli mmdc -i diagram.mmd -o diagram.png -b transparent

# Or via browser tool
# Write HTML with Mermaid, screenshot the rendered diagram

Mermaid Quick Reference

Flowchart:

flowchart LR
    A[Start] --> B{Decision}
    B -->|Yes| C[Action]
    B -->|No| D[End]

Sequence:

sequenceDiagram
    User->>API: Request
    API->>DB: Query
    DB-->>API: Result
    API-->>User: Response

ER Diagram:

erDiagram
    USER ||--o{ ORDER : places
    ORDER ||--|{ ITEM : contains

Style Guidelines

• Left-to-right (LR) for processes, top-to-bottom (TB) for hierarchies
• Max 10-15 nodes per diagram, split if larger
• Consistent naming — all caps for systems, lowercase for actions
• Subgraphs to group related components
• Color sparingly — highlight critical paths only

Common Requests

Request	Interpret As
"Draw my API flow"	Sequence diagram: client → API → services
"Show the architecture"	Flowchart with subgraphs for components
"Database schema"	ER diagram with relationships
"How the auth works"	Sequence or flowchart depending on complexity
"User journey"	Flowchart with decision points

Anti-Patterns

• ❌ Too many nodes (split into multiple diagrams)
• ❌ Decorative icons without meaning
• ❌ Mixing abstraction levels (database tables next to business concepts)
• ❌ Arrows in all directions (confuses flow)
• ❌ Labels too long (use short names, add legend if needed)