engineering-intelligence 1.0.0 → 1.1.0

package/templates/canonical/agents/system-architect.md

@@ -0,0 +1,27 @@
+---
+name: system-architect
+description: Designs component boundaries, API contracts, NFR responses, and ADRs for AI-DLC construction.
+---
+
+# System Architect
+
+Owns architecture during AI-DLC Inception and Construction.
+
+## Responsibilities
+
+- Define logical components, boundaries, contracts, and dependency direction
+- Use `nfr-adr-governor` for measurable NFRs and ADR lifecycle management
+- Keep architecture aligned with `.engineering-intelligence/graph/` and existing memory
+- Identify when design-first workflow is required
+
+## Outputs
+
+- `.engineering-intelligence/aidlc/construction/<unit>/functional-design/`
+- `.engineering-intelligence/aidlc/construction/<unit>/nfr-design/`
+- ADR files under `decision-records/`
+
+## Gates
+
+- Architecture claims cite repository evidence or are marked unknown
+- High-risk alternatives are captured in ADRs
+- API and data boundaries are explicit before code generation

package/templates/canonical/agents/test-engineer.md

@@ -0,0 +1,20 @@
+---
+name: test-engineer
+description: Designs and executes unit, integration, contract, regression, performance, and negative-path tests for AI-DLC changes.
+---
+
+# Test Engineer
+
+Owns objective completion criteria and validation evidence.
+
+## Responsibilities
+
+- Convert requirements into executable assertions
+- Add regression tests for bugfixes
+- Add contract and negative-path tests for boundary changes
+- Use `environmental-backpressure-engine` to run and record checks
+
+## Outputs
+
+- Test plan in the active AI-DLC unit
+- Build and test summary with actual command results

package/templates/canonical/rules/engineering-intelligence.md

@@ -4,6 +4,38 @@
 
 When `knowledge-base/` exists, consult the relevant documents, `.engineering-intelligence/context/`, and `.engineering-intelligence/graph/` before non-trivial project edits.
 
+When `.engineering-intelligence/aidlc/` exists, also consult `aidlc-state.md`, `execution-plan.md`, `open-questions.md`, and the active construction unit before edits.
+
+## AI-DLC Operating Model
+
+Use the AI-Driven Development Lifecycle inside the existing Engineering Intelligence workflows for non-trivial work. Do not fork work into a separate lifecycle; merge AI-DLC with Agile delivery artifacts.
+
+| Phase | Purpose | Required Outputs |
+|---|---|---|
+| Discovery | Capture business intent and technical environment | `.engineering-intelligence/aidlc/discovery/vision.md`, `technical-environment.md`, `open-questions.md` |
+| Inception | Detect workspace, reverse engineer brownfield systems, validate requirements, plan workflow | `aidlc-state.md`, `execution-plan.md`, `inception/requirements.md`, Agile backlog/story/acceptance artifacts, reverse-engineering docs when brownfield |
+| Construction | Design and implement per independent unit | `construction/<unit>/`, `cross-unit-discoveries.md`, build/test summary |
+| Operations | Prepare deployment, observability, rollback, runbooks | `operations/operations-readiness.md`, MCP/security review when relevant |
+
+Select the delivery mode inside `engineering-intelligence`: standard Agile delivery, adversarial delivery, TDD delivery, design-first delivery, or hypothesis debugging.
+
+Maintain these Agile artifacts when product work is in scope:
+
+| Path | Purpose |
+|---|---|
+| `.engineering-intelligence/aidlc/agile/product-backlog.md` | Epics, stories, priorities, dependencies, status |
+| `.engineering-intelligence/aidlc/agile/sprint-plan.md` | Sprint goal, selected stories, risks, commitments |
+| `.engineering-intelligence/aidlc/agile/acceptance-criteria.md` | Story-level acceptance criteria mapped to tests |
+| `.engineering-intelligence/aidlc/agile/definition-of-ready.md` | Gate before construction starts |
+| `.engineering-intelligence/aidlc/agile/definition-of-done.md` | Gate before completion |
+| `.engineering-intelligence/aidlc/agile/retrospective.md` | Lessons and process improvements |
+
+End AI-DLC-enabled workflow responses with:
+
+```text
+AI-DLC: <phase> -> <stage> -> <status>
+```
+
 ## Engineering Change Protocol
 
 For every engineering change, follow this sequence:
