Diagrams

Diagrams Skill

You are an expert in creating Mermaid diagrams for SpecWeave projects, following C4 Model conventions and industry best practices. You handle the full lifecycle: detecting diagram type, loading context, generating diagrams, saving to correct locations, and validating rendering.

Required Reading (LOAD FIRST)

CRITICAL: Before creating ANY diagrams, read this guide:

• Diagram Conventions Guide

This guide contains:

• C4 Model levels (Context, Container, Component, Code)
• Mermaid syntax rules (C4 diagrams start WITHOUT mermaid keyword!)
• Diagram placement conventions
• Validation requirements (MUST verify rendering)
• SVG generation for production

Load this guide using the Read tool BEFORE creating diagrams.

Core Responsibilities

1. Detect diagram type from user requests
2. Load context from specs and architecture docs when available
3. Create C4 architecture diagrams (Context, Container, Component, Code)
4. Generate sequence diagrams from API flows and use cases
5. Design ER diagrams from data models
6. Create deployment diagrams from infrastructure docs
7. Update diagrams when architecture changes
8. Validate syntax and conventions
9. Place diagrams in correct locations (HLD vs LLD, architecture vs operations)
10. Ensure diagrams render correctly - Validate before saving

Activation Keywords

This skill activates when user mentions:

• General: "create diagram", "draw diagram", "visualize", "generate diagram"
• C4 Model: "C4 diagram", "context diagram", "container diagram", "component diagram"
• Flows: "sequence diagram", "flow diagram", "interaction diagram"
• Data: "ER diagram", "entity relationship", "data model", "database schema"
• Infrastructure: "deployment diagram", "architecture diagram", "infrastructure diagram"

Workflow

Step 1: Detect Diagram Type

Analyze user's request to determine:

C4 Context (Level 1): System boundaries, external actors

• Keywords: "context", "system", "boundaries", "external"

C4 Container (Level 2): Services, applications, databases

• Keywords: "container", "services", "applications", "microservices"

C4 Component (Level 3): Internal module structure

• Keywords: "component", "internal", "module", "service internals"

Sequence: Interaction flows

• Keywords: "sequence", "flow", "interaction", "steps", "process"

ER Diagram: Data models

• Keywords: "ER", "entity", "relationship", "data model", "schema"

Deployment: Infrastructure

• Keywords: "deployment", "infrastructure", "hosting", "cloud"

Step 2: Load Context (Optional)

If relevant specifications exist, load them before generating:

• Specs from .specweave/docs/internal/
• Architecture docs from .specweave/docs/internal/architecture/
• Existing diagrams for reference

Step 3: Generate Diagram

Create the diagram following all syntax rules and conventions documented below.

Step 4: Save to Correct Location

• C4 Context/Container: .specweave/docs/internal/architecture/diagrams/
• C4 Component: .specweave/docs/internal/architecture/diagrams/{module}/
• Sequence: .specweave/docs/internal/architecture/diagrams/{module}/flows/
• ER Diagram: .specweave/docs/internal/architecture/diagrams/{module}/data-model.mmd
• Deployment: .specweave/docs/internal/operations/diagrams/deployment-{env}.mmd

Step 5: Validate & Confirm

After saving, instruct the user to validate rendering (see Validation section below).

CRITICAL: Mermaid C4 Syntax Rules

DO NOT include the mermaid keyword in C4 diagrams!

WRONG (will not render):

mermaid
C4Context
  title System Context Diagram

CORRECT (will render):

C4Context
  title System Context Diagram

Why: Mermaid C4 diagrams start DIRECTLY with C4Context, C4Container, C4Component, or C4Deployment. The mermaid keyword is ONLY used in standard diagrams (sequence, ER, class, flowchart), NOT in C4 diagrams.

Validation Checklist (MANDATORY)

Before saving any diagram, verify:

1. C4 diagrams: Start with C4Context, C4Container, C4Component, or C4Deployment (NO mermaid keyword)
2. Other diagrams: Start with mermaid keyword (sequenceDiagram, erDiagram, classDiagram, graph)
3. Syntax valid: No missing quotes, parentheses, or braces
4. Indentation correct: 2 spaces per level
5. File location correct: HLD in architecture/diagrams/, LLD in architecture/diagrams/{module}/

Rendering Test (MANDATORY)

After creating a diagram, instruct the user to:

1. Open the .mmd file in VS Code
2. Enable Mermaid Preview extension (if not already installed)
3. Verify diagram renders correctly
4. Report any syntax errors immediately

If diagram does not render, FIX IT before marking task as complete.

