← ClaudeAtlas

architecture-fitness-functionslisted

Architecture fitness functions turn intended boundaries into dependency rules, cycle checks, ownership gates, ADR conformance, runtime/resilience checks, and staged CI enforcement.
Xopoko/plug-n-skills · ★ 11 · AI & Automation · score 77
Install: claude install-skill Xopoko/plug-n-skills
# Architecture Fitness Functions Bundled commands use `$PLUGIN_ROOT` (`$env:PLUGIN_ROOT` in PowerShell; same path suffix) for the plugin root. Set it once: use the host's plugin-root variable when defined (Claude Code: `PLUGIN_ROOT="$CLAUDE_PLUGIN_ROOT"`), otherwise the absolute path of this plugin's root directory. Use when architecture quality should become observable, testable, or CI-enforced. ## Rule Shape Each rule needs: intent, scope, owner, signal, mechanism, pass condition, cadence, failure action, exception path, related ADR/principle, protected quality attribute, and tradeoff. Cadence: `local`, `pre-commit`, `ci`, `release`, `scheduled`, `production`. Rollout: `measure -> warn -> enforce` for legacy systems. ## Common Guardrails - Dependency direction: domain, UI, adapters, shared packages, and apps import only allowed layers. - Cycle prevention: package, namespace, module, service, or workspace cycles. - Boundary API: imports only through public entry points. - Data ownership: one bounded context owns writes for a table/topic/entity family. - Runtime coupling: sync calls, queues, cache, external APIs follow approved directions. - Observability/resilience: critical flows expose logs/metrics/traces/health checks and timeout/retry/fallback/idempotency policies. - Deployment safety: migration order, feature flags, rollback readiness, compatibility windows. - Documentation drift: architecture-changing code links ADRs, diagrams, ownership docs. - Ownership topol