architecture-diagrams

EvanLavender13's avatarfrom EvanLavender13

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.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 4, 2026

When & Why to Use This Skill

This Claude skill enables the creation of professional, standardized architecture diagrams and flowcharts using Mermaid syntax. It focuses on producing clear, unambiguous technical visualizations by enforcing best practices such as mandatory arrow labeling, consistent abstraction levels, and comprehensive legends, making it an essential tool for system documentation and technical communication.

Use Cases

  • System Architecture Mapping: Visualize high-level system boundaries and internal module interactions for RFCs and technical design documents.
  • Data Flow Visualization: Create detailed pipelines showing how data is transformed across different processing nodes with explicit payload labeling.
  • Software Dependency Analysis: Generate module or function-level graphs to identify coupling and understand the impact of code changes.
  • Standardizing Documentation: Apply consistent visual conventions (e.g., specific arrow types for async events) across a project's entire documentation suite.
  • Logic and Workflow Design: Map out complex business logic or algorithmic decision paths using standardized flowchart symbols to ensure no 'dead ends' in the process.
namearchitecture-diagrams
descriptionThis 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.

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.

%% 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.

%% 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.

%% 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 <-->.

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
%% 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

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

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

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

Node Shapes

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

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