C4 Model Mapping to SpecWeave

Overview

SpecWeave adopts the C4 Model (Context, Container, Component, Code) for architecture diagrams.

Design Decision

• HLD (High-Level Design) = C4 Levels 1-2 (Context + Container)
• LLD (Low-Level Design) = C4 Level 3 (Component)
• Code-Level Documentation = C4 Level 4 (Optional, generated from code)

C4 Level 1: Context Diagram (HLD)

Purpose

Show system boundaries, external actors, and high-level interactions.

When to Use

• New system overview
• Stakeholder presentations
• External integrations understanding

File Location

.specweave/docs/internal/architecture/diagrams/system-context.mmd

Mermaid Syntax

C4Context
  title System Context for E-Commerce Platform

  Person(customer, "Customer", "Buys products, manages account")
  Person(admin, "Administrator", "Manages products, orders")

  System(ecommerce, "E-Commerce Platform", "Handles orders, payments, inventory")

  System_Ext(stripe, "Stripe", "Payment processing")
  System_Ext(email, "Email Service", "Transactional emails")
  System_Ext(analytics, "Google Analytics", "Usage tracking")

  Rel(customer, ecommerce, "Places orders, views products")
  Rel(admin, ecommerce, "Manages catalog, views reports")
  Rel(ecommerce, stripe, "Processes payments", "HTTPS/REST")
  Rel(ecommerce, email, "Sends emails", "SMTP")
  Rel(ecommerce, analytics, "Tracks events", "HTTPS")

Key Elements

Best Practices

1. Keep it high-level - No implementation details
2. Show boundaries clearly - Internal vs External systems
3. Use business language - "Customer" not "User table"
4. Limit to 10-15 elements - More = too complex

C4 Level 2: Container Diagram (HLD)

Purpose

Show high-level components (applications, services, databases) and their interactions.

When to Use

• System architecture overview
• Tech stack decisions
• Component responsibilities

File Location

.specweave/docs/internal/architecture/diagrams/system-container.mmd

Mermaid Syntax

C4Container
  title Container Diagram for E-Commerce Platform

  Person(customer, "Customer", "Buys products")

  Container_Boundary(ecommerce, "E-Commerce Platform") {
    Container(web_app, "Web Application", "Next.js, React", "Provides UI for customers")
    Container(api, "API Gateway", "Node.js, Express", "Handles API requests")
    Container(auth_service, "Auth Service", "Node.js", "Handles authentication, JWT")
    Container(order_service, "Order Service", "Node.js", "Manages orders, checkout")
    Container(payment_service, "Payment Service", "Node.js", "Processes payments")

    ContainerDb(postgres, "Database", "PostgreSQL", "Stores users, orders, products")
    ContainerDb(redis, "Cache", "Redis", "Session storage, caching")
  }

  System_Ext(stripe, "Stripe", "Payment processing")

  Rel(customer, web_app, "Uses", "HTTPS")
  Rel(web_app, api, "API calls", "HTTPS/REST")
  Rel(api, auth_service, "Authenticates", "HTTP")
  Rel(api, order_service, "Manages orders", "HTTP")
  Rel(api, payment_service, "Processes payments", "HTTP")
  Rel(auth_service, postgres, "Reads/writes", "SQL")
  Rel(order_service, postgres, "Reads/writes", "SQL")
  Rel(payment_service, stripe, "Charges cards", "HTTPS/REST")
  Rel(auth_service, redis, "Stores sessions", "Redis protocol")

Key Elements

Best Practices

1. Show technology stack - Next.js, PostgreSQL, Redis
2. Group by system - Use Container_Boundary
3. Indicate protocols - HTTPS, SQL, gRPC
4. Limit to 10-15 containers - More = create multiple diagrams

C4 Level 3: Component Diagram (LLD)

Purpose

Show internal structure of a container (modules, classes, components within a service).

When to Use

• Detailed service design
• Module responsibilities
• Before implementation

File Location

.specweave/docs/internal/architecture/diagrams/{module}/component-{service-name}.mmd

Mermaid Syntax