@@ -11,10 +43,11 @@ For every engineering change, follow this sequence:
 | Step | Action | Output |
 |---|---|---|
 | 1 | Write impact report before editing | `.engineering-intelligence/reports/IMP-XXX-*.md` |
-| 2 | Implement code changes and tests | Modified source and test files |
-| 3 | Validate honestly — report unrun checks | Test results, lint results |
-| 4 | Incrementally update affected intelligence and graph artifacts | Updated knowledge/memory/context/graph |
-| 5 | Record completed work | `.changes/CHG-XXX-*.md` |
+| 2 | Update AI-DLC plan/state when the change is non-trivial | `.engineering-intelligence/aidlc/execution-plan.md`, `aidlc-state.md` |
+| 3 | Implement code changes and tests | Modified source and test files |
+| 4 | Validate honestly with environmental backpressure — report unrun checks | Test results, lint results, build/test summary |
+| 5 | Incrementally update affected intelligence and graph artifacts | Updated knowledge/memory/context/graph/aidlc |
+| 6 | Record completed work | `.changes/CHG-XXX-*.md` |
 
 ## Read-Only Workflows
 
@@ -37,6 +70,7 @@ Use these as the canonical project-intelligence paths — never invent alternati
 |---|---|
 | `knowledge-base/` | Evidence-based project documentation |
 | `.engineering-intelligence/memory/` | Durable decisions, rules, patterns |
+| `.engineering-intelligence/aidlc/` | AI-DLC durable lifecycle state, plans, audit, unit artifacts, operations readiness |
 | `.engineering-intelligence/context/` | Compact AI navigation maps |
 | `.engineering-intelligence/events/` | Change-event guidance |
 | `.engineering-intelligence/graph/` | Architecture graph JSON + Mermaid maps |
@@ -49,3 +83,10 @@ Use these as the canonical project-intelligence paths — never invent alternati
 - Back every material claim with a file path reference
 - Mark uncertainty explicitly — silence is worse than "unknown"
 - Use `**Not detected**` for absent features, not omission
+
+## Safety And Governance
+
+- Use measurable NFRs for latency, reliability, security, compliance, data, and compatibility targets.
+- Create ADRs only when real alternatives were considered; accepted ADRs are immutable except supersession links.
+- Require explicit human approval before destructive actions, production deployments, merges, irreversible migrations, or broad permission grants.
+- For MCP or external tool execution, prefer tool-level permissions, schema pinning, sandboxed execution, and raw-parameter approval for destructive operations.

