Design review

Conduct a structured design review of a module, feature, or system component.

Steps

1. Identify the scope of review from the argument (module path, feature name, or PR number).
2. Map the component boundaries:
   • Entry points (APIs, event handlers, CLI commands).
   • Internal modules and their responsibilities.
   • External dependencies and integration points.
   • Data flow from input to output.
3. Evaluate against design principles:
   • Single Responsibility: Does each module have one clear purpose?
   • Dependency Direction: Do dependencies flow inward (clean architecture)?
   • Interface Segregation: Are interfaces minimal and focused?
   • Error Handling: Are failures handled consistently and explicitly?
   • Testability: Can components be tested in isolation?
4. Check for common anti-patterns:
   • God objects or modules with too many responsibilities.
   • Circular dependencies between modules.
   • Leaky abstractions exposing internal implementation.
   • Configuration scattered across multiple locations.
5. Assess scalability and operational concerns:
   • Can this handle 10x current load?
   • What are the failure modes and recovery paths?
   • Is observability built in (logging, metrics, tracing)?
6. Produce a structured review with actionable recommendations.

Format

## Design Review: <Component Name>

### Architecture Score: <1-5>/5

### Strengths
- What is well designed

### Concerns
- CRITICAL: Issues that need immediate attention
- WARNING: Issues to address before next milestone

### Recommendations
1. Specific actionable improvement
2. Specific actionable improvement

### Diagram
<Mermaid diagram of current architecture>

Rules

• Be constructive; pair every criticism with a concrete suggestion.
• Focus on structural issues, not cosmetic ones.
• Consider the team's current constraints and pragmatic tradeoffs.
• Reference specific files and line numbers where applicable.