How do I install the Review Architecture skill?

Run npx skillmds@latest add mpiton/review-architecture 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 Review Architecture safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Review Architecture?

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 Review Architecture free to use?

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

Who published Review Architecture?

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

Review Architecture by mpiton — Agent Skill

Name: Review Architecture
Author: mpiton

Review Architecture

Read-only review of an implementation diff for structural quality - placement, naming, project conventions, and domain responsibilities. Returns OK or REGENERATE. Invoked in parallel with review-intent by green-cycle, also callable standalone on a PR or diff.

mpiton 04e0c4a 2.4 KB Updated Sep 17, 2026

File contents

review-architecture

Reviewer "architecture" from Phase 4b. Read-only critique of a production-code diff. Runs in parallel with review-intent.

When to use

Called by green-cycle on the implementation diff produced by attempt N.
Standalone: /review-architecture <diff-or-pr> to audit any change.

Inputs

diff — the staged or committed diff to review.
Project conventions, discovered from the repo:
- CONTEXT.md (shared language).
- docs/adr/ (architecture decision records).
- Existing file structure under the touched module.

Output format

Three sections, then a verdict.

1. Structure (placement)

New files live in the layer matching their responsibility (e.g. domain logic in domain/, adapters in infra/).
Public exports from a module match the module's contract; nothing leaks across layer boundaries.
The diff respects the import direction conventions of the project (no inward dependencies from infra into domain, etc.).

Flag with PLACEMENT: <path> — <issue>.

2. Naming and conventions

Identifiers use the project's shared language (terms from CONTEXT.md). No synonyms, no jargon drift.
File naming, casing, and pluralization follow the local convention.
Public type / function signatures match the style of neighbouring code (parameter order, error vs result, sync vs async).

Flag with NAMING: <symbol> — <issue>.

3. Responsibilities

Each new function / class has a single coherent responsibility.
Domain logic is in domain code; orchestration in application services; I/O in adapters. No mixing.
No business rule duplicated across layers.
Existing patterns are reused; the diff does not introduce a parallel mechanism for a thing the codebase already does.

Flag with RESPONSIBILITY: <symbol> — <issue>.

Verdict

Last line: VERDICT: OK (no flags) or VERDICT: REGENERATE (any flag).

Contract

Read-only. Never edits files.
Reviews ONLY the diff; does not propose unrelated refactors of pre-existing code.
Flags must be actionable (point to a specific line / symbol / file).

---name: review-architecturedescription: Read-only review of an implementation diff for structural quality - placement, naming, project conventions, and domain responsibilities. Returns OK or REGENERATE. Invoked in parallel with review-intent by green-cycle, also callable standalone on a PR or diff.---# review-architectureReviewer "architecture" from Phase 4b. Read-only critique of a production-code diff. Runs in parallel with `review-intent`.## When to use- Called by `green-cycle` on the implementation diff produced by attempt N.- Standalone: `/review-architecture <diff-or-pr>` to audit any change.## Inputs- `diff` — the staged or committed diff to review.- Project conventions, discovered from the repo: - `CONTEXT.md` (shared language). - `docs/adr/` (architecture decision records). - Existing file structure under the touched module.## Output formatThree sections, then a verdict.### 1. Structure (placement)- New files live in the layer matching their responsibility (e.g. domain logic in `domain/`, adapters in `infra/`).- Public exports from a module match the module's contract; nothing leaks across layer boundaries.- The diff respects the import direction conventions of the project (no inward dependencies from infra into domain, etc.).Flag with `PLACEMENT: <path> — <issue>`.### 2. Naming and conventions- Identifiers use the project's shared language (terms from `CONTEXT.md`). No synonyms, no jargon drift.- File naming, casing, and pluralization follow the local convention.- Public type / function signatures match the style of neighbouring code (parameter order, error vs result, sync vs async).Flag with `NAMING: <symbol> — <issue>`.### 3. Responsibilities- Each new function / class has a single coherent responsibility.- Domain logic is in domain code; orchestration in application services; I/O in adapters. No mixing.- No business rule duplicated across layers.- Existing patterns are reused; the diff does not introduce a parallel mechanism for a thing the codebase already does.Flag with `RESPONSIBILITY: <symbol> — <issue>`.### VerdictLast line: `VERDICT: OK` (no flags) or `VERDICT: REGENERATE` (any flag).## Contract- Read-only. Never edits files.- Reviews ONLY the diff; does not propose unrelated refactors of pre-existing code.- Flags must be actionable (point to a specific line / symbol / file).

Frequently asked questions