| name | architecture-review |
| description | Architecture review and design validation. Evaluates system designs against best practices, identifies anti-patterns, and ensures architectural decisions align with non-functional requirements. |
| version | 1.1.0 |
| model | sonnet |
| invoked_by | both |
| user_invocable | true |
| tools | ["Read","Write","Edit","Glob","Grep"] |
| best_practices | ["Evaluate designs against SOLID principles","Check for anti-patterns and code smells","Verify non-functional requirements","Document architectural decisions","Always document trade-offs explicitly"] |
| error_handling | graceful |
| streaming | supported |
| verified | true |
| lastVerifiedAt | "2026-02-22T00:00:00.000Z" |
| source | builtin |
| trust_score | 100 |
| provenance_sha | 0417ac48c5242cbc |
Architecture Review Skill
Architecture Review Skill - Evaluates system designs against best practices, identifies anti-patterns, and ensures architectural decisions align with non-functional requirements (scalability, maintainability, security, performance).
- Reviewing system architecture designs
- Identifying anti-patterns and architectural smells
- Validating against SOLID, DRY, YAGNI principles
- Assessing non-functional requirements
- Recommending architectural improvements
Step 1: Gather Architecture Context
Understand the current architecture by:
- Read project structure: Use Glob to map directory structure
- Identify key components: Find entry points, services, data layers
- Review dependencies: Check package.json, imports, module graph
- Understand data flow: Trace requests through the system
Step 2: Evaluate Design Principles
Check adherence to fundamental principles:
SOLID Principles:
- Single Responsibility: Does each class/module have one reason to change?
- Open/Closed: Can behavior be extended without modification?
- Liskov Substitution: Are subtypes substitutable for base types?
- Interface Segregation: Are interfaces focused and minimal?
- Dependency Inversion: Do high-level modules depend on abstractions?
Other Principles:
- DRY: Is logic duplicated unnecessarily?
- YAGNI: Are there unused or speculative features?
- Separation of Concerns: Are responsibilities properly divided?
Step 3: Check for Anti-Patterns
Identify common anti-patterns:
- God Class/Module: Classes doing too much
- Spaghetti Code: Tangled, hard-to-follow logic
- Circular Dependencies: Modules that reference each other
- Feature Envy: Classes that use other classes' data excessively
- Shotgun Surgery: Changes that require touching many files
- Leaky Abstractions: Implementation details exposed to consumers
Step 4: Assess Non-Functional Requirements
Evaluate against NFRs:
- Scalability: Can the system handle increased load?
**Example Review Request**:
