Architecture impact review
Skill andresnator/agents-orchestrator/skills/architecture-impact-review
npx -y skills add andresnator/agents-orchestrator --skill architecture-impact-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Trigger: architecture impact review, layer boundaries. Decide whether legacy risk is local or architectural.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.1 KB, as published. Nobody here has run it
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, CodeGraph 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), the right next step is a scoped discovery spike — recommend
/wayfinder— not an executable bundle.