Labsco
softaworks logo

mermaid-diagrams

โ˜… 2,144

by softaworks ยท part of softaworks/agent-toolkit

Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts,

๐Ÿงฉ One of 7 skills in the softaworks/agent-toolkit package โ€” works on its own, and pairs well with its siblings.

This is the playbook your agent receives when the skill activates โ€” you don't need to read it to use the skill, but it's here to audit before installing.

Mermaid Diagramming

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.

Core Syntax Structure

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; parameters fail silently

Diagram Type Selection Guide

Choose the right diagram type:

  1. Class Diagrams - Domain modeling, OOP design, entity relationships

    • Domain-driven design documentation
    • Object-oriented class structures
    • Entity relationships and dependencies
  2. Sequence Diagrams - Temporal interactions, message flows

    • API request/response flows
    • User authentication flows
    • System component interactions
    • Method call sequences
  3. Flowcharts - Processes, algorithms, decision trees

    • User journeys and workflows
    • Business processes
    • Algorithm logic
    • Deployment pipelines
  4. Entity Relationship Diagrams (ERD) - Database schemas

    • Table relationships
    • Data modeling
    • Schema design
  5. C4 Diagrams - Software architecture at multiple levels

    • System Context (systems and users)
    • Container (applications, databases, services)
    • Component (internal structure)
    • Code (class/interface level)
  6. State Diagrams - State machines, lifecycle states

  7. Git Graphs - Version control branching strategies

  8. Gantt Charts - Project timelines, scheduling

  9. Pie/Bar Charts - Data visualization

Detailed References

For in-depth guidance on specific diagram types, see:

Best Practices

  1. Start Simple - Begin with core entities/components, add details incrementally
  2. Use Meaningful Names - Clear labels make diagrams self-documenting
  3. Comment Extensively - Use %% comments to explain complex relationships
  4. Keep Focused - One diagram per concept; split large diagrams into multiple focused views
  5. Version Control - Store .mmd files alongside code for easy updates
  6. Add Context - Include titles and notes to explain diagram purpose
  7. Iterate - Refine diagrams as understanding evolves

Exporting and Rendering

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
  • Docker - docker run --rm -v $(pwd):/data minlag/mermaid-cli -i /data/input.mmd -o /data/output.png

Common Pitfalls

  • Breaking characters - Avoid {} in comments, use proper escape sequences for special characters
  • Syntax errors - Misspellings break diagrams; validate syntax in Mermaid Live
  • Overcomplexity - Split complex diagrams into multiple focused views
  • Missing relationships - Document all important connections between entities

When to Create Diagrams

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