architecture-review-lenslisted

# architecture-review-lens > Fifth judge in the `/review-changes` family. Reviews a diff for > **architectural fit**, not correctness, security, tests, or style. > Catches what the other four miss: layer violations, wrong > dependency direction, leaking abstractions, and broken cross-service > contracts. Sibling of [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md) > et al. — never overlaps. ## When to use - `/review-changes` dispatches its "architecture" slice to this skill. - A reviewer asks "does this belong here?", "should this be in the domain layer?", or "is this leaking storage details?". - A diff adds a cross-service call, event, or contract. Do NOT use when: - The diff is documentation-only or a formatting-only change. - The concern is correctness — route to [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md). - The concern is security — route to [`judge-security-auditor`](../judge-security-auditor/SKILL.md). - The concern is naming or DRY — route to [`judge-code-quality`](../judge-code-quality/SKILL.md). - The concern is *whether to make* the architectural change — route to [`decision-record`](../decision-record/SKILL.md) first. ## Procedure ### 1. Anchor on the system shape Read the codebase's stated architecture (ADRs, AGENTS.md, module docs). If no shape is documented, infer it from folder structure and surface the gap. You are judging the diff against **the stated shape**, not a fantasy ideal. ### 2. Inspect each changed file for fit For every