Skill v1.0.0
currentAutomated scanversion: "1.0.0" name: architecture-diagram description: Generate architecture diagrams in Mermaid, PlantUML, or diagrams.net formats disable-model-invocation: false
Architecture Diagram Generator
I'll analyze your codebase and generate visual architecture diagrams showing component relationships, data flow, and system structure.
Arguments: $ARGUMENTS - diagram type or format (e.g., "mermaid", "plantuml", "component", "data-flow")
Strategic Analysis Process
<think> Effective architecture diagrams require understanding:
- Project Structure Analysis
- What's the application architecture? (monolith, microservices, serverless)
- What layers exist? (frontend, backend, database, services)
- How do components communicate?
- What are the major modules and their responsibilities?
- Are there clear architectural patterns? (MVC, MVVM, Clean Architecture)
- Diagram Type Selection
- Component diagram: Show major components and relationships
- Sequence diagram: Show interaction flows
- Data flow diagram: Show how data moves through system
- Deployment diagram: Show infrastructure and deployment
- Class diagram: Show object-oriented structure
- Entity-relationship: Show database schema
- Format Decision
- Mermaid: Simple, version-controllable, GitHub/GitLab rendering
- PlantUML: More features, complex diagrams, requires rendering
- Diagrams.net (Draw.io): Visual editing, XML format
- ASCII art: Terminal-friendly, simple visualizations
- Detail Level
- High-level overview: Major components only
- Medium detail: Components + key interactions
- Detailed: All modules, functions, data flows
- Focus on what's most valuable for documentation
</think>
Phase 1: Architecture Discovery
MANDATORY FIRST STEPS:
- Analyze project structure and file organization
- Identify architectural patterns from code
- Map component dependencies
- Detect technology stack and frameworks
Let me analyze your project architecture:
# Analyze project structureecho "=== Architecture Analysis ==="# Detect project typeif [ -d "src/components" ] || [ -d "components" ]; thenecho "Frontend components detected"fiif [ -d "src/api" ] || [ -d "api" ] || [ -d "routes" ]; thenecho "API/Backend layer detected"fiif [ -d "src/models" ] || [ -d "models" ]; thenecho "Data models detected"fiif [ -d "src/services" ] || [ -d "services" ]; thenecho "Service layer detected"fi# Count major componentsecho ""echo "Component counts:"find src -type f -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" 2>/dev/null | wc -l | xargs echo "Files:"find src -type d -maxdepth 2 2>/dev/null | wc -l | xargs echo "Directories:"# Identify frameworkif grep -q "\"next\"" package.json 2>/dev/null; thenecho "Framework: Next.js"elif grep -q "\"react\"" package.json 2>/dev/null; thenecho "Framework: React"elif grep -q "\"vue\"" package.json 2>/dev/null; thenecho "Framework: Vue"elif grep -q "\"express\"" package.json 2>/dev/null; thenecho "Framework: Express (Node.js)"fi
Phase 2: Component Relationship Mapping
I'll map relationships between components:
Analysis Methods:
- Import/export analysis (module dependencies)
- API endpoint mapping (request/response flows)
- Database relationship detection (foreign keys, relations)
- Event system mapping (event emitters/listeners)
- Service dependencies (dependency injection patterns)
Using Native Tools:
- Grep to find import statements and dependencies
- Glob to identify component files by pattern
- Read key architectural files (routers, services, models)
- Pattern detection for architectural styles
I'll analyze:
- Frontend component hierarchy
- Backend route handlers and middleware
- Service layer dependencies
- Database entity relationships
- External API integrations
Phase 3: Diagram Generation
Based on analysis, I'll generate appropriate diagrams:
Mermaid Diagrams (Default)
Component Diagram:
graph TBsubgraph FrontendUI[User Interface]Components[React Components]Store[State Management]endsubgraph BackendAPI[API Layer]Services[Business Services]Models[Data Models]endsubgraph InfrastructureDB[(Database)]Cache[(Redis Cache)]Queue[Message Queue]endUI --> ComponentsComponents --> StoreComponents --> APIAPI --> ServicesServices --> ModelsModels --> DBServices --> CacheServices --> Queue
Data Flow Diagram:
flowchart LRUser((User)) --> UI[User Interface]UI --> Auth{Authentication}Auth -->|Valid| API[API Gateway]Auth -->|Invalid| Login[Login Page]API --> Service[Business Logic]Service --> DB[(Database)]DB --> ServiceService --> APIAPI --> UIUI --> User
Sequence Diagram:
sequenceDiagramparticipant Userparticipant Frontendparticipant APIparticipant Serviceparticipant DBUser->>Frontend: Click ActionFrontend->>API: HTTP RequestAPI->>Service: Process RequestService->>DB: Query DataDB-->>Service: Return ResultsService-->>API: Format ResponseAPI-->>Frontend: JSON ResponseFrontend-->>User: Update UI
System Architecture:
graph TBsubgraph Client LayerWeb[Web App]Mobile[Mobile App]endsubgraph API GatewayGateway[API Gateway]Auth[Auth Service]endsubgraph ServicesUserService[User Service]ProductService[Product Service]OrderService[Order Service]endsubgraph Data LayerPostgreSQL[(PostgreSQL)]Redis[(Redis)]S3[S3 Storage]endWeb --> GatewayMobile --> GatewayGateway --> AuthAuth --> GatewayGateway --> UserServiceGateway --> ProductServiceGateway --> OrderServiceUserService --> PostgreSQLProductService --> PostgreSQLOrderService --> PostgreSQLProductService --> RedisOrderService --> S3
PlantUML Diagrams
Class Diagram:
@startumlclass User {+id: string+email: string+name: string+authenticate()+updateProfile()}class Product {+id: string+name: string+price: number+getDetails()}class Order {+id: string+userId: string+items: Product[]+total: number+createOrder()+processPayment()}User "1" -- "*" OrderOrder "*" -- "*" Product@enduml
Component Diagram:
@startumlpackage "Frontend" {[React Components][Redux Store][API Client]}package "Backend" {[Express Server][Auth Middleware][Business Logic]}package "Data" {database "PostgreSQL"database "Redis"}[React Components] --> [Redux Store][React Components] --> [API Client][API Client] --> [Express Server][Express Server] --> [Auth Middleware][Auth Middleware] --> [Business Logic][Business Logic] --> PostgreSQL[Business Logic] --> Redis@enduml
Deployment Diagram
Infrastructure Visualization:
graph TBsubgraph Cloud Providersubgraph FrontendCDN[CDN / CloudFront]Static[Static Hosting]endsubgraph ApplicationLB[Load Balancer]App1[App Server 1]App2[App Server 2]App3[App Server 3]endsubgraph DataPrimary[(Primary DB)]Replica[(Read Replica)]Cache[(Redis Cluster)]endsubgraph QueueMQ[Message Queue]Worker1[Worker 1]Worker2[Worker 2]endendUsers((Users)) --> CDNCDN --> StaticUsers --> LBLB --> App1LB --> App2LB --> App3App1 --> PrimaryApp2 --> PrimaryApp3 --> PrimaryApp1 --> ReplicaApp2 --> ReplicaApp3 --> ReplicaApp1 --> CacheApp2 --> CacheApp3 --> CacheApp1 --> MQMQ --> Worker1MQ --> Worker2Worker1 --> PrimaryWorker2 --> Primary
Phase 4: Diagram Output
I'll create diagram files in your project:
File Creation:
docs/architecture/components.mmd- Component diagramdocs/architecture/data-flow.mmd- Data flow diagramdocs/architecture/deployment.mmd- Deployment diagramdocs/architecture/sequence.mmd- Sequence diagramsdocs/architecture/README.md- Documentation with rendered diagrams
Markdown Integration:
# System Architecture## Component Diagram
[diagram content]
## Data Flow
[diagram content]
This automatically renders on GitHub, GitLab, and many documentation platforms.
Token Optimization
Expected range: 1,400–4,200 tokens (initial), 500 tokens (cache hit)
Caching: Caches architecture analysis in .claude/cache/architecture/ for 7 days. Invalidated when source structure changes.
Early exit: Returns cached diagram immediately if project structure has not changed.
Patterns used: Grep-before-Read, early exit, caching, Bash for system queries