Code-to-Diagram — Analysis Methodology
Load this file when the user asks to visualize existing code, analyze a codebase, or generate diagrams from source files.Workflow
- Identify scope — what part of the code to diagram
- Choose analysis strategy — which patterns to look for
- Extract structure — read relevant files
- Select diagram type — based on what was found
- Generate diagram — create .mmd file
- Validate and render — as usual
Analysis Strategies by Request Type
”Show me the architecture”
What to look for:- Project root structure (folders, entry points)
- Package.json / pyproject.toml / Cargo.toml for dependencies
- Docker files, docker-compose.yml for services
- Infrastructure-as-code (CDK, Terraform, CloudFormation, Pulumi)
- Environment variables for external service connections
- Root directory listing
- docker-compose.yml / Dockerfile
- Infrastructure files (cdk/, terraform/, cloudformation/)
- Main entry point (src/main.ts, app.py, cmd/main.go)
- Config files for external connections
”Diagram the database schema”
What to look for:- ORM models/entities (TypeORM, Prisma, SQLAlchemy, Drizzle)
- Migration files
- Schema definition files (.prisma, models.py, entities/)
- Foreign key references
- Enum definitions
- Schema files (schema.prisma, models/, entities/)
- Migration files (for relationship confirmation)
- Seed files (for understanding data relationships)
- Each model/entity → ERD entity
- Each field → attribute with type
@relation/ ForeignKey → relationship@id/ primary_key → PK marker@unique→ UK marker- Foreign key fields → FK marker
“Show me the API flow”
What to look for:- Route definitions (controllers, routers, handlers)
- Middleware chain
- Service layer calls
- External API calls
- Database queries in the flow
- Route/controller files
- Middleware definitions
- Service files called by controllers
- Repository/data-access files
- Each controller/handler → participant
- Each service class → participant
- Each external call → external participant
- Method calls → synchronous messages (->>)
- Returns → response messages (—>>)
- If/else in code → alt blocks
- Try/catch → opt or break blocks
- Loops → loop blocks
”Show me the module dependencies”
What to look for:- Import statements between modules
- Module registration (NestJS modules, Angular modules)
- Dependency injection configuration
- Package/module boundaries
- Each module/package → class or node
- Import/dependency → arrow
- Circular dependencies → highlight (bidirectional or color)
“Show me the state machine”
What to look for:- Enum definitions for states/status
- Switch/case or if/else chains on status
- State machine libraries (XState, statechart)
- Transition functions
- Event handlers that change state
- Each enum value → state
- Each transition function → edge with event label
- Initial state → [*] —> state
- Terminal states → state —> [*]
- Guard conditions → edge labels
”Show me the class structure”
What to look for:- Class definitions with methods and properties
- Interfaces and abstract classes
- Inheritance (extends)
- Composition (has-a fields)
- Implementation (implements)
class X extends Y→ inheritance (Y <|-- X)class X implements Y→ realization (Y ..|> X)- Field of type
Yin classX→ association (X --> Y) - Array/collection of
YinX→ aggregation (X o-- Y) Ycreated and owned byX→ composition (X *-- Y)public→+,private→-,protected→#
Framework-Specific Patterns
NestJS
React / Next.js
Python / FastAPI
Multi-Diagram Strategy
For complex codebases, recommend generating multiple focused diagrams rather than one overwhelming diagram:- System Context (C4 Level 1) — always, as the overview
- Container Diagram (C4 Level 2) — for multi-service architectures
- ERD — if database models exist
- Key Flow Sequence — for the most important user-facing flow
- State Diagram — if significant state machines exist
Output Format
When generating from code, always:-
Add a header comment linking to source:
- Use names that match the code (class names, method names)
-
Include a brief note about what was excluded:
-
Flag uncertainty: