architecture-review

Table of Contents

• Quick Start
• When to Use
• Progressive Loading
• Required TodoWrite Items
• Workflow
• Step 1: Establish Context (arch-review:context-established)
• Step 2: ADR Audit (arch-review:adr-audit)
• Step 3: Interaction Mapping (arch-review:interaction-mapping)
• Step 4: Principle Checks (arch-review:principle-checks)
• Step 5: Risks and Actions (arch-review:risks-actions)
• Testing

Testing

Run pytest plugins/pensive/tests/skills/test_architecture_review.py to verify review logic.

• Architecture Principles Checklist
• Coupling
• Cohesion
• Layering
• Evolution

Architecture Review Workflow

Architecture assessment against ADRs and design principles.

Quick Start

/architecture-review

When To Use

• Approving reimplementations.
• Large-scale refactoring reviews.
• System design changes.
• New module/service introduction.
• Dependency restructuring.

When NOT To Use

• Selecting architecture paradigms - use archetypes skills
• API surface review - use api-review
• Selecting architecture paradigms - use archetypes skills
• API surface review - use api-review

Progressive Loading

Load modules based on review scope:

• modules/adr-audit.md (~400 tokens): ADR verification and documentation.
• modules/coupling-analysis.md (~450 tokens): Dependency analysis and boundary violations.
• modules/principle-checks.md (~500 tokens): Code quality, security, and performance.
• modules/fpf-methodology.md (~800 tokens): FPF (Functional, Practical, Foundation) multi-perspective review methodology.
• modules/ceremony-audit.md (~600 tokens): Manual lenses for mapping layers that never diverge. Passthrough mappers, twin types, speculative DTOs, single-implementation interfaces. Includes the IO boundary counter-signal.

Load all modules for full reviews. For focused reviews, load only relevant modules.

Required TodoWrite Items

1. arch-review:context-established: Repository, branch, motivation.
2. arch-review:adr-audit: ADR verification and new ADR needs.
3. arch-review:interaction-mapping: Module coupling analysis.
4. arch-review:invariant-check: Invariant conflict detection and 3-option analysis.
5. arch-review:principle-checks: LoD, security, performance.
6. arch-review:ceremony-audit: Mapping layers that never diverge.
7. arch-review:risks-actions: Recommendation and follow-ups.
8. arch-review:findings-verified

Workflow

Step 1: Establish Context (arch-review:context-established)

Confirm repository and branch:

pwd
git status -sb

Document:

• Feature/bug/epic motivating review.
• Affected subsystems.
• Architectural intent from README/docs.
• Design trade-off assumptions.

Step 2: ADR Audit (arch-review:adr-audit)

Load: modules/adr-audit.md

• Locate ADRs in project.
• Verify required sections.
• Check status flow.
• Confirm immutability compliance.
• Flag need for new ADRs.

Step 3: Interaction Mapping (arch-review:interaction-mapping)

Load: modules/coupling-analysis.md

• Diagram before/after module interactions.
• Verify composition boundaries.
• Check data ownership clarity.
• Validate dependency flow direction.
• Identify coupling violations.

Step 3.5: Invariant Conflict Detection (arch-review:invariant-check)

Before checking principles, identify whether the changes conflict with existing design invariants. This is the highest-judgment step in architecture review: models get this wrong more often than any other call.

Identify existing invariants:

1. Scan ADRs for recorded decisions still in "accepted" status
2. Check module boundaries (are imports crossing layers that previously didn't?)
3. Check data flow direction (does data now flow in a new direction?)
4. Check API contracts (are public interfaces changing shape?)
5. Check structural patterns (is a new pattern being introduced alongside an existing one?)

# Detect boundary crossings in changed files
git diff --name-only | while read f; do
  head -20 "$f" 2>/dev/null | rg "^(import|from|use |require)" || true
done

When a conflict is detected:

Do NOT recommend a resolution. Present the three options and escalate to human judgment:

Output format:

### Invariant Conflicts

[I1] **[Invariant name]** — [what decision it represents]
- **Location**: file.py:42
- **Anchor**: `verbatim source text at line 42`
- **Conflict**: [what change clashes]
- **Options**: Preserve / Layer / Revise
- **Recommendation**: ESCALATE TO HUMAN
- **Risk if wrong**: [what compounds]

Why this matters: Bad invariant decisions compound. After a few wrong calls the codebase becomes unsalvageable. This is a judgment problem rather than a context problem: the agent should surface it, not solve it.

Step 4: Principle Checks (arch-review:principle-checks)

Load: modules/principle-checks.md

• Law of Demeter.
• Anti-slop patterns.
• Security (input validation, least privilege).
• Performance (N+1 queries, caching).

Step 4.5: Ceremony Audit (arch-review:ceremony-audit)

Load: modules/ceremony-audit.md

Coupling analysis (Step 3) finds boundaries that leak. This step finds the opposite failure: boundaries that cost something and separate nothing.

• Passthrough mappers whose fields are all 1:1 copies.
• Twin types that are structurally identical across layers.
• Speculative DTOs with no external contract pinning their shape.
• Interfaces with exactly one implementation and no test double.

Each finding must name the need the ceremony serves today. If no current need can be named, the ceremony is the finding.

Do not flag mappers at an IO boundary. They are load-bearing even when they look like passthroughs, because they stop future internal fields from escaping. See the counter-signal in the module.

Step 5: Risks and Actions (arch-review:risks-actions)

Summarize using imbue:diff-analysis/modules/risk-assessment-framework:

• Current vs proposed architecture.
• Business impact.
• Technical debt implications.

List follow-ups with owners and dates.

Provide recommendation:

• Approve: Architecture sound.
• Approve with actions: Minor issues to address.
• Block: Fundamental problems requiring redesign.

Architecture Principles Checklist

Coupling

• Dependencies follow defined boundaries.
• No circular dependencies.
• Extension points used properly.
• Abstractions don't leak.

Cohesion

• Related functionality grouped.
• Single responsibility per module.
• Clear module purposes.

Layering

• Layers have clear responsibilities.
• Dependencies flow downward.
• No layer bypassing.

Invariants

• Existing design invariants identified.
• Conflicts between changes and invariants surfaced.
• Three-option analysis (preserve/layer/revise) presented.
• Invariant changes escalated to human judgment.
• No silent invariant revisions in the diff.

Evolution

• Changes are reversible.
• Migration paths are clear.
• ADRs document decisions.

Verify Findings Are Grounded (arch-review:findings-verified)

Every finding must cite a real location and a verbatim anchor. Write findings to .review/findings.json and confirm each citation resolves:

python plugins/imbue/scripts/citation_verifier.py \
  --findings .review/findings.json --repo-root .

Drop or label UNVERIFIED any finding the verifier fails (exit 1); only verified findings enter the report. See Skill(imbue:review-core) Step 5 and Skill(imbue:structured-output) for the schema.

Exit Criteria

• Context established, ADR audit complete, interaction mapping done, invariant conflicts surfaced, principle checks run, risks and actions documented.
• Every reported finding carries a Location + verbatim Anchor confirmed by citation_verifier.py (exit 0), or unverified findings were dropped or labeled UNVERIFIED.