Mode d’emploi
- Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
- Consultez le document original pour les outils, identifiants et environnements requis.
- Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/robsonrung/rar-skills --skill architecture-lensAvant de commencer
- L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
- Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
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, return verdict (proceed | revise), blocking_findings, advisory_findings, and required_changes. 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.
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.
