# Architecture Impact Review

> Trigger: architecture impact review, layer boundaries. Decide whether legacy risk is local or architectural.

- Skill: `andresnator/architecture-impact-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add andresnator/architecture-impact-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andresnator/architecture-impact-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: andresnator (https://skillmd.com/u/andresnator)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/andresnator/architecture-impact-review

---


# Architecture Impact Review
Decide whether the target problem is local or architectural.

## Look for

- Layer violations.
- Domain logic mixed with infrastructure.
- Business logic in controllers, repositories, or DTOs.
- Circular dependencies.
- Coupled modules.
- God classes and services with too many responsibilities.
- Hidden business rules.
- Boundary-crossing dependencies.

Verify coupling, cycles, and boundary crossings from imports, build-file dependencies, or a code-graph index (for example, Graphify MCP/CLI) when available; every boundary claim cites `file:line`.

Keep broad architectural cleanup as follow-up unless it is required for safe characterization.

## Routing rules (local vs architectural)

- **Modules first, deployment last**: modularizing inside the current deployable is always the safe local move and belongs to refactor plans. Extracting a deployable (service) is an architectural decision — defer it to its last responsible moment, the point where not deciding would eliminate the alternative, and route it to the architecture domain.
- **Consistency boundary test**: components that must stay transactionally consistent belong in the same module (local concern); where eventual consistency and domain events are acceptable, a module boundary — and possibly an architectural decision — is in play.
- **Language boundary test**: when the same term means different things across the code under review ("policy", "account"), the scope is straddling a bounded-context boundary; escalate the boundary question instead of refactoring across it.
- **Problem nature test**: if nobody can predict whether the restructuring will work (a complex, experiment-first problem rather than a complicated, analyzable one), recommend the Plan discovery route (`operation=deep-plan intent=discovery`), not an executable change.