Peer review architecture for quality, risks, and optimization opportunities. Analyzes scalability bottlenecks, security vulnerabilities, performance optimization, technology fit, and provides prioritized recommendations. Use when reviewing proposed architecture documents for quality assurance, risk identification, or architectural decision validation.
acceptance
[{"review_complete":"All architectural dimensions reviewed"},{"risks_identified":"Risks assessed and prioritized"},{"recommendations_provided":"Actionable recommendations with priorities"},{"alternatives_considered":"Alternative approaches evaluated"}]
inputs
{"architecture_file":{"type":"string","required":true,"description":"Path to architecture document"},"requirements_file":{"type":"string","required":false,"description":"Path to requirements (for comparison)"},"focus_area":{"type":"string","required":false,"description":"security | scalability | performance | cost | maintainability | all"}}
outputs
{"review_summary":{"type":"string","description":"Overall review summary"},"risks":{"type":"array","description":"Identified risks with severity levels"},"recommendations":{"type":"array","description":"Prioritized improvement recommendations"},"alternatives_evaluated":{"type":"number","description":"Number of alternative approaches considered"}}
Conduct peer review of architecture documents to identify risks, bottlenecks, optimization opportunities, and provide expert recommendations. Goes beyond validation to critically analyze architecture quality and suggest improvements.
## Risk: [Risk Title]**Severity:** Critical | High | Medium | Low
**Likelihood:** High | Medium | Low
**Impact:** [Description of impact]
**Mitigation:** [How to address]
**Effort:** [Time/cost to mitigate]
Example:
## Risk: Database Becomes Bottleneck at Scale**Severity:** High (🟠)
**Likelihood:** High (projected 50K users in 6 months)
**Impact:** Performance degradation, poor user experience, potential downtime
**Mitigation:**1. Add database read replicas (3 hours)
2. Implement Redis caching (4 hours)
3. Plan sharding strategy (2 days research)
**Effort:** ~2 person-days
10. Generate Recommendations
Categorize recommendations by priority:
Priority Levels:
P0 (Critical): Must address before production
P1 (High): Address before launch or soon after
P2 (Medium): Address in next quarter
P3 (Low): Nice-to-have improvements
Recommendation Template:
**[P0] Add Input Validation**-**Issue:** No validation layer, vulnerable to SQL injection/XSS
-**Recommendation:** Implement Zod schemas for all API inputs
-**Impact:** Critical security vulnerability
-**Effort:** 1-2 days
-**Resources:** [Zod documentation link]
Prioritization Criteria:
Security issues → P0/P1
Scalability blockers → P1/P2
Performance issues → P1/P2
Maintainability concerns → P2/P3
Cost optimizations → P2/P3
11. Evaluate Alternatives
For each major architectural decision, consider alternatives:
Alternative Evaluation Template:
### Alternative: [Option Name]**Current Choice:** [What's in architecture]
**Alternative:** [Different approach]
**Pros:**- Benefit 1
- Benefit 2
**Cons:**- Drawback 1
- Drawback 2
**Recommendation:** Keep current | Switch to alternative | Consider for future
**Rationale:** [Why this recommendation]
Example:
### Alternative: Microservices vs. Modular Monolith**Current Choice:** Microservices architecture
**Alternative:** Modular Monolith
**Pros:**- Simpler deployment
- Lower operational overhead
- Faster development initially
- Easier debugging
**Cons:**- Less independent scaling
- Potential coupling over time
- Harder to extract services later
**Recommendation:** Switch to Modular Monolith for now
**Rationale:** Team is small (3 developers), complexity of microservices outweighs benefits at current scale. Plan to extract microservices when team grows to 10+ developers.
