Generate editable diagrams from text descriptions

The skill creates clear, editable diagrams from messy or structured input, preferring text-based diagram source (so results can be reviewed, versioned, and refined) over rendered images unless the user explicitly asks for a file or a downloadable artifact would materially help. The default workflow is: identify intent, audience, and source material; choose the diagram family and language from a decision table; normalize entities, relationships, labels, states, and time/order before writing code; generate concise source; validate it mentally and, for files, run the render script; and return the source plus a short assumptions note. Underspecified requests get reasonable, briefly-labeled assumptions rather than a round of clarifying questions.

The decision table defaults to Mermaid unless another language is clearly better: flowchart for process/decision flows, sequenceDiagram (or PlantUML for UML formality) for interaction sequences, stateDiagram-v2 for lifecycles, erDiagram for database schemas, classDiagram for object models, gantt for schedules, mindmap for hierarchies, journey for customer journeys, gitGraph for git history, Graphviz DOT for dense dependency/package graphs (better layout engines), Mermaid subgraphs/Graphviz clusters/PlantUML C4-style for layered architecture, and raw SVG only when no diagram language fits. Output policy always provides editable source unless an image alone was requested, defaults to one best diagram, uses stable simple syntax over renderer-fragile fancy features, keeps ASCII node IDs with human-readable labels, and adds boundaries (client, service, database, queue, external API, operator) for technical diagrams or happy-path/decision/failure/retry distinctions for business-process diagrams, plus an Assumptions section when the source text was uncertain.

Language-specific rules: Mermaid flowcharts default to flowchart TD (or LR for architecture/pipelines), use subgraphs for swimlanes, decision diamonds for branches, and alt/else, opt, loop, par blocks for conditional/optional/repeated/parallel flows; Graphviz DOT uses digraph/graph, layout attributes like rankdir=LR and splines=true, and subgraph cluster_name for boundaries; PlantUML wraps diagrams in @startuml/@enduml with actor/participant/database/component stereotypes; SVG stays simple and accessible with a <title> and no embedded external fonts or remote images. Rendering to a file, quoted verbatim from the source:

python "<SKILL_ROOT>/diagram-generator/scripts/render_diagram.py" input.mmd --format svg --out output.svg
python "<SKILL_ROOT>/diagram-generator/scripts/render_diagram.py" input.dot --format png --out output.png
python "<SKILL_ROOT>/diagram-generator/scripts/render_diagram.py" input.puml --format svg --out output.svg

The renderer tries common local tools and reports installation hints rather than claiming success when a renderer is unavailable - an image is never claimed rendered unless the script completed and the output file exists. Of the toolchain, only the Mermaid CLI (mmdc, via npm install -g @mermaid-js/mermaid-cli) and the Python render script itself auto-install; Graphviz and PlantUML (which also needs Java) require manual installation. Since the skill mainly outputs text-format diagram source, a local renderer is only needed when the user explicitly wants a PNG/SVG/PDF file.

Use it for turning textual analysis into Mermaid, Graphviz, or PlantUML visuals, or for producing attack-path or architecture diagrams for reports. Rendered output is generated downstream for docs-generator/ reports or pentest deliverables from pentest-tools/.

Input is messy or structured text describing a process, sequence, schema, hierarchy, or architecture. Output is editable diagram source in the chosen language, plus a rendered image file only when explicitly requested and confirmed to exist.

Anyone turning analysis, architecture, or attack-path narratives into a reviewable, versionable diagram rather than a one-off rendered image.