architecture-lens

Architecture Lens

Review code-level structure using Richards and Ford's Fundamentals of Software Architecture and Practical Model-Driven Enterprise Architecture. Judge ease of change through coupling, placement, cohesion, dependency direction, and scope. A real choice has a tradeoff; state its cost without manufacturing alternatives to settled decisions.

Use macro-architecture for system style, domain-driven-design for domain modeling, and full-review for a correctness or security review.

Select the lens

Decision or review	Method to load
Unresolved approach, boundary, library, sync/async, or build/reuse choice	Lens 1: references/decision-review.md
Tangled code or deciding what to split, extract, or merge	Lens 2: references/coupling-review.md
Layer placement, cohesion, dependency direction, or scope in a diff or design	Lenses 3–6: references/structural-review.md

Combine methods only when the question needs them. Inspect the affected code and its contracts; a local boundary review does not require mapping the whole repository. Reuse existing design decisions and evidence.

Connascence ranks coupling by strength × locality × degree. Strong coupling can be acceptable locally; distant dynamic coupling deserves attention. Keep the smallest coherent shape: remove speculative scope without introducing more indirection than the change needs.

Authority and output

This skill reports findings. A user's request for scoped fixes authorizes those edits. A design-gate or other read-only reviewer invocation returns findings only and overrides standalone edit routes.

For a standalone review, group findings by selected lens with file:line, the violated rule, and a concrete fix. For a decision, state the chosen shape, actual tradeoff, and next move. A small decision can use two lines. A clean lens returns clean; do not invent findings or a counterpoint to fill a category.

Under design-gate, use the caller's canonical gate result. A load-bearing issue can require revision; cosmetic preference cannot.

Use all three or no ADR: hard to reverse, surprising without context, and a real tradeoff. Record on settle using references/adr-template.md when all three apply. Otherwise preserve the decision in the existing task or review note.

In an interview, contribute the decision, rationale, constraints, and source references to the existing decision record. Standalone report and implementation mechanics do not apply at that stage.

Additional references

• references/verification-menu.md: when a finding needs an executable check.
• references/fitness-functions.md: when a durable architecture rule needs enforcement.
• references/risk-and-diagrams.md: when a migration, availability boundary, unproven technology, or requested diagram needs a risk model.

The selected methods link to their detailed taxonomies and checklists. Load those only when the decision needs them.