package/templates/canonical/skills/aidlc-lifecycle-engine/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: aidlc-lifecycle-engine
+description: Runs the adaptive AI-DLC lifecycle with Discovery, Inception, Construction, Operations, durable artifacts, hatted agents, and objective completion gates.
+version: 1.0.0
+---
+
+# AI-DLC Lifecycle Engine
+
+Use this skill inside the existing Engineering Intelligence workflows. It is not a separate command family. It turns Agile intent into an adaptive, artifact-driven delivery path while preserving familiar Agile concepts: vision, backlog, user stories, acceptance criteria, sprint planning, implementation, review, release readiness, and retrospective learning.
+
+## Runtime Artifacts
+
+Use `.engineering-intelligence/aidlc/` as the canonical AI-DLC root:
+
+| Path | Purpose |
+|---|---|
+| `.engineering-intelligence/aidlc/aidlc-state.md` | Active phase, stage, workflow, hat, unit, and completion status |
+| `.engineering-intelligence/aidlc/audit.md` | Append-only chronological log of decisions, user answers, tool checks, and transitions |
+| `.engineering-intelligence/aidlc/open-questions.md` | Unresolved ambiguities and owner/status |
+| `.engineering-intelligence/aidlc/execution-plan.md` | Adaptive stage plan with mandatory/conditional/skipped stages |
+| `.engineering-intelligence/aidlc/discovery/vision.md` | Business objectives, personas, value, success metrics |
+| `.engineering-intelligence/aidlc/discovery/technical-environment.md` | Runtime, deployment, integrations, data stores, auth, constraints |
+| `.engineering-intelligence/aidlc/agile/product-backlog.md` | Epics, stories, priorities, dependencies, and status |
+| `.engineering-intelligence/aidlc/agile/sprint-plan.md` | Active sprint goal, selected stories, capacity, risks, and commitments |
+| `.engineering-intelligence/aidlc/agile/acceptance-criteria.md` | Story-level acceptance criteria expressed as executable validation targets |
+| `.engineering-intelligence/aidlc/agile/definition-of-ready.md` | Readiness checklist before construction |
+| `.engineering-intelligence/aidlc/agile/definition-of-done.md` | Completion checklist after validation and sync |
+| `.engineering-intelligence/aidlc/agile/retrospective.md` | Lessons, process improvements, recurring risks, and follow-ups |
+| `.engineering-intelligence/aidlc/inception/requirements.md` | Validated functional requirements and edge cases |
+| `.engineering-intelligence/aidlc/inception/reverse-engineering/` | Brownfield architecture, API, code structure, component inventory, technology stack |
+| `.engineering-intelligence/aidlc/construction/cross-unit-discoveries.md` | Shared discoveries from parallel or sequential units |
+| `.engineering-intelligence/aidlc/construction/<unit>/` | Unit functional design, NFR design, ADRs, code plan, build/test evidence |
+| `.engineering-intelligence/aidlc/operations/` | Deployment readiness, observability, runbooks, rollback notes |
+
+These AI-DLC files complement `knowledge-base/`, `.engineering-intelligence/memory/`, `.engineering-intelligence/context/`, `.engineering-intelligence/graph/`, `.engineering-intelligence/reports/`, and `.changes/`.
+
+## Embedded Agile + AI-DLC Model
+
+Map Agile to AI-DLC this way:
+
+| Agile Concept | AI-DLC Phase | Artifact |
+|---|---|---|
+| Product vision | Discovery | `discovery/vision.md` |
+| Product backlog | Discovery / Inception | `agile/product-backlog.md` |
+| User stories | Inception | `inception/requirements.md`, `agile/product-backlog.md` |
+| Acceptance criteria | Inception / Construction | `agile/acceptance-criteria.md`, tests |
+| Sprint planning | Inception | `agile/sprint-plan.md`, `execution-plan.md` |
+| Development | Construction | `construction/<unit>/` |
+| Daily inspection | Construction | `aidlc-state.md`, `audit.md`, `cross-unit-discoveries.md` |
+| Sprint review | Construction / Operations | validation summary, review report |
+| Release | Operations | `operations/operations-readiness.md` |
+| Retrospective | Operations | `agile/retrospective.md` |
+
+## Adaptive Phase Model
+
+### 0. Discovery
+
+Use when project intent, deployment environment, ownership, or constraints are unclear.
+
+Outputs:
+- `discovery/vision.md`
+- `discovery/technical-environment.md`
+- `open-questions.md`
+
+Ask role-aware questions. For multiple-choice questions in Markdown, put a blank line between options so strict CommonMark renderers keep options readable. Convert answers into backlog items, user stories, acceptance criteria, and open questions.
+
+### 1. Inception
+
+Always run workspace detection. Classify the repository as `greenfield` or `brownfield`.
+
+For brownfield systems, run reverse engineering and write:
+- `business-overview.md`
+- `architecture.md`
+- `code-structure.md`
+- `api-documentation.md`
+- `component-inventory.md`
+- `technology-stack.md`
+
+Then compile validated requirements, backlog updates, acceptance criteria, sprint plan, and an adaptive `execution-plan.md`.
+
+### 2. Construction
+
+Execute per unit of work. Each unit may include:
+- Functional design
+- NFR requirements
+- NFR design
+- Infrastructure design
+- Code generation plan
+- Build and test summary
+
+Before starting each unit, read `cross-unit-discoveries.md`. If new constraints appear, append finding, impact, and action taken.
+
+### 3. Operations
+
+Use when deployment, infrastructure, observability, or production readiness is in scope. Produce readiness evidence, rollback guidance, alert thresholds, and runbooks.
+
+## Delivery Mode Selection
+
+Within `/engineering-intelligence`, choose a delivery mode:
+
+| Mode | Use When | Required Hats |
+|---|---|---|
+| Standard Agile Delivery | General feature, bugfix, refactor, or update | Product Analyst, System Architect, Component Builder, Test Engineer, Documentation Writer |
+| Adversarial Delivery | Auth, payment, public API, data exposure, critical business rules | Security Officer, Adversary, Compliance Auditor, Test Engineer |
+| TDD Delivery | High-reliability business logic or service contracts | Product Analyst, Test Engineer, Component Builder |
+| Design-First Delivery | Major migrations, new architecture, data model redesign | System Architect, Database Administrator, Security Officer, Compliance Auditor |
+| Hypothesis Debugging | Production bugs, regressions, memory leaks, trace failures | Orchestration Lead, Performance Analyst, SRE, Component Builder |
+
+## Objective Completion Criteria
+
+Each stage must end with binary evidence:
+- Artifact exists at the expected path
+- Story is Ready before implementation and Done before completion
+- Unknowns are recorded or resolved
+- Required tests, type checks, linters, scans, or build commands ran, failed, or were explicitly unavailable
+- Human approval is recorded before irreversible actions
+- Breadcrumb is updated in `aidlc-state.md`
+
+## Environmental Backpressure
+
+Use compilers, strict linters, type systems, test suites, security scanners, architecture checks, and local reproducer scripts as direct feedback. When a tool fails, analyze the raw diagnostic output, revise the implementation, and rerun the relevant check until the issue is resolved or a concrete blocker is logged.
+
+## Progress Breadcrumb
+
+End AI-DLC-enabled workflow responses with one compact status line:
+
+```text
+AI-DLC: <phase> -> <stage> -> <status>
+```
+
+## Quality Gates
+
+- [ ] Discovery artifacts exist when initial intent or environment was ambiguous
+- [ ] Backlog, stories, acceptance criteria, Definition of Ready, and Definition of Done are updated for product work
+- [ ] Workspace is classified as greenfield or brownfield
+- [ ] Brownfield reverse engineering exists before broad changes
+- [ ] Requirements and execution plan are durable files
+- [ ] Construction is split into explicit units
+- [ ] Cross-unit discoveries are loaded and updated
+- [ ] Validation uses environmental backpressure
+- [ ] Operations readiness is addressed when deployment or production behavior changes

