architecture-diagrams

This skill should be used when the user asks to "create a diagram", "draw architecture", "make a Mermaid diagram", "update the system diagram", "visualize data flow", or when generating flowcharts, module diagrams, or dependency graphs. Provides standards for clear, unambiguous Mermaid diagrams.

16 stars

Best use case

architecture-diagrams is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

This skill should be used when the user asks to "create a diagram", "draw architecture", "make a Mermaid diagram", "update the system diagram", "visualize data flow", or when generating flowcharts, module diagrams, or dependency graphs. Provides standards for clear, unambiguous Mermaid diagrams.

Teams using architecture-diagrams should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/architecture-diagrams/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/development/architecture-diagrams/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/architecture-diagrams/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How architecture-diagrams Compares

Feature / Agentarchitecture-diagramsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

This skill should be used when the user asks to "create a diagram", "draw architecture", "make a Mermaid diagram", "update the system diagram", "visualize data flow", or when generating flowcharts, module diagrams, or dependency graphs. Provides standards for clear, unambiguous Mermaid diagrams.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Architecture Diagram Standards

Apply these standards when creating or updating Mermaid diagrams.

## Core Rules

### Every Arrow Needs a Label

Unlabeled arrows force readers to guess the relationship.

```mermaid
%% BAD
A --> B

%% GOOD
A -->|float[] samples| B
A -->|HTTP 200| B
A -->|calls| B
```

### No Dead Ends

Every process node needs input AND output arrows. Data doesn't disappear.

```mermaid
%% BAD: normalize just ends
RawData --> Normalize

%% GOOD: show what normalized data becomes
RawData -->|int16[]| Normalize -->|float[] peak=1.0| Smoother
```

### Single Abstraction Level Per Diagram

Don't mix high-level modules with implementation functions.

| Level | Shows | Example Nodes |
|-------|-------|---------------|
| System | External boundaries | AudioJones, WASAPI, Display |
| Module | Internal components | audio.c, waveform.c, visualizer.c |
| Function | Implementation detail | ProcessWaveformBase, CubicInterp |

Create separate diagrams for each level.

### Connect All Subgraphs

Isolated subgraphs indicate missing relationships. If a subgraph modifies data elsewhere, show the arrow.

```mermaid
%% BAD: UI floats alone
subgraph UI
    Panel --> Slider
end
subgraph Core
    Config --> Render
end

%% GOOD: show what UI affects
subgraph UI
    Panel --> Slider
end
subgraph Core
    Config --> Render
end
Slider -->|modifies| Config
```

## Arrow Conventions

Pick ONE meaning per diagram and state it in a legend or title:

| Arrow Type | Meaning | Use When |
|------------|---------|----------|
| `-->` | Data flows from A to B | Showing data transformation pipelines |
| `-->` | A calls/invokes B | Showing control flow or dependencies |
| `-.->` | Async/event-based | Callbacks, message queues |
| `==>` | High-volume/critical path | Emphasizing main data path |

**Bidirectional**: Use two arrows with separate labels, not `<-->`.

```mermaid
Client -->|request| Server
Server -->|response| Client
```

## Required Elements

### Legend

Every diagram needs a legend explaining:

- Arrow meaning (data flow vs dependency)
- Shape meanings if non-obvious
- Any color coding

```mermaid
%% Legend:
%% → data flow (payload type on label)
%% [box] processing function
%% [(cylinder)] persistent buffer
%% {{diamond}} decision point
```

### Title

Descriptive title that clarifies arrow semantics:

- "Data Flow: Audio Samples to Screen" (arrows = data movement)
- "Module Dependencies" (arrows = import/call relationships)

## Mermaid Syntax Reference

### Labeled Edges

```mermaid
A -->|label| B      %% arrow with label
A -- label --> B    %% alternative syntax
A -.->|label| B     %% dotted with label
A ==>|label| B      %% thick with label
```

### Subgraph Direction

```mermaid
subgraph Module[Module Name]
    direction LR
    A --> B
end
```

Note: Subgraph direction ignored if nodes link outside the subgraph.

### Node Shapes

```mermaid
A[Rectangle]        %% process/function
B[(Database)]       %% persistent storage
C((Circle))         %% start/end point
D{Diamond}          %% decision
E{{Hexagon}}        %% preparation/setup
F[/Parallelogram/]  %% input/output
```

## Verification Checklist

Before finalizing any diagram:

- [ ] Every arrow has a label describing what flows/relationship
- [ ] No orphaned nodes or subgraphs
- [ ] Every process has both input and output arrows
- [ ] Single abstraction level throughout
- [ ] Legend explains arrow and shape meanings
- [ ] Title clarifies diagram's semantic intent

