| name | analyze-architecture |
| description | Deeply analyze codebase architecture and dependencies. Use when understanding system design, finding patterns, or mapping how components interact. |
| argument-hint | ["component-or-feature"] |
| context | fork |
| agent | Explore |
| allowed-tools | ["Glob","Grep","Read","Bash(git *)"] |
Analyze Codebase Architecture
Perform deep architectural analysis of $ARGUMENTS without cluttering the main context.
Analysis Goals
Investigate and document:
-
Component Structure
- How is $ARGUMENTS organized?
- What are the main modules/files?
- What patterns are being used?
-
Dependencies & Relationships
- What does $ARGUMENTS depend on?
- What depends on $ARGUMENTS?
- Are there circular dependencies?
- Are dependencies appropriately layered?
-
Data Flow
- How does data flow through $ARGUMENTS?
- What are the inputs and outputs?
- Where is state managed?
- Are there side effects?
-
Design Patterns
- What architectural patterns are used?
- Are patterns applied consistently?
- Are there anti-patterns present?
-
Potential Issues
- Tight coupling between components?
- Missing abstractions or too many abstractions?
- Code duplication?
- Complexity hotspots?
Investigation Steps
Step 1: Map the Territory
Use Glob to find all files related to $ARGUMENTS:
Step 2: Understand Key Files
Read the most important files:
- Entry points
- Core business logic
- Public APIs
- Type definitions
For each file, note:
- Purpose and responsibilities
- Key functions/classes
- Exports and imports
Step 3: Trace Dependencies
Use Grep to find:
- Import statements for $ARGUMENTS
- References to key functions
- Test coverage
Create a dependency graph showing relationships.
Step 4: Analyze Patterns
Look for:
- Consistent patterns (good)
- Pattern violations (investigate why)
- Missing patterns (opportunities)
- Overused patterns (complexity)
Step 5: Generate Report
Output Format
Provide a comprehensive report:
Overview
- What is $ARGUMENTS?
- What problem does it solve?
- Where does it fit in the larger system?
Architecture Diagram
[ASCII diagram showing component structure]
Component A
├── Sub-component B
├── Sub-component C
└── Sub-component D
├── Module E
└── Module F
Key Components
For each major component:
- Purpose: What it does
- Location: File paths
- Dependencies: What it uses
- Dependents: What uses it
- Complexity: Lines of code, cyclomatic complexity if notable
Data Flow
Input → [Component A] → [Component B] → Output
↓
[Side Effect]
Patterns Observed
- Pattern 1: Where it's used and why
- Pattern 2: Implementation details
Issues & Recommendations
Issues
- Issue description
- Impact: High/Medium/Low
- Location: file.ts:123
- Recommendation: Specific action
Opportunities
- Improvement description
- Benefit: What would improve
- Approach: How to implement
Metrics
- Total files: X
- Total lines: Y
- Test coverage: Z%
- Key dependencies: List
Notes
- This skill runs in a forked context to avoid cluttering your main conversation
- It can read many files without impacting your working context
- Results are summarized and returned to you when analysis completes
- Use when you need deep investigation without disrupting current work