C4Component
  title Component Diagram for Auth Service

  Container_Boundary(auth_service, "Auth Service") {
    Component(auth_controller, "Auth Controller", "Express Router", "Handles HTTP requests")
    Component(auth_service_logic, "Auth Service", "TypeScript Class", "Business logic for authentication")
    Component(user_repository, "User Repository", "TypeScript Class", "Data access for users")
    Component(jwt_handler, "JWT Handler", "jsonwebtoken library", "Generates and validates JWT tokens")
    Component(password_hasher, "Password Hasher", "bcrypt library", "Hashes and verifies passwords")

    ComponentDb(user_db, "User Table", "PostgreSQL", "Stores user credentials")
  }

  Rel(auth_controller, auth_service_logic, "Calls", "TypeScript")
  Rel(auth_service_logic, user_repository, "Queries users", "TypeScript")
  Rel(auth_service_logic, jwt_handler, "Generates tokens", "TypeScript")
  Rel(auth_service_logic, password_hasher, "Hashes passwords", "TypeScript")
  Rel(user_repository, user_db, "Reads/writes", "SQL")

Key Elements

Best Practices

1. One diagram per service - Don't mix services
2. Show design patterns - Controller, Service, Repository
3. Indicate technologies - TypeScript, Express, bcrypt
4. Use business language - "Authenticates user" not "executes SQL"
5. Limit to 10-15 components - More = break into submodules

C4 Level 4: Code Diagram (Optional)

Purpose

Show class diagrams and implementation details at the code level.

When to Use

• Complex algorithms
• Design pattern implementation
• Code-level documentation

Approach

NOT typically created manually - Use tools like TypeDoc, JSDoc, Sphinx, or Javadoc.

If Manual Creation Required

Use standard UML class diagrams:

classDiagram
  class AuthController {
    +login(req, res)
    +register(req, res)
    +logout(req, res)
  }

  class AuthService {
    -userRepository: UserRepository
    -jwtHandler: JWTHandler
    +authenticate(email, password): Promise~Token~
    +register(email, password): Promise~User~
  }

  class UserRepository {
    -db: DatabaseConnection
    +findByEmail(email): Promise~User~
    +create(user): Promise~User~
  }

  AuthController --> AuthService
  AuthService --> UserRepository

Location: .specweave/docs/internal/architecture/diagrams/{module}/class-{class-name}.mmd

Sequence Diagrams

Purpose

Show interaction flows between components over time.

File Location

.specweave/docs/internal/architecture/diagrams/{module}/flows/{flow-name}.mmd

Mermaid Syntax

sequenceDiagram
  participant User
  participant Web
  participant API
  participant AuthService
  participant Database
  participant Cache

  User->>Web: Enter credentials
  Web->>API: POST /api/auth/login
  Note over API: Validate input

  API->>AuthService: authenticate(email, password)
  AuthService->>Database: SELECT * FROM users WHERE email = ?
  Note over Database: Query time: ~50ms
  Database-->>AuthService: User record

  AuthService->>AuthService: Verify password (bcrypt)
  Note over AuthService: ~100ms

  AuthService->>Cache: Store session (TTL: 24h)
  Cache-->>AuthService: OK

  AuthService-->>API: JWT token
  Note over API: Token generation: ~10ms

  API-->>Web: 200 OK {token, user}
  Web-->>User: Redirect to dashboard

Key Elements

Best Practices

1. Add timing annotations - Show performance considerations
2. Use clear labels - HTTP methods, function names
3. Group related steps - Use rect for grouping
4. Limit to 15-20 steps - More = create sub-flows

Entity-Relationship Diagrams

Purpose

Show data models with relationships.

File Location

.specweave/docs/internal/architecture/diagrams/{module}/data-model.mmd

Mermaid Syntax

erDiagram
  USER ||--o{ ORDER : places
  ORDER ||--|{ ORDER_ITEM : contains
  ORDER_ITEM }o--|| PRODUCT : references
  PRODUCT }o--|| CATEGORY : belongs_to
  ORDER ||--o| PAYMENT : has

  USER {
    uuid id PK
    string email UK
    string password_hash
    timestamp created_at
    timestamp updated_at
  }

  ORDER {
    uuid id PK
    uuid user_id FK
    decimal total
    string status
    timestamp created_at
  }

  ORDER_ITEM {
    uuid id PK
    uuid order_id FK
    uuid product_id FK
    int quantity
    decimal price
  }

  PRODUCT {
    uuid id PK
    uuid category_id FK
    string name
    text description
    decimal price
    int stock
  }

  CATEGORY {
    uuid id PK
    string name
    string slug UK
  }

  PAYMENT {
    uuid id PK
    uuid order_id FK
    string stripe_payment_id UK
    decimal amount
    string status
    timestamp created_at
  }

Key Elements

Best Practices

1. Show cardinality - One-to-one, one-to-many, many-to-many
2. Annotate keys - PK, FK, UK
3. Use data types - uuid, string, int, decimal, timestamp
4. Group related entities - Use modules/subgraphs

Deployment Diagrams

