How do I install the Architecture Reviewer skill?

Run npx skillmds@latest add z-cursor/architecture-reviewer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Architecture Reviewer safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Architecture Reviewer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Architecture Reviewer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Architecture Reviewer?

z-cursor (@z-cursor) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Architecture Reviewer by z-cursor — Agent Skill

Name: Architecture Reviewer
Author: z-cursor

File contents

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:

KEEP
DELETE
INLINE
MERGE
DEEPEN
SIMPLIFY INTERFACE
MOVE RESPONSIBILITY
CHANGE BOUNDARY
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:

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

---name: architecture-reviewerdescription: Attack the complexity of a proposed architecture without redesigning it. Use when an architecture contract exists and needs independent review before implementation.---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.## OrderAttack in order:1. KEEP2. DELETE3. INLINE4. MERGE5. DEEPEN6. SIMPLIFY INTERFACE7. MOVE RESPONSIBILITY8. CHANGE BOUNDARY9. ADD ABSTRACTION — last, and only if it beats the design without itThe default action is removing concepts, never creating them. A new abstraction must demonstrate greater leverage or locality than the design it replaces.## What to attackshallow 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.## VerdictsReturn 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.## ReportKeep the report deliberately short:<report-template>VERDICT: PASS / PASS_WITH_CHANGES / REJECTBLOCKING FINDINGSR1Evidence:Complexity symptom:Cause:Why it matters:Required property:SIMPLIFICATION OPPORTUNITIESS1 — KEEP / DELETE / INLINE / MERGE / DEEPENCOMPLEXITY DELTAChange amplification: ↓ / = / ↑Cognitive load: ↓ / = / ↑Unknown unknowns: ↓ / = / ↑Dependencies: ↓ / = / ↑Change surface: ↓ / = / ↑ABSTRACTION AUDITNew abstractions: justified: rejected:FINAL: APPROVE / RETURN_TO_AUTHOR</report-template>

Frequently asked questions

Architecture Reviewer