architecture-review

Architecture review and design validation. Evaluates system designs against best practices, identifies anti-patterns, and ensures architectural decisions align with non-functional requirements.

Jump to install

Repository: oimiragieo/agent-studio
Last source activity: April 21, 2026 at 23:45
Detected SKILL.md language: English
Stars: 36
Forks: 6

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

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**:

Review the architecture of src/services/ for scalability and maintainability

## Architecture Review: src/services/

### Summary

The service layer follows a reasonable structure but has some coupling issues...

### Strengths

- Clear separation between API handlers and business logic
- Good use of dependency injection

### Concerns

1. **High Priority**: UserService has 15 methods (God Class)
2. **Medium Priority**: Circular dependency between OrderService and InventoryService
3. **Low Priority**: Some magic numbers in validation logic

### Recommendations

1. Split UserService into UserAuthService and UserProfileService
2. Introduce EventBus to decouple Order and Inventory
3. Extract validation constants to configuration

Anti-Pattern	Why It Fails	Correct Approach
No NFR evaluation	Design may pass functional tests but fail at scale or under attack	Always evaluate performance, security, scalability, observability
Reviewing only the happy path	Systems fail at error boundaries, not in the happy path	Review failure modes, retry behavior, and circuit breakers
Approving without trade-off documentation	Hidden trade-offs become future surprises	Explicitly document all trade-offs with rationale
Single point of failure left undocumented	System has silent fragility that surfaces under load	Map all SPOFs; require mitigation plans for each
Checking SOLID without anti-pattern catalog	Principle adherence doesn't guarantee absence of anti-patterns	Check both principles AND concrete anti-patterns (God Class, Shotgun Surgery, etc.)
Architecture review after implementation starts	Too late to fix structural issues without major rework	Review in design phase, before any code is written

cat .claude/context/memory/learnings.md