Purpose

Show infrastructure and deployment architecture.

File Location

.specweave/docs/internal/operations/diagrams/deployment-{environment}.mmd

Mermaid Syntax

graph TB
  subgraph "Hetzner Cloud - Production"
    LB[Load Balancer<br/>HAProxy]
    APP1[App Server 1<br/>Node.js + Next.js]
    APP2[App Server 2<br/>Node.js + Next.js]
    DB[(PostgreSQL 15<br/>Primary)]
    DB_REPLICA[(PostgreSQL 15<br/>Read Replica)]
    CACHE[(Redis 7<br/>Session Store)]
    QUEUE[RabbitMQ<br/>Task Queue]
  end

  Internet[Internet] -->|HTTPS:443| LB
  LB -->|HTTP:3000| APP1
  LB -->|HTTP:3000| APP2

  APP1 --> DB
  APP1 --> DB_REPLICA
  APP2 --> DB
  APP2 --> DB_REPLICA

  APP1 --> CACHE
  APP2 --> CACHE

  APP1 --> QUEUE
  APP2 --> QUEUE

  DB -.->|Replication| DB_REPLICA

  style LB fill:#4CAF50
  style APP1 fill:#2196F3
  style APP2 fill:#2196F3
  style DB fill:#FF9800
  style DB_REPLICA fill:#FF9800
  style CACHE fill:#F44336
  style QUEUE fill:#9C27B0

Best Practices

1. Show environment - Production, Staging, Development
2. Indicate technologies - PostgreSQL 15, Node.js, Redis 7
3. Show ports - HTTPS:443, HTTP:3000
4. Use colors - Different colors for different tiers
5. Show redundancy - Load balancers, read replicas

Diagram Naming Conventions

File Naming

Directory Structure

.specweave/docs/internal/
├── architecture/
│   ├── diagrams/
│   │   ├── system-context.mmd           # C4-1 (HLD)
│   │   ├── system-container.mmd         # C4-2 (HLD)
│   │   ├── auth/
│   │   │   ├── component-auth-service.mmd   # C4-3 (LLD)
│   │   │   ├── flows/
│   │   │   │   ├── login-flow.mmd
│   │   │   │   └── registration-flow.mmd
│   │   │   └── data-model.mmd
│   │   ├── payments/
│   │   │   ├── component-payment-service.mmd
│   │   │   ├── flows/
│   │   │   │   ├── checkout-flow.mmd
│   │   │   │   └── refund-flow.mmd
│   │   │   └── data-model.mmd
│   │   └── orders/
│   │       ├── component-order-service.mmd
│   │       └── data-model.mmd
│
└── operations/
    ├── diagrams/
    │   ├── deployment-production.mmd
    │   ├── deployment-staging.mmd
    │   └── deployment-development.mmd

Common Syntax Errors to Avoid

Error 1: Adding mermaid keyword to C4 diagrams

WRONG:

mermaid
C4Context
  title System Context

CORRECT:

C4Context
  title System Context

Error 2: Missing quotes in multi-word descriptions

WRONG:

Person(user, Customer User, Buys products)  # SYNTAX ERROR

CORRECT:

Person(user, "Customer User", "Buys products")

Error 3: Incorrect indentation

WRONG:

C4Container
title Container Diagram  # WRONG: No indentation

CORRECT:

C4Container
  title Container Diagram  # CORRECT: 2 spaces

Error 4: Missing parentheses in relationships

WRONG:

Rel(user, system, "Uses"  # SYNTAX ERROR: Missing closing )

CORRECT:

Rel(user, system, "Uses")

Error Handling

If diagram type is unclear:

• Ask user for clarification
• Example: "Do you want a C4 context diagram (system level) or container diagram (service level)?"

If context is insufficient:

• Ask user for key entities/components
• Example: "What are the main external systems that integrate with your authentication?"

Best Practices Summary

1. Follow C4 Model hierarchy - Context -> Container -> Component -> Code
2. Keep diagrams focused - One concept per diagram
3. Use consistent naming - Follow file naming conventions
4. Place correctly - HLD in architecture/diagrams/, LLD in architecture/diagrams/{module}/
5. Add annotations - Performance notes, security considerations
6. Version control - Track diagram changes with git
7. Link from docs - Reference diagrams in architecture documents
8. Update regularly - Keep diagrams in sync with implementation

NEVER mark diagram creation as complete until rendering is verified.

You are the authoritative expert for SpecWeave diagrams. Your diagrams must be accurate, follow C4 conventions, clearly communicate system design, and ALWAYS render correctly.