Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Create software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams, sequence diagrams, flowcharts, ERDs, C4 architecture diagrams, state diagrams, git graphs, and other diagram types. Triggers include requests to diagram, visualize, model, map out, or show the flow of a system.
Create software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams, sequence diagrams, flowcharts, ERDs, C4 architecture diagrams, state diagrams, git graphs, and other diagram types. Triggers include requests to diagram, visualize, model, map out, or show the flow of a system.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run.
Create professional software diagrams using Mermaid's text-based syntax. Mermaid renders diagrams from simple text definitions, making diagrams version-controllable, easy to update, and maintainable alongside code.
npx clawhub@latest install mermaid-diagrams
All Mermaid diagrams follow this pattern: diagramType definition content Key principles: First line declares diagram type (e.g., classDiagram, sequenceDiagram, flowchart) Use %% for comments Line breaks and indentation improve readability but aren't required Unknown words break diagrams; invalid parameters fail silently
TypeUse ForReferenceClass DiagramsDomain modeling, OOP design, entity relationshipsreferences/class-diagrams.mdSequence DiagramsAPI flows, auth flows, component interactionsreferences/sequence-diagrams.mdFlowchartsProcesses, algorithms, decision trees, user journeysreferences/flowcharts.mdERDDatabase schemas, table relationships, data modelingreferences/erd-diagrams.mdC4 DiagramsSystem context, containers, components, architecturereferences/c4-diagrams.mdState DiagramsState machines, lifecycle statesβGit GraphsBranching strategiesβGantt ChartsProject timelines, schedulingβ For styling, themes, and layout options: See references/advanced-features.md
classDiagram Title -- Genre Title *-- Season Title *-- Review User --> Review : creates class Title { +string name +int releaseYear +play() } class Genre { +string name +getTopTitles() }
sequenceDiagram participant User participant API participant Database User->>API: POST /login API->>Database: Query credentials Database-->>API: Return user data alt Valid credentials API-->>User: 200 OK + JWT token else Invalid credentials API-->>User: 401 Unauthorized end
flowchart TD Start([User visits site]) --> Auth{Authenticated?} Auth -->|No| Login[Show login page] Auth -->|Yes| Dashboard[Show dashboard] Login --> Creds[Enter credentials] Creds --> Validate{Valid?} Validate -->|Yes| Dashboard Validate -->|No| Error[Show error] Error --> Login
erDiagram USER ||--o{ ORDER : places ORDER ||--|{ LINE_ITEM : contains PRODUCT ||--o{ LINE_ITEM : includes USER { int id PK string email UK string name datetime created_at } ORDER { int id PK int user_id FK decimal total datetime created_at }
Start simple β begin with core entities/components, add details incrementally Use meaningful names β clear labels make diagrams self-documenting Comment extensively β use %% comments to explain complex relationships Keep focused β one diagram per concept; split large diagrams into multiple views Version control β store .mmd files alongside code for easy updates Add context β include titles and notes to explain diagram purpose Iterate β refine diagrams as understanding evolves
Configure diagrams using frontmatter: --- config: theme: base themeVariables: primaryColor: "#ff6b6b" --- flowchart LR A --> B Available themes: default, forest, dark, neutral, base Layout options: layout: dagre (default) β classic balanced layout layout: elk β advanced layout for complex diagrams Look options: look: classic β traditional Mermaid style look: handDrawn β sketch-like appearance
Native support in: GitHub/GitLab β automatically renders in Markdown VS Code β with Markdown Mermaid extension Notion, Obsidian, Confluence β built-in support Export options: Mermaid Live Editor β online editor with PNG/SVG export Mermaid CLI β npm install -g @mermaid-js/mermaid-cli then mmdc -i input.mmd -o output.png
Always diagram when: Starting new projects or features Documenting complex systems Explaining architecture decisions Designing database schemas Planning refactoring efforts Onboarding new team members Use diagrams to: Align stakeholders on technical decisions Document domain models collaboratively Visualize data flows and system interactions Plan before coding Create living documentation that evolves with code
Breaking characters β avoid {} in comments; escape special characters Syntax errors β misspellings break diagrams; validate in Mermaid Live Overcomplexity β split complex diagrams into multiple focused views Missing relationships β document all important connections between entities Stale diagrams β a wrong diagram is worse than no diagram; update when systems change
NEVER create diagrams with more than 15 nodes β they become unreadable; split into multiple focused diagrams NEVER leave arrows unlabeled β every connection should explain the relationship or data flow NEVER create diagrams without a title or caption β context-free diagrams are useless outside the author's head NEVER use diagrams as the sole documentation β pair diagrams with prose that explains the "why" NEVER let diagrams go stale β update diagrams when architecture changes; stale diagrams mislead NEVER use Mermaid for data visualization β Mermaid is for architecture and flow diagrams, not charts of business data
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.