← ClaudeAtlas

architecture-preflightlisted

Validate architecture boundaries, standards alignment, and ADR need before planning a feature. Use when starting a new feature or invoking /architecture-preflight.
Accelerated-Innovation/governed-ai-delivery · ★ 18 · AI & Automation · score 71
Install: claude install-skill Accelerated-Innovation/governed-ai-delivery
# Architecture Preflight You are preparing to plan and implement a feature. Determine the feature name from the user's request; if it is not provided, ask before proceeding. Before generating any code or detailed plan, produce an Architecture Preflight Report. ## 1. Summary - What is the feature or change? - What input specs are being used (NFRs: `features/<feature_name>/nfrs.md`, Gherkin: `features/<feature_name>/acceptance.feature`, Eval criteria: `features/<feature_name>/eval_criteria.yaml`)? - What affected modules or layers are in scope? ## 2. Standards Check For each of the following, state which architectural rules apply (cite file and section): - Layering (from `docs/backend/architecture/ARCH_CONTRACT.md`) - API conventions (from `docs/backend/architecture/API_CONVENTIONS.md`) - Auth/security patterns (from `docs/backend/architecture/SECURITY_AUTH_PATTERNS.md`) - Error model and response shape - Logging and observability expectations ## 2.6 Extension Discovery 1. Scan `extensions/*/manifest.yaml` in the project root. If none exist, write "No extensions present" and skip the rest of this section. 2. For each discovered manifest, parse `id`, `capabilities`, `applies_to`, `contract_sets[].paths`, and `contract_sets[].relates_to`. 3. An extension is **applicable** to this feature when any of: - the feature touches a file matching one of `applies_to` globs - the feature's described intent uses a declared `capability` 4. For each applicable extension, list it