home / skills / shotaiuchi / dotclaude / review-architecture

review-architecture skill

/dotclaude/skills/review-architecture

This skill reviews architecture and design of code, highlighting SOLID, layering, modularity, and maintainability improvements for scalable systems.

npx playbooks add skill shotaiuchi/dotclaude --skill review-architecture

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.0 KB
---
name: review-architecture
description: >-
  Architecture-focused code review. Apply when reviewing code for
  design patterns, SOLID principles, layer separation, dependency direction,
  modularity, coupling, cohesion, and maintainability.
user-invocable: false
---

# Architecture Review

Review code from an architecture and design perspective.

## Review Checklist

### SOLID Principles
- Single Responsibility: Each class/module has one reason to change
- Open/Closed: Extended via abstraction, not modification
- Liskov Substitution: Subtypes are substitutable for base types
- Interface Segregation: No forced dependency on unused interfaces
- Dependency Inversion: Depend on abstractions, not concretions

### Layer Separation
- Verify proper separation of concerns (UI / Domain / Data)
- Check dependency direction (inner layers don't depend on outer)
- Look for business logic leaking into UI or data layers
- Verify data mapping between layers (Entity / Model / DTO)

### Modularity & Coupling
- Check for tight coupling between unrelated modules
- Verify proper use of dependency injection
- Look for god classes or modules with too many responsibilities
- Check for circular dependencies

### Consistency & Patterns
- Verify consistency with existing codebase patterns
- Check naming conventions are followed
- Look for reinvented patterns where existing utilities exist
- Verify error handling follows project conventions

### Extensibility & Maintainability
- Check if changes are easy to extend without modification
- Verify testability (dependencies are injectable)
- Look for hardcoded values that should be configurable
- Check documentation for complex logic

## Output Format

Report findings with categories:

| Category | Description |
|----------|-------------|
| Violation | Breaks established architecture rules |
| Concern | May cause problems as codebase grows |
| Suggestion | Improvement for better maintainability |
| Positive | Good pattern worth highlighting |

Overview

This skill performs architecture-focused code reviews to surface design, modularity, and maintainability issues. It evaluates SOLID adherence, layer separation, dependency direction, coupling/cohesion, and patterns consistency to produce actionable findings. The output uses clear categories (Violation, Concern, Suggestion, Positive) to prioritize work.

How this skill works

I analyze source code and project structure to identify anti-patterns, misplaced business logic, and dependency issues. I check for SOLID principle violations, verify layer boundaries and data mapping, inspect modularity and circular dependencies, and assess consistency with existing patterns and conventions. Findings are categorized so teams can triage fixes and improvements.

When to use it

  • Before merging large features that touch multiple layers
  • During architectural refactors or module extraction efforts
  • When onboarding to a new codebase to understand design health
  • As part of regular technical debt sprints or QA gates
  • Prior to major releases to reduce maintainability risk

Best practices

  • Enforce single responsibility at module and class levels
  • Depend on interfaces/abstractions and inject dependencies
  • Keep UI, domain, and data layers strictly separated
  • Avoid circular dependencies; prefer clear dependency flow inward
  • Follow existing project naming, error handling, and test conventions

Example use cases

  • Review a pull request that adds a cross-cutting feature affecting UI and data layers
  • Audit a legacy module to plan safe extraction into a separate package
  • Validate a proposed domain model for Liskov and interface segregation issues
  • Assess a microservice to ensure configuration and hardcoded values are externalized
  • Evaluate whether tests and DI make a component easily replaceable and mockable

FAQ

What does a Violation vs. a Concern mean?

A Violation breaks core architectural rules and should be fixed before merging. A Concern may not be immediately blocking but will hinder scaling or maintenance and should be scheduled.

Can this review check for framework-specific best practices?

Yes. I consider project conventions and framework idioms when assessing patterns and consistency, but I focus primarily on architectural principles rather than micro-optimizations.