Mermaid Diagrams
Turn the supplied process, code, schema, or relationships into the requested Mermaid diagram. The user's explicit instructions take precedence over this skill's guidelines, including their choice of output format.
Choose the representation
Establish the facts to show and the destination renderer. If the request leaves the format open and a text-based system/process diagram fits, Mermaid is a reasonable choice. Preserve an explicitly requested drawing tool or artifact format.
Use supplied evidence for nodes, edges, cardinalities, dates, and values. Mark conceptual assumptions; ask for missing facts that determine the diagram rather than inventing a system.
Produce a renderable result
- Return a fenced
mermaidblock, or the requested.mmd/rendered artifact. Use one diagram declaration per block. - Prefer stable syntax supported by the destination. Examples were checked against Mermaid 11.16; a host can bundle an older version.
- Give nodes stable IDs distinct from display labels and subgraph IDs. Quote labels with punctuation; avoid reserved
endIDs and use%%comments on their own lines. - Keep ER attributes one per line and alias sequence participants whose names contain spaces.
- Split diagrams when readability suffers, not at a fixed node count.
Validate nontrivial or repaired syntax with the project's renderer or an available Mermaid CLI. Inspect the rendered result when producing an artifact; if rendering is unavailable, state that limitation. A simple syntax answer does not require installing a new toolchain.
References
Load the diagram type or rendering topic required.
Check Mermaid documentation and the destination's own support notes when a feature is version-sensitive.
