create-mermaid-diagrams
Create Mermaid Diagrams
Overview
Create clear Mermaid diagrams and always validate output through a repeatable loop that catches syntax and rendering errors before final delivery.
Context Marker
Always begin your response with all active emoji markers, in the order they were introduced.
Format: "<marker1><marker2><marker3>\n<response>"
The marker for this skill is: 🎨
Manual Triggering
When manual invocation is needed, trigger this skill using whatever mechanism your assistant/tool provides for manual skill selection or activation.
Workflow
-
Define communication intent and choose the smallest diagram type that fits:
flowchartfor process and architecture flow.sequenceDiagramfor interaction timelines.stateDiagram-v2for state transitions.
-
Generate markdown with exactly one Mermaid fence per requested diagram:
- Opening fence must be exactly ```mermaid (no leading space; any spaced example is only Markdown escaping).
- Closing fence must be exactly ``` (no leading space; any spaced example is only Markdown escaping).
- Keep fence markers at column 0.
-
Validate the full markdown file with
mmdc:mmdc -i <input.md> -o /tmp/<name>-rendered.md -a /tmp/<name>-mermaid-artifacts -
If validation fails:
- Read raw Mermaid CLI output from
mmdc. - Apply the minimal targeted fix in the failing Mermaid fence.
- Re-run the same full-file validation command.
- Read raw Mermaid CLI output from
-
Repeat failure analysis and correction up to 3 attempts.
-
If still failing after 3 attempts, return:
- Best-effort corrected diagram.
- Validation summary with likely root cause.
- Raw error excerpt from Mermaid CLI output.
- Next manual fix suggestion.
Feedback Loop Rules
- Do not change diagram type unless the error indicates the type keyword is invalid.
- Prefer minimal edits per retry to avoid introducing new syntax errors.
- Preserve user intent and semantic meaning while repairing syntax.
- Stop retrying early when validation succeeds.
Runtime Requirements
mmdcmust be available inPATH.- If running in a sandboxed AI tool, allow execution of
mmdcexplicitly. - Treat
mmdcstdout/stderr as the source of truth for pass/fail and diagnosis.
Existing Documentation with Multiple Mermaid Diagrams
When validating an existing markdown file that includes multiple Mermaid blocks:
- Run one full-file validation command with
mmdc. - Parse CLI output to identify discovered block count and rendered artifacts.
- For failures, use parse error snippet and caret location to identify the failing fence.
- Patch only failing blocks, then re-run full-file validation.
- Provide a final rollup: total blocks, passed, failed, fixed, unresolved.
Error Handling
Treat any non-zero mmdc exit as a failure and use Mermaid CLI output as the source of truth for diagnosis and repair.
For dependency, access, or input failures (for example mmdc not executable in sandbox), stop immediately and do not continue retries.
When validation cannot run, the response must clearly state that validation did not occur and include:
- the exact
mmdccommand that failed - exit code (if available)
- a raw stderr excerpt
- explicit next steps to grant
mmdcexecution access or fix file/path permissions
Output Requirements
- Always include the final Mermaid markdown block.
- Include a short validation result summary.
- On failure, include the actionable error context and exact next steps.
References
- Mermaid best practices and templates:
references/mermaid-best-practices.md - Advanced diagram patterns and constructs:
references/advanced-patterns.md - Error classes and repair strategies:
references/error-patterns.md - Multi-diagram markdown validation workflow:
references/multi-diagram-validation.md
More from liatrio-labs/ai-prompts
git-commit-conventional
Create Conventional Commit messages and execute safe git commits from working tree changes. Use when users ask to create a commit, write a conventional commit message, split broad changes into multiple commits, stage only parts of files, run pre-commit before committing, or perform a quick commit-time quality review with severity guardrails.
24create-pull-request
Generate a reviewer-ready pull request or merge request title and description from branch changes. Use when a user asks to draft PR/MR content, summarize branch deltas against a base branch, or optionally create the PR with gh/glab after approval.
23liatrio-brand-guidelines
Applies Liatrio brand guidelines to UI design, brand audits, and asset selection. Use when users request Liatrio styling, logo variants, typography or color decisions, visual polish, or formal brand compliance checks.
21branch-surgery-pr-split
Split oversized or mixed-concern branches into smaller, reviewable PR stacks with safety refs, topology selection, parity audits, and merge sequencing. Use when a PR or branch is too large, difficult to review, mixed across concerns, conflict-prone, or needs to be decomposed without losing net changes.
21uv-usage
Provides concise guidance for using uv (Python package manager), including project workflows, pip-compatible commands, Python version management, and PEP 723 inline script dependencies. Use when users mention uv, uv run, inline dependencies, PEP 723, or Python dependency/project management.
16tilt-dev
Manage local development environments with Tilt. Use when working with projects that run services via Tilt (indicated by presence of Tiltfile), including checking service status, viewing logs, troubleshooting connectivity issues, or managing the Tilt stack. Essential for projects using Tiltfile with local_resource for orchestrating backend, frontend, and other services.
15