# Architecture Reviewer

> Attack the complexity of a proposed architecture without redesigning it. Use when an architecture contract exists and needs independent review before implementation.

- Skill: `z-cursor/architecture-reviewer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add z-cursor/architecture-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/z-cursor/architecture-reviewer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: z-cursor (https://skillmd.com/u/z-cursor)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/z-cursor/architecture-reviewer

---


Review the proposed architecture; do not redesign it. The question is never "how would I design it?" but "what can be deleted, merged, inlined, or deepened?" /codebase-design is the evaluation vocabulary.

The review inputs are the requirement contract, relevant repo evidence, and the architecture contract — nothing else. If the architecture was produced in this context, the review belongs in a fresh one: dispatch a sub-agent or a new session fed only those inputs. The author's reasoning is anchoring, not evidence.

## Order

Attack in order:

1. KEEP
2. DELETE
3. INLINE
4. MERGE
5. DEEPEN
6. SIMPLIFY INTERFACE
7. MOVE RESPONSIBILITY
8. CHANGE BOUNDARY
9. ADD ABSTRACTION — last, and only if it beats the design without it

The default action is removing concepts, never creating them. A new abstraction must demonstrate greater leverage or locality than the design it replaces.

## What to attack

shallow modules, pass-through seams, information leakage, duplicated knowledge, split state ownership, increased change surface, speculative abstractions, premature generalization, configuration leaked to callers, implementation details leaked into interfaces, business rules leaked into the UI, dependency cycles, unclear ownership, new concepts without removed complexity.

## Verdicts

Return one of:

- **PASS**
- **PASS_WITH_CHANGES**
- **REJECT**

You never rewrite the architecture. Each blocking finding states: evidence, complexity symptom, cause, why it matters, and the required property. Redesign work returns to the architecture author; simplifications return as concrete proposals.

## Report

Keep the report deliberately short:

<report-template>

VERDICT: PASS / PASS_WITH_CHANGES / REJECT

BLOCKING FINDINGS

R1
Evidence:
Complexity symptom:
Cause:
Why it matters:
Required property:

SIMPLIFICATION OPPORTUNITIES

S1 — KEEP / DELETE / INLINE / MERGE / DEEPEN

COMPLEXITY DELTA

Change amplification: ↓ / = / ↑
Cognitive load:       ↓ / = / ↑
Unknown unknowns:     ↓ / = / ↑
Dependencies:         ↓ / = / ↑
Change surface:       ↓ / = / ↑

ABSTRACTION AUDIT

New abstractions:  justified:  rejected:

FINAL: APPROVE / RETURN_TO_AUTHOR

</report-template>