Architectural alignment validation
Skill meyverick/agy-skills/skills/architectural-alignment-validation
A collection of elite, modular, and validated AI agent skills and system rules for Google Antigravity.
npx -y skills add meyverick/agy-skills --skill architectural-alignment-validationAssembled 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
Evaluates and validates codebase architectural structure. Use when auditing SOLID, DRY, Demeter, or DDD decoupling principles.
SKILL.md
2.4 KB, as published. Nobody here has run it
Architectural Alignment Validation
This skill enforces strict, mathematically verifiable adherence to software architecture principles (SOLID, DDD, SoC). It prevents technical debt accumulation by auditing boundary isolation.
When to Use
- Use when reviewing pull requests or major feature additions.
- Use when mapping out a codebase refactoring plan.
- NOT for debating purely stylistic formatting preferences (like tabs vs spaces).
Core Process
Phase 1: The SOLID Audit
- SRP: Scan for God Classes (files > 500 lines or > 3 distinct responsibilities).
- OCP: Ensure new features extend existing interfaces rather than modifying core logic.
- DIP: Ensure high-level business logic depends on abstractions (Interfaces), never concrete database or UI implementations.
Phase 2: Domain-Driven Design (DDD) Boundaries
- Group folders by business capability (
/billing,/user-management), NOT by technical type (/controllers,/models). - Ensure no domain module imports directly from another domain module's internal files. They must only interact through explicit exported interfaces (
index.tsfacades).
Phase 3: Demeter & Coupling Checks
- Scan for Law of Demeter violations:
user.getAccount().getPlan().getLimits(). - Force the implementation of proxy methods on the immediate dependency.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "It's a small app, we don't need DDD folder structures." | All apps grow. Organizing by technical type (/models) guarantees a tangled monolith. Enforce domain boundaries early. |
| "I'll just inject the Database instance directly into the UI controller." | Violates Dependency Inversion. The UI controller must rely on a Repository interface to allow unit testing. |
Red Flags
- Files acting as "Managers" or "Handlers" with thousands of lines of mixed logic.
- Deeply chained object property accesses across module boundaries.
Verification
Before finalizing the architectural validation:
- No module reaches deep into the internal directory of another module.
- Business logic layers are entirely devoid of SQL or HTTP specific code.
- Files adhere to strict Single Responsibility (typically < 300 lines).