// Use when evaluating whether a proposed change fits the existing architecture. Prevents layer violations, dependency cycles, and accidental coupling.
Use when the user wants a code review instead of implementation. Prioritizes correctness bugs, behavioral regressions, missing tests, and risky assumptions.
Use when reviewing documentation for accuracy, completeness, and alignment with source code. Catches doc-code drift before it confuses readers.
Use when making changes that should be committed. Enforces atomic commits, meaningful messages, and clean history.
Use when investigating slow execution, high memory usage, or excessive token consumption. Systematic measurement before optimization.
Use when improving code structure without changing behavior. Ensures each refactoring step preserves all existing tests.
Use when reviewing code for security vulnerabilities. Covers prompt injection, path traversal, command injection, and agent-specific attack vectors.
| name | architecture-review |
| description | Use when evaluating whether a proposed change fits the existing architecture. Prevents layer violations, dependency cycles, and accidental coupling. |
| version | 1.0.0 |
| author | Aixlarity |
| license | Apache-2.0 |
| metadata | {"aixlarity":{"tags":["architecture","design","review","modularity"],"related_skills":["code-review","refactoring","writing-plans"]}} |
Every module should have one reason to change. If a proposed change touches three unrelated modules, the architecture has a coupling problem.
These are the rules from AGENTS.md, enforced during architecture review:
aixlarity-cli → aixlarity-core (one-way only)
aixlarity-core never imports from aixlarity-cli
Within aixlarity-core:
tools/registry.rs ← tools/*.rs ← agent.rs ← prompt.rs ← app.rs
A change that reverses any arrow is an architecture violation.
For any proposed change, ask: