Architectural Review and Guidance

Architect Review is an expert-persona skill that reviews system architecture and major design changes as a master software architect. It works through a fixed response approach: analyze the system's current architectural context, assess the impact of a proposed change (High/Medium/Low), evaluate compliance against established patterns, identify architectural violations or anti-patterns, recommend concrete improvements with tradeoffs, consider scalability implications, and document decisions as Architecture Decision Records when needed, ending with concrete implementation guidance.

Use it when reviewing system architecture or a major design change, evaluating scalability, resilience, or maintainability impact, checking compliance with architecture standards, or seeking guidance on a complex distributed system. Do not use it for a small code review with no architectural impact, a change that is minor and local to a single module, or when there isn't enough system context or requirements to actually assess the design - its own safety guidance is to avoid approving high-risk changes without a validation plan and to document assumptions and dependencies so regressions can be traced back to them.

Inputs are the system's context, goals, and constraints, plus the specific design or change under review - example interactions include "review this microservice design for proper bounded context boundaries," "assess the architectural impact of adding event sourcing," or "evaluate our CI/CD pipeline architecture for scalability and security." Output is a structured assessment: identified risks, an impact rating, specific refactoring recommendations with tradeoffs, scalability considerations, and - where warranted - an Architecture Decision Record plus next steps for validation.

Its knowledge base spans clean architecture and hexagonal architecture, microservices with proper service boundaries, event-driven architecture (event sourcing, CQRS), Domain-Driven Design (bounded contexts, ubiquitous language), service mesh (Istio, Linkerd, Consul Connect), event streaming (Kafka, Pulsar, NATS), resilience patterns (circuit breaker, bulkhead, Saga, Outbox), cloud-native patterns (Kubernetes, Terraform/Pulumi/CloudFormation, GitOps), security architecture (Zero Trust, OAuth2/OIDC/JWT, Vault-based secret management), data architecture (polyglot persistence, data mesh, database-per-service), and documentation practices (the C4 model, ADRs, OpenAPI/Swagger). It draws explicitly on Martin Fowler and Sam Newman's microservices writing, Eric Evans and Vaughn Vernon's DDD, and Robert C. Martin's Clean Architecture.

Teams and engineers who need an architectural second opinion before committing to a significant design decision - reviewing a new microservice's boundaries, weighing serverless versus containerized deployment, assessing a service mesh or event-driven redesign, or checking a database schema for proper data isolation across services. Its behavioral stance favors evolutionary architecture and enabling change over rigid gatekeeping, balancing technical rigor against actual business value rather than pursuing architectural purity for its own sake.