package/templates/canonical/skills/engineering-intelligence-skill/SKILL.md

@@ -34,6 +34,7 @@ Classify the incoming request before starting:
 
 Read these artifacts and identify relevant context:
 - `knowledge-base/` — architecture, APIs, runtime flow relevant to the change
+- `.engineering-intelligence/aidlc/` — active AI-DLC state, plan, audit, open questions, construction units
 - `.engineering-intelligence/memory/` — decisions, constraints, patterns that apply
 - `.engineering-intelligence/context/` — module map, critical paths, dangerous areas near the change
 - `.engineering-intelligence/graph/` — dependency and service relationships
@@ -75,6 +76,20 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 
 ### 3. Implement the Change
 
+- Select the adaptive delivery mode inside the existing Engineering Intelligence workflow:
+  - Standard Agile delivery for normal feature, bugfix, update, and refactor work
+  - Adversarial delivery for auth, payment, public API, secrets, or compliance-sensitive work
+  - TDD delivery for high-reliability business rules and service contracts
+  - Design-first delivery for migrations, new architecture, and broad system boundaries
+  - Hypothesis debugging for unknown-cause defects
+- Update Agile artifacts when product behavior is in scope:
+  - `.engineering-intelligence/aidlc/agile/product-backlog.md`
+  - `.engineering-intelligence/aidlc/agile/sprint-plan.md`
+  - `.engineering-intelligence/aidlc/agile/acceptance-criteria.md`
+  - `.engineering-intelligence/aidlc/agile/definition-of-ready.md`
+  - `.engineering-intelligence/aidlc/agile/definition-of-done.md`
+- Update `.engineering-intelligence/aidlc/execution-plan.md` and `.engineering-intelligence/aidlc/aidlc-state.md`
+- Split broad changes into construction units and keep `.engineering-intelligence/aidlc/construction/cross-unit-discoveries.md` current
 - Edit only the files necessary for the request
 - Follow existing coding patterns from `.engineering-intelligence/memory/coding-patterns.md`
 - Read conventions from `knowledge-base/16-conventions.md` and `.engineering-intelligence/memory/coding-patterns.md` — match naming patterns, import style, error handling patterns, and code structure
@@ -85,6 +100,7 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 ### 4. Add/Update Tests
 
 - Add tests proportional to the change risk level
+- Map each acceptance criterion to at least one automated test, manual verification step, or explicitly recorded unavailable check
 - For `bugfix`: add a regression test reproducing the original issue
 - For `feature`: add unit tests and integration tests for the new behavior
 - For `architecture`/`security`: add boundary and negative-path tests
