| name | architecture-review |
| description | Use when reviewing architecture decisions. C4 model, dependency inversion, hexagonal boundaries. |
Architecture Review
When to Use
∀ plan reviews (standard, complex). ∀ PRs that touch module boundaries.
Checklist
- DEPENDENCY DIRECTION: ∀ import: does it follow domain <- app <- infra <- presentation?
- BOUNDARY CHECK: ∀ new module: is responsibility single and clear?
- PORT/ADAPTER: ∀ external dependency: accessed through port? adapter exists?
- COUPLING: ∀ cross-module call: through interface or direct import?
- ADR: Architecture decision worth recording? -> create ADR
Review Template
| Aspect | Status | Finding |
|---|
| Layer dependency | pass/fail | ... |
| Module boundaries | pass/fail | ... |
| Port coverage | pass/fail | ... |
| Cross-cutting concerns | pass/fail | ... |
Anti-Patterns
- Reviewing code style (that's code-reviewer's job)
- Proposing rewrites for working code (YAGNI)
- ¬reading the spec before reviewing architecture
- Designing for hypothetical future requirements
Rules
- Scope: architecture only, ¬code quality, ¬spec compliance
- ∀ finding: cite specific file + line
- Severity: Critical (blocks) | Important (should fix) | Suggestion (optional)
- ∀ deviation from patterns: justification required