## Anti-patterns

| Problem | Fix |
|---------|-----|
| `A --> B --> C --> D` (unlabeled chain) | Add data type labels to each arrow |
| Subgraph with no external connections | Add arrows showing how it interacts |
| Function node with only input arrow | Show output or mark as "side effect: X" |
| Mixed modules and functions | Split into separate diagrams |
| Colors without legend | Add legend or remove colors |

## Example: Complete Data Flow

```mermaid
flowchart LR
    subgraph Capture[Audio Capture]
        CB[Callback] -->|int16[] stereo| RB[(Ring Buffer)]
    end

    subgraph Process[Waveform Processing]
        RB -->|int16[4096]| Norm[Normalize]
        Norm -->|float[1024] peak=1.0| Smooth[Smooth]
        Smooth -->|float[2048] palindrome| Interp[CubicInterp]
    end

    subgraph Render[Visualization]
        Interp -->|Vector2[]| Draw[DrawCircular]
        Draw -->|pixels| Accum[(accumTexture)]
        Accum -->|texture| Blur[Gaussian Blur]
        Blur -->|decayed texture| Accum
        Accum -->|final frame| Screen[Display]
    end

%% Legend:
%% → data flow with payload type
%% [(name)] persistent buffer
%% [name] processing function
```

Related Skills

architecture

16
from diegosouzapw/awesome-omni-skill

Comprehensive system architecture design and implementation workflow that orchestrates expert analysis, technical decision-making, and architectural pattern selection using the integrated toolset. Handles everything from initial system analysis to implementation-ready technical specifications.

architecture-workshop

16
from diegosouzapw/awesome-omni-skill

Framework for designing new architectural mechanisms when existing patterns don't fit

architecture-validator

16
from diegosouzapw/awesome-omni-skill

Validate hexagonal architecture (Domain, Application, Infrastructure, Presentation). Use when creating new files in src/, reorganizing code, or when the user requests architecture validation.

architecture-validation

16
from diegosouzapw/awesome-omni-skill

Dynamically validate codebase compliance with architectural decisions and constraints

architecture-to-json

16
from diegosouzapw/awesome-omni-skill

Guide for extracting architectural diagrams, flowcharts, and sequence diagrams into a structured JSON format. Use this skill when you need to transform a visual or textual description of a system architecture or workflow into a clear, structured JSON representation.

architecture-tech-lead

16
from diegosouzapw/awesome-omni-skill

This skill should be used when the user asks to 'review my architecture', 'improve testability', 'refactor for testing', 'reduce mocking in tests', 'too many mocks', 'extract pure functions', 'functional core imperative shell', 'design a feature', 'evaluate approaches', 'make code more testable', 'domain modeling', 'DDD design', 'bounded contexts', 'too much coupling', or needs architectural validation for Java/Spring Boot or TypeScript/Next.js codebases. Use for design decisions, not implementation.

architecture-synthesis

16
from diegosouzapw/awesome-omni-skill

Generate a reference architecture specification from analyzed frameworks. Use when (1) designing a new agent framework based on prior art, (2) defining core primitives (Message, State, Tool types), (3) specifying interface protocols, (4) creating execution loop pseudocode, or (5) producing architecture diagrams and implementation roadmaps.

architecture-strategist

16
from diegosouzapw/awesome-omni-skill

Use this agent when analyzing code changes from an architectural perspective, evaluating system design decisions, or ensuring changes align with established architectural patterns. Triggers on requests like "architecture review", "design evaluation", "system architecture analysis".

architecture-status

16
from diegosouzapw/awesome-omni-skill

Reports on the health and state of architecture documentation (counts of ADRs, reviews, activity levels, documentation gaps). Use when the user asks "What's our architecture status?", "Show architecture documentation", "How many ADRs do we have?", "What decisions are documented?", "Architecture health check", or wants an overview/summary of documentation state. Do NOT use for listing team members (use list-members), creating new documents (use create-adr), or conducting reviews (use architecture-review or specialist-review).

architecture-spec

16
from diegosouzapw/awesome-omni-skill

Generates technical architecture specification from PRD. Covers architecture pattern, tech stack, data models, and app structure. Use when creating ARCHITECTURE.md or designing system architecture.

architecture-selection

16
from diegosouzapw/awesome-omni-skill

System architecture patterns including monolith, microservices, event-driven, and serverless, with C4 modeling, scalability strategies, and technology selection criteria. Use when designing system architectures, evaluating patterns, or planning scalability.

architecture-reviewer

16
from diegosouzapw/awesome-omni-skill

Review software architecture for SOLID principles, design patterns, scalability, and maintainability. Use when evaluating system design or planning refactoring.