@@ -93,6 +109,8 @@ Before any code edit, write `.engineering-intelligence/reports/IMP-XXX-<summary>
 ### 5. Validate
 
 - Run linters, type checks, and test suites available in the project
+- Use environmental backpressure: analyze failed diagnostics, fix, and rerun the relevant command until it passes or a blocker is recorded
+- Write `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/build-and-test-summary.md` for non-trivial units
 - **Never claim validation passed unless it actually ran and passed**
 - Record partial or failed validation honestly
 
@@ -104,6 +122,8 @@ Use `incremental-sync-engine` to update only affected artifacts:
 - Context maps if module/service topology changed
 - Graph nodes/edges if dependencies or services changed
 - Event guidance if API/schema/auth contracts changed
+- AI-DLC lifecycle artifacts if state, plan, NFRs, ADRs, operations readiness, or unit discoveries changed
+- Agile artifacts if backlog, story status, acceptance criteria, Ready/Done gates, or retrospective learning changed
 
 ### 7. Record Change
 
@@ -153,6 +173,7 @@ Summarize to the user:
 - Affected systems and services
 - Synchronized intelligence artifacts
 - Unresolved risks or follow-ups
+- Final AI-DLC breadcrumb: `AI-DLC: <phase> -> <stage> -> <status>`
 
 ## Quality Gates
 
@@ -160,6 +181,11 @@ Summarize to the user:
 - [ ] All changed behavior has corresponding test coverage
 - [ ] Validation was actually executed (not just claimed)
 - [ ] Only affected intelligence artifacts were updated
+- [ ] AI-DLC state, execution plan, and unit artifacts are current for non-trivial work
+- [ ] Story meets Definition of Ready before implementation starts
+- [ ] Story meets Definition of Done before final report
+- [ ] Acceptance criteria are mapped to validation evidence
+- [ ] Environmental backpressure was used for validation failures
 - [ ] Change record references the correct impact report
 - [ ] High-risk changes went through review gate
 - [ ] Generated code follows detected project conventions (naming, imports, structure)

package/templates/canonical/skills/environmental-backpressure-engine/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: environmental-backpressure-engine
+description: Drives compiler, linter, type-check, test, security, and architecture feedback loops until objective validation passes or blockers are recorded.
+version: 1.0.0
+---
+
+# Environmental Backpressure Engine
+
+Use this skill whenever code is generated or modified. The environment, not subjective inspection alone, supplies the feedback loop.
+
+## Procedure
+
+1. Detect available validation commands from package manifests, build files, CI config, and README instructions.
+2. Prefer narrow checks first, then broaden:
+   - formatter or static syntax check
+   - type check or compile
+   - targeted tests
+   - full test suite
+   - linter
+   - security or architecture scanner when relevant
+3. Run the smallest relevant command that can expose the current risk.
+4. Capture raw diagnostics in the active unit's `build-and-test/` artifact.
+5. Fix failures and rerun the relevant check.
+6. Stop only when checks pass, are unavailable, or a blocker is recorded with evidence.
+
+## Build And Test Summary
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/build-and-test-summary.md`:
+
+```markdown
+# Build And Test Summary: <unit>
+
+## Commands
+- `<command>`: <passed|failed|unavailable|skipped> — <why>
+
+## Failures And Corrections
+- <diagnostic summary> -> <fix applied> -> <rerun result>
+
+## Coverage / Performance
+- <available metrics or Not detected>
+
+## Residual Risk
+- <remaining risks, blockers, or manual verification>
+```
+
+## Rules
+
+- Never report validation as passed unless the command actually ran and passed.
+- Do not hide failing output. Summarize it and keep enough detail for reproduction.
+- Human review begins after local backpressure is exhausted, not before.

package/templates/canonical/skills/mcp-security-governor/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: mcp-security-governor
+description: Reviews MCP tools and external execution surfaces for scoped authorization, schema integrity, sandboxing, and human approval gates.
+version: 1.0.0
+---
+
+# MCP Security Governor
+
+Use this skill when a project configures MCP servers, external tool execution, CI/CD automation, database access, deployment tools, or any agent-callable side effect.
+
+## Security Model
+
+Check for defense in depth:
+- OAuth 2.1 or equivalent modern authorization for remote servers
+- PKCE for public clients where applicable
+- Server metadata validation before authorization
+- Tool-level permissions rather than server-level blanket permissions
+- Explicit user approval for destructive or irreversible actions
+- Tool schema hashing or pinning to detect schema drift
+- Sandboxed local execution with workspace-scoped filesystem access
+- Secrets kept out of prompts, logs, artifacts, and generated documentation
+
+## MCP Review Artifact
+
+Write `.engineering-intelligence/aidlc/operations/mcp-security-review.md`:
+
+```markdown
+# MCP Security Review
+
+## Configurations Reviewed
+- <path or Not detected>
+
+## Tool Inventory
+| Server | Tool | Capability | Permission Scope | Destructive | Approval Required |
+|---|---|---|---|---|---|
+
+## Risks
+- <risk, evidence, severity>
+
+## Required Controls
+- <control and implementation owner>
+
+## Approval Boundaries
+- <actions that must never run without human confirmation>
+```
+
+## Rules
+
+- Do not grant a tool broader filesystem, network, or deployment permission than the task requires.
+- Treat changed tool definitions as untrusted until revalidated.
+- Destructive actions must expose raw parameters to the user before execution.

package/templates/canonical/skills/nfr-adr-governor/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: nfr-adr-governor
+description: Captures non-functional requirements, maps them to architectural patterns, and governs ADR lifecycle states.
+version: 1.0.0
+---
+
+# NFR And ADR Governor
+
+Use this skill for performance, reliability, security, privacy, compliance, scalability, compatibility, migration, and operational constraints.
+
+## NFR Requirements
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/nfr-requirements.md`:
+
+```markdown
+# NFR Requirements: <unit>
+
+| Dimension | Target | Evidence / Source | Validation Method |
+|---|---|---|---|
+| Latency | <p50/p95/p99> | <source> | <test/monitor> |
+| Throughput | <target> | <source> | <load/perf test> |
+| Reliability | <SLO/SLA> | <source> | <failure test> |
+| Security | <standard/control> | <source> | <scan/review/test> |
+| Data | <volume/retention/migration> | <source> | <migration/test> |
+| Compatibility | <API/browser/runtime> | <source> | <contract test> |
+```
+
+## NFR Design
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/nfr-design/design.md` with concrete patterns. Examples: circuit breaker with exponential backoff, idempotency keys, bulkheads, rate limits, schema expansion/contraction, cache invalidation, trace correlation, policy-based authorization.
+
+## ADR Lifecycle
+
+Create an ADR only when two or more distinct alternatives were considered.
+
+Allowed states:
+- `Proposed`
+- `Accepted`
+- `Rejected`
+- `Superseded`
+
+Accepted ADRs are immutable. To change one, create a new `Proposed` ADR and mark the old accepted ADR as `Superseded by ADR-NNNN` after the new decision is accepted.
+
+ADR path:
+
+```text
+.engineering-intelligence/aidlc/construction/<unit>/nfr-design/decision-records/ADR-NNNN-<slug>.md
+```
+
+ADR template:
+
+```markdown
+# ADR-NNNN: <decision>
+
+## Status
+Proposed
+
+## Context
+<problem, constraints, NFR drivers>
+
+## Options Considered
+- Option A: <tradeoffs>
+- Option B: <tradeoffs>
+
+## Decision
+<chosen option when accepted>
+
+## Consequences
+- Positive: <benefits>
+- Negative: <costs>
+- Validation: <how this will be tested>
+
+## Supersedes / Superseded By
+<links or Not applicable>
+```
+
+## Quality Gates
+
+- [ ] NFRs are measurable where possible
+- [ ] Design patterns map back to NFR targets
+- [ ] ADR exists only when alternatives were considered
+- [ ] ADR state transitions are explicit
+- [ ] Accepted ADRs are not edited except to mark supersession

package/templates/canonical/skills/operations-readiness-engine/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: operations-readiness-engine
+description: Produces deployment, observability, rollback, and runbook readiness artifacts for production-bound AI-DLC changes.
+version: 1.0.0
+---
+
+# Operations Readiness Engine
+
+Use this skill when a change affects deployment, infrastructure, runtime behavior, SLOs, data migrations, incident response, or production monitoring.
+
+## Procedure
+
+1. Identify deployment target, environment variables, infrastructure files, CI/CD gates, and runtime services.
+2. Define release strategy: normal deploy, canary, blue/green, feature flag, or manual rollout.
+3. Define rollback plan and data recovery constraints.
+4. Define observability: metrics, traces, logs, dashboards, alerts, and ownership.
+5. Confirm production readiness with objective gates.
+
+## Outputs
+
+Write `.engineering-intelligence/aidlc/operations/operations-readiness.md`:
+
+```markdown
+# Operations Readiness
+
+## Deployment Scope
+- <services, packages, infrastructure>
+
+## Release Strategy
+- Strategy: <normal|canary|blue-green|feature-flag|manual>
+- Human approvals required: <yes/no and why>
+
+## Observability
+| Signal | Source | Threshold | Owner | Runbook |
+|---|---|---|---|---|
+
+## Rollback
+- Code rollback:
+- Data rollback:
+- Configuration rollback:
+
+## Readiness Gates
+- [ ] Build passes
+- [ ] Tests pass
+- [ ] Migrations are backward compatible or downtime is approved
+- [ ] Alerts/runbooks exist for changed failure modes
+- [ ] Secrets and environment variables are documented securely
+```
+
+## Rules
+
+- Never execute production deployment without explicit user approval.
+- Mark unknown production constraints in `open-questions.md`.
+- For database changes, require backward-compatible migration planning unless downtime is approved.

package/templates/canonical/skills/requirement-scoper/SKILL.md

@@ -24,13 +24,14 @@ Act as a detailed Business Analyst and Technical Architect persona. Analyze the
 
 2. **Formulate Scoping Questions** — Identify gaps, ambiguities, and edge cases. Ask the user 3 to 5 targeted questions covering:
    - **Business Value & Scope**: What are the limits of the MVP?
+   - **Agile Story Shape**: What user role, user goal, priority, dependencies, and release expectation apply?
    - **Technical Strategy**: Which specific database, caching, or third-party integrations are expected?
    - **Edge Cases**: How should errors, rate limits, or validation failures be handled?
    - **UI/UX (if applicable)**: What configuration or user feedback is expected?
 
 3. **Iterate with User** — Wait for user responses. Adjust assumptions based on their answers.
 
-4. **Generate Final Requirement Prompt** — Once requirements are clear, output a comprehensive requirements document to `knowledge-base/19-requirements.md` and formulate the finalized prompt for the development agent.
+4. **Generate Final Requirement Prompt** — Once requirements are clear, output a comprehensive requirements document to `knowledge-base/19-requirements.md`, update Agile artifacts under `.engineering-intelligence/aidlc/agile/`, and formulate the finalized prompt for the development agent.
 
 ## Output Format
 
@@ -47,10 +48,21 @@ The final requirements document `knowledge-base/19-requirements.md` must follow
 - **System Boundaries & Dependencies**: <Files/modules affected based on graph mappings>
 - **Edge Cases & Failure Modes**: <Exactly how to handle failures, retries, limits>
 
-## 3. Iterated QA Log
+## 3. Agile Delivery Model
+- **Epic**: <epic or initiative>
+- **User Story**: As a <persona>, I want <capability>, so that <outcome>.
+- **Priority**: <P0/P1/P2 or project convention>
+- **Acceptance Criteria**:
+  - Given <context>, when <action>, then <observable result>.
+- **Definition of Ready**:
+  - <ready gate status>
+- **Definition of Done**:
+  - <done gate expectations>
+
+## 4. Iterated QA Log
 <Questions asked and answers received during scoping>
 
-## 4. Finalized Implementation Prompt
+## 5. Finalized Implementation Prompt
 Provide the exact prompt to pass to the coding agent to execute this change:
 ```text
 /engineering-intelligence <Fully detailed requirements and file scope here>
@@ -62,10 +74,12 @@ Provide the exact prompt to pass to the coding agent to execute this change:
 - **Do not modify product code** — this skill is strictly for scoping and analysis.
 - Do not make assumptions on ambiguities; always ask clarifying questions.
 - Base questions and plans on project graph mappings and existing memory files.
+- Keep Agile artifacts synchronized with the final requirement prompt.
 
 ## Quality Gates
 
 - [ ] Clear business goals and technical boundaries defined.
 - [ ] At least 3 scoping questions asked and logged.
+- [ ] User story, acceptance criteria, priority, dependencies, and Ready/Done gates are documented.
 - [ ] Finalized prompt maps exact files and modules.
 - [ ] Output does not contain any code modification.