engineering-intelligence 1.5.0 → 1.7.0

package/templates/canonical/agents/product-analyst.md

@@ -13,6 +13,7 @@ You are the Product Analyst agent. Your responsibility is to bridge the gap betw
 - Maintain requirements documentation without writing product code.
 - Lead AI-DLC discovery inside initialization and requirement scoping when business intent, deployment context, personas, success metrics, or constraints are unclear.
 - Maintain Agile backlog, user story, acceptance criteria, Definition of Ready, and sprint planning artifacts.
+- Autonomously decompose large initiatives into a durable Epic → Feature → Ticket backlog using `backlog-decomposition-engine`, setting a `pending` approval gate on every feature.
 
 ## Scoping Protocol
 1. **Analyze Initial Input**: Receive the developer's raw requirement or bug description.
@@ -21,6 +22,7 @@ You are the Product Analyst agent. Your responsibility is to bridge the gap betw
 4. **Publish Requirements**: Write the scoping result and final implementation prompt to `knowledge-base/19-requirements.md`.
 5. **Publish AI-DLC Discovery**: During initialization or scoping, write `.engineering-intelligence/aidlc/discovery/vision.md`, `.engineering-intelligence/aidlc/discovery/technical-environment.md`, and `.engineering-intelligence/aidlc/open-questions.md`.
 6. **Publish Agile Scope**: Update `.engineering-intelligence/aidlc/agile/product-backlog.md`, `acceptance-criteria.md`, `definition-of-ready.md`, and `sprint-plan.md`.
+7. **Decompose When Large**: For epic-sized initiatives, run `backlog-decomposition-engine` to write the Epic → Feature → Ticket hierarchy under `.engineering-intelligence/aidlc/agile/backlog/`, then stop at the per-feature approval gate without implementing.
 
 ## Collaboration Rules
 - **No Code Modification**: Never attempt to write or edit source code files.

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

@@ -25,7 +25,8 @@ 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/product-backlog.md` | High-level epics, priorities, dependencies, status |
+| `.engineering-intelligence/aidlc/agile/backlog/` | Hierarchical Epic → Feature → Ticket backlog with stable IDs, dependency graph, and per-feature approval gates |
 | `.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 |
@@ -38,6 +39,18 @@ End AI-DLC-enabled workflow responses with:
 AI-DLC: <phase> -> <stage> -> <status>
 ```
 
+## Backlog Decomposition And Delivery
+
+For epic-sized initiatives, decompose before implementing:
+
+| Step | Workflow | Action |
+|---|---|---|
+| 1 | `decompose-backlog` | Autonomously create the Epic → Feature → Ticket hierarchy under `.engineering-intelligence/aidlc/agile/backlog/` with stable IDs, dependency graph, and execution order. Plans only; does not modify product code. |
+| 2 | (human) | Approve each feature. Implementation of a feature must not begin until `Approval: approved` is recorded in its feature file and `aidlc/audit.md`. |
+| 3 | `deliver-backlog` | Implement an approved feature's tickets one at a time via `engineering-intelligence`, rolling up ticket → feature → epic status. Re-enter the approval gate for every feature. |
+
+Optionally mirror the backlog to GitHub Issues with `issue-tracker-sync-engine`; the local markdown backlog remains the source of truth.
+
 ## Engineering Change Protocol
 
 For every engineering change, follow this sequence:
@@ -61,8 +74,9 @@ These workflows analyze and report but do **not** modify product code:
 | `analyze-impact` | Write impact report for a proposal or diff | `.engineering-intelligence/reports/IMP-XXX-*.md` |
 | `sync-engineering-intelligence` | Synchronize intelligence for a change | Updated knowledge/memory/context/graph |
 | `review-engineering-change` | Write review findings | `.engineering-intelligence/reports/REV-XXX-*.md` |
+| `decompose-backlog` | Create the Epic → Feature → Ticket backlog | `.engineering-intelligence/aidlc/agile/backlog/` |
 
-Only the `engineering-intelligence` implementation workflow is intended to modify product code.
+The `engineering-intelligence` and `deliver-backlog` workflows are the only workflows intended to modify product code; `deliver-backlog` does so one approved feature at a time.
 
 ## Canonical Paths
 

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

@@ -21,7 +21,8 @@ Use `.engineering-intelligence/aidlc/` as the canonical AI-DLC root:
 | `.engineering-intelligence/aidlc/checkpoints.md` | Resume checkpoints after major workflow steps |
 | `.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/product-backlog.md` | High-level epics, priorities, dependencies, and status |
+| `.engineering-intelligence/aidlc/agile/backlog/` | Hierarchical Epic → Feature → Ticket backlog with stable IDs, dependency graph, and per-feature approval gates, owned by `backlog-decomposition-engine` |
 | `.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 |
@@ -42,8 +43,9 @@ 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` |
+| Product backlog | Discovery / Inception | `agile/product-backlog.md`, `agile/backlog/` |
+| Epic → Feature → Ticket breakdown | Inception | `agile/backlog/` via `backlog-decomposition-engine` |
+| User stories | Inception | `inception/requirements.md`, `agile/backlog/features/` |
 | Acceptance criteria | Inception / Construction | `agile/acceptance-criteria.md`, tests |
 | Sprint planning | Inception | `agile/sprint-plan.md`, `execution-plan.md` |
 | Development | Construction | `construction/<unit>/` |

package/templates/canonical/skills/backlog-decomposition-engine/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: backlog-decomposition-engine
+description: Autonomously decomposes a high-level initiative into a durable Epic to Feature to Ticket backlog with stable IDs, acceptance criteria, dependencies, execution order, and a per-feature human approval gate. Use to plan large product work before implementation.
+version: 1.0.0
+---
+
+# Backlog Decomposition Engine
+
+Turn a single high-level initiative, product brief, or large request into a complete, durable, hierarchical backlog. This skill plans and structures work; it does **not** modify product code. Implementation happens later through `deliver-backlog` and `engineering-intelligence-skill`.
+
+The hierarchy is three levels:
+
+```text
+Epic  (a business outcome / initiative)
+ └─ Feature  (a shippable slice of the epic; the approval unit)
+     └─ Ticket  (an implementable unit of work; maps to one /engineering-intelligence run)
+```
+
+## Inputs
+
+- The user's high-level initiative or request
+- `knowledge-base/` (domain context)
+- `.engineering-intelligence/graph/` (dependency, service, runtime, business-flow graphs)
+- `.engineering-intelligence/memory/` (durable architecture and business decisions)
+- `.engineering-intelligence/aidlc/discovery/vision.md` and `agile/product-backlog.md` when present
+
+## Runtime Artifacts
+
+Write the backlog under `.engineering-intelligence/aidlc/agile/backlog/`:
+
+| Path | Purpose |
+|---|---|
+| `.engineering-intelligence/aidlc/agile/backlog/backlog-index.md` | Master index, ID counters, and status rollup for every epic, feature, and ticket |
+| `.engineering-intelligence/aidlc/agile/backlog/epics/EPIC-XXX-<slug>.md` | One epic: outcome, success metrics, child features |
+| `.engineering-intelligence/aidlc/agile/backlog/features/FEAT-XXX-<slug>.md` | One feature: user story, acceptance criteria, child tickets, approval state |
+| `.engineering-intelligence/aidlc/agile/backlog/tickets/TKT-XXX-<slug>.md` | One ticket: executable acceptance criteria, affected files, Ready/Done gates, implementation command |
+| `.engineering-intelligence/aidlc/agile/backlog/dependency-graph.md` | Feature and ticket dependency graph plus the derived execution order |
+| `.engineering-intelligence/aidlc/agile/backlog/sync/tracker-sync-map.md` | Local ID to external tracker (e.g. GitHub issue) mapping, written only by `issue-tracker-sync-engine` |
+
+This backlog is the structured expansion of `agile/product-backlog.md`; keep the high-level epic list in `product-backlog.md` consistent with `backlog-index.md`.
+
+## Identifier Rules
+
+- IDs are stable and zero-padded: `EPIC-001`, `FEAT-001`, `TKT-001`.
+- Never renumber an existing ID. Allocate the next number from the counters in `backlog-index.md`.
+- Slugs are lowercase, hyphenated, and derived from the title.
+- Every feature names its parent epic; every ticket names its parent feature.
+
+## Procedure
+
+1. **Load Intelligence** — Read the inputs above. If project intelligence has not been initialized, run discovery/initialization first or record the gap in `open-questions.md`.
+
+2. **Frame Epics** — Group the initiative into one or more epics by business outcome. Each epic gets an objective, success metrics, priority, and a verifiable definition of success.
+
+3. **Slice Features** — Decompose each epic into the smallest set of independently shippable features. Each feature is the **approval unit**: it carries a user story, acceptance criteria, priority, dependencies, and an `Approval` state that starts at `pending`.
+
+4. **Cut Tickets** — Decompose each feature into implementable tickets sized for a single `/engineering-intelligence` run (roughly half a day to two days of work). Use graph intelligence to predict affected files and to keep tickets cohesive. Each ticket carries executable acceptance criteria, a type, an estimate, a risk level, Definition of Ready, Definition of Done, and a ready-to-run implementation command.
+
+5. **Map Dependencies** — Build `dependency-graph.md`. Record feature-to-feature and ticket-to-ticket dependencies, mark which can run in parallel (no dependency edge and no overlapping owned files), and emit a topologically ordered execution sequence. Flag conflict risk where owned files overlap.
+
+6. **Assign Initial Status** — Tickets start `todo`; a ticket becomes `ready` only when its Definition of Ready is satisfied and its dependencies are `done`. Features start `proposed` with `Approval: pending`. Epics start `proposed`.
+
+7. **Write Artifacts** — Create every epic, feature, and ticket file plus `backlog-index.md` and `dependency-graph.md`. Update `agile/product-backlog.md`, `agile/acceptance-criteria.md`, and `execution-plan.md` to reference the new IDs. Append the decomposition decisions to `aidlc/audit.md`.
+
+8. **Optional Tracker Sync** — If the user asked to sync, or a GitHub remote is detected and sync is enabled, invoke `issue-tracker-sync-engine` to mirror epics/features/tickets to the external tracker and record the mapping in `sync/tracker-sync-map.md`.
+
+9. **Stop At The Gate** — Decomposition ends with a plan only. Do not implement. Hand off to `deliver-backlog`, which enforces the per-feature approval gate.
+
+## Artifact Templates
+
+### `backlog-index.md`
+
+```markdown
+# Backlog Index
+
+## Counters
+- next-epic: 3
+- next-feature: 7
+- next-ticket: 21
+
+## Status Rollup
+| ID | Type | Title | Parent | Status | Approval | Priority |
+|---|---|---|---|---|---|---|
+| EPIC-001 | epic | <title> | — | in-progress | — | P0 |
+| FEAT-001 | feature | <title> | EPIC-001 | proposed | pending | P0 |
+| TKT-001 | ticket | <title> | FEAT-001 | ready | — | P0 |
+```
+
+### `epics/EPIC-XXX-<slug>.md`
+
+```markdown
+# EPIC-001: <title>
+
+- Status: proposed | approved | in-progress | done
+- Priority: P0 | P1 | P2
+- Owner: <persona or team>
+
+## Business Outcome
+<the measurable outcome this epic delivers>
+
+## Success Metrics
+- <metric and target>
+
+## Features
+- FEAT-001 — <title>
+- FEAT-002 — <title>
+
+## Definition of Success
+- [ ] <binary, evidence-backed completion condition>
+```
+
+### `features/FEAT-XXX-<slug>.md`
+
+```markdown
+# FEAT-001: <title>
+
+- Epic: EPIC-001
+- Status: proposed | approved | in-progress | in-review | done | blocked
+- Approval: pending | approved | changes-requested
+- Priority: P0 | P1 | P2
+- Depends On: FEAT-XXX (or none)
+
+## User Story
+As a <persona>, I want <capability>, so that <outcome>.
+
+## Acceptance Criteria
+- Given <context>, when <action>, then <observable result>.
+
+## Tickets
+- TKT-001 — <title>
+- TKT-002 — <title>
+
+## Approval Gate
+Implementation of this feature's tickets must not begin until a human records
+`Approval: approved` here and in `aidlc/audit.md`.
+```
+
+### `tickets/TKT-XXX-<slug>.md`
+
+```markdown
+# TKT-001: <title>
+
+- Feature: FEAT-001
+- Status: todo | ready | in-progress | in-review | done | blocked
+- Type: feature | bugfix | chore | spike | migration
+- Estimate: S | M | L
+- Risk: low | medium | high
+- Depends On: TKT-XXX (or none)
+- Files Likely Affected: <paths from graph intelligence>
+
+## Acceptance Criteria
+- Given <context>, when <action>, then <observable result>.
+
+## Definition of Ready
+- [ ] Dependencies are done
+- [ ] Acceptance criteria are testable
+- [ ] Affected files identified from graph intelligence
+
+## Definition of Done
+- [ ] Code implemented and tests added proportional to risk
+- [ ] Safety gates run or explicitly not applicable
+- [ ] Intelligence synchronized and change record written
+
+## Implementation Command
+```text
+/engineering-intelligence Implement TKT-001: <fully scoped request with file paths and constraints>
+```
+```
+
+## Rules
+
+- Do **not** modify product code; this skill only writes backlog and planning artifacts.
+- Never renumber existing IDs; only append new ones using the counters.
+- Every ticket must be independently implementable and map to exactly one implementation command.
+- Features are the approval unit; tickets inherit their feature's approval state.
+- Cite graph and knowledge evidence for affected-file predictions; record unknowns instead of guessing.
+- Keep `backlog-index.md`, `product-backlog.md`, and child files consistent on every write.
+
+## Quality Gates
+
+- [ ] At least one epic, one feature, and one ticket exist with stable zero-padded IDs
+- [ ] Every feature has a user story, acceptance criteria, and `Approval: pending`
+- [ ] Every ticket has executable acceptance criteria and a runnable implementation command
+- [ ] `dependency-graph.md` exists with a topological execution order and parallel-safe markings
+- [ ] `backlog-index.md` counters and status rollup match the child files
+- [ ] No product code was modified
+- [ ] Decomposition decisions appended to `aidlc/audit.md`

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

@@ -28,6 +28,20 @@ Classify the incoming request before starting:
 | `security` | Auth, permissions, vulnerability fixes | High |
 | `documentation` | Knowledge-only changes (no product code) | Low |
 
+## Depth Level
+
+Determine execution depth from the user's request before proceeding:
+
+| Signal words | Depth | Effect |
+|---|---|---|
+| "minimal", "quick", "sketch", "spike", "prototype" | **Minimal** | Skip optional gates; lightweight impact report; no full sync; use existing intelligence as-is |
+| (default — no explicit signal) | **Standard** | Full procedure; all applicable gates; incremental sync after changes |
+| "comprehensive", "thorough", "production-critical", "audit" | **Comprehensive** | All gates mandatory; extended scope analysis; full intelligence sync; cross-reference all ADRs |
+
+Record the depth on line 2 of the impact report header. For **Minimal** depth, list which gates were skipped and why.
+
+**Context gate (Standard and Comprehensive):** On high-risk or architecture-level changes, commit all intelligence artifacts and the current execution plan to git before starting implementation. This creates a clean recovery point if the context window fills mid-implementation.
+
 ## Procedure
 
 ### 1. Pre-Flight: Read Intelligence
@@ -274,6 +288,13 @@ Summarize to the user:
 - [ ] High-risk changes went through review gate
 - [ ] Generated code follows detected project conventions (naming, imports, structure)
 
+## Rules
+
+- **Never vibe-code** — Do not edit files directly without first recording the change in the impact report. If an urgent direct edit is unavoidable, log the file and reason in the impact report's "direct edits" section and update design artifacts before marking the work done.
+- Always write the impact report before any code edit.
+- Never claim validation passed unless it actually ran and passed.
+- Record partial or failed validation honestly.
+
 ## Cross-References
 
 - Depends on: `initialize-intelligence-skill` (prerequisite), `context-budget-optimizer`, `change-detection-engine`, `impact-analysis-engine`, `graph-engine`, `staleness-detector`

package/templates/canonical/skills/issue-tracker-sync-engine/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: issue-tracker-sync-engine
+description: Mirrors the local Epic to Feature to Ticket backlog to an external issue tracker such as GitHub Issues, keeping the local markdown backlog as the source of truth and recording a stable ID mapping. Use to publish or refresh tracker issues from the backlog.
+version: 1.0.0
+---
+
+# Issue Tracker Sync Engine
+
+Synchronize the local backlog under `.engineering-intelligence/aidlc/agile/backlog/` to an external issue tracker. The **local markdown backlog is always the source of truth**; the tracker is a mirror. This skill does not modify product code.
+
+## When To Run
+
+- The user asks to publish, sync, or push the backlog to GitHub Issues (or another tracker).
+- A new feature or ticket was created or its status changed and the backlog is configured to sync.
+- Sync is optional: skip silently when no tracker is configured or detected.
+
+## Tracker Detection
+
+1. Prefer an explicit tracker named by the user or recorded in `sync/tracker-sync-map.md`.
+2. Otherwise detect a GitHub remote (e.g. `git remote -v` shows a `github.com` origin) and treat GitHub Issues as the target.
+3. If no tracker is available, record `tracker: none` in `sync/tracker-sync-map.md` and stop without error.
+
+## Mapping Model
+
+Map the local hierarchy onto tracker primitives:
+
+| Local | GitHub Issues | Generic Tracker |
+|---|---|---|
+| Epic | Issue labeled `epic` (parent / tracking issue) | Epic / initiative |
+| Feature | Issue labeled `feature`, linked to epic (sub-issue when supported) | Story / feature |
+| Ticket | Issue labeled `ticket`/`task`, linked to feature | Task / sub-task |
+
+Record every link in `sync/tracker-sync-map.md`:
+
+```markdown
+# Tracker Sync Map
+
+- tracker: github
+- repo: <owner/name>
+- last-synced: <ISO timestamp>
+
+| Local ID | Tracker ID | URL | Last Status | Direction |
+|---|---|---|---|---|
+| EPIC-001 | #42 | <url> | open | local->tracker |
+| FEAT-001 | #43 | <url> | open | local->tracker |
+| TKT-001 | #44 | <url> | open | local->tracker |
+```
+
+## Procedure
+
+1. **Resolve Tracker** — Detect or read the configured tracker. Stop cleanly if none.
+2. **Diff** — Compare `backlog-index.md` against `sync/tracker-sync-map.md`. Classify each node as new, changed, unchanged, or closed-locally.
+3. **Create** — For new nodes, create issues bottom-consistent: epic first, then its features, then their tickets, linking children to parents. Apply `epic`/`feature`/`ticket` labels and copy the title plus a body summarizing the local artifact with a link back to its local path.
+4. **Update** — For changed nodes, update the tracker issue title, body, labels, and open/closed state to match local status (`done` local status closes the tracker issue).
+5. **Record Mapping** — Write the local-to-tracker ID, URL, and direction into `sync/tracker-sync-map.md`. Never overwrite the local backlog from the tracker unless the user explicitly requests a pull.
+6. **Audit** — Append a sync summary (counts created/updated/closed, tracker, timestamp) to `aidlc/audit.md`.
+
+## Host Tooling
+
+- In hosts with native GitHub tools (e.g. an MCP GitHub server), use them to create, update, link, and close issues.
+- In hosts without tracker tooling, emit a ready-to-run command list (e.g. `gh issue create ...`) into `sync/tracker-sync-map.md` for the user to execute, and mark direction as `pending`.
+
+## Rules
+
+- The local backlog is authoritative; never silently mutate local files from tracker state.
+- Sync is idempotent: re-running with no local changes must create no duplicate issues.
+- Preserve stable local IDs in issue titles or bodies so mapping survives renames.
+- Treat tracker write failures as logged blockers, not silent successes.
+
+## Quality Gates
+
+- [ ] Tracker resolved or `tracker: none` recorded without error
+- [ ] Every synced node has a row in `sync/tracker-sync-map.md`
+- [ ] Re-running with no changes creates no duplicates (idempotent)
+- [ ] Local `done` status closes the corresponding tracker issue
+- [ ] Sync summary appended to `aidlc/audit.md`
+- [ ] No product code modified

package/templates/canonical/skills/question-file-engine/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: question-file-engine
+description: Writes structured MCQ clarification files to .engineering-intelligence/aidlc/open-questions/ instead of asking questions inline. Creates durable decision artifacts and enables context reset between question creation and answer processing. Use when a request has 3+ ambiguities or scope is unclear.
+version: 1.0.0
+---
+
+# Question File Engine
+
+Write structured clarification question files rather than asking questions inline in chat. This pattern creates durable decision artifacts, lets users answer thoughtfully with full context visible, and enables a context reset between question creation and answer processing — so each phase starts with a fresh focused context.
+
+## When to Use
+
+- Request has clarity: Vague, Incomplete, or Contradictory
+- 3 or more clarifications are needed before proceeding
+- Questions involve trade-offs the user must decide (not resolvable from codebase alone)
+- Starting a long workflow where misaligned assumptions cost significant rework
+
+## Inputs
+
+- Original request or initiative description
+- Ambiguity analysis from calling skill (requirement-scoper, backlog-decomposition-engine)
+- Optional: project architecture from `knowledge-base/`, `$EI graph/`
+
+## Procedure
+
+### 1. Identify Ambiguities
+
+Group unknowns into categories before writing:
+
+| Category | Examples |
+|---|---|
+| Scope | In/out of MVP, affected modules, integration boundaries |
+| Strategy | Which implementation approach, library, or architecture pattern |
+| Risk | Tolerance for breaking changes, migration complexity |
+| Priority | Ship now vs. defer, dependency ordering |
+
+Cap at 8 questions per file. Write a second file for additional batches.
+
+### 2. Write the Question File
+
+Save to `$AIDLC open-questions/YYYYMMDD-{slug}.md`:
+
+```markdown
+# Clarification Questions: {topic}
+
+**Instructions:** Check boxes to select answers. Multiple selections are fine. Write a custom answer after "Custom:" when no option fits.
+Return to chat and say **"questions answered, continue"** when done.
+
+---
+
+## Q1: {Question?}
+
+**Context:** {1–2 sentences explaining why this matters for the implementation.}
+
+- [ ] A) {Option A}
+- [ ] B) {Option B}
+- [ ] C) {Option C}
+- [ ] D) Custom: _______________
+
+---
+
+## Q2: {Question?}
+
+**Context:** {why this matters}
+
+- [ ] A) {Option A}
+- [ ] B) {Option B}
+- [ ] C) Custom: _______________
+
+---
+
+_Created: {ISO date} | Topic: {original request summary}_
+```
+
+Guidelines for good questions:
+- Every question must have a concrete impact on the implementation plan
+- Include 2–4 options with brief descriptions; always include a "Custom" option
+- Order questions: scope first, then strategy, then risk
+- State the default assumption in option A if the user skips the question
+
+### 3. Stop and Signal
+
+After writing the file, output exactly this and nothing else:
+
+> Questions written to `$AIDLC open-questions/{filename}`.
+>
+> **Next step:** Open the file, check boxes to select your answers (you may select multiple), then return here and say **"questions answered, continue"**.
+
+**Stop. Do not proceed. Do not guess answers. Wait for explicit user signal.**
+
+### 4. Resume Protocol
+
+When user signals answers are ready:
+
+1. **Re-read the question file from disk.** Never rely on in-context memory of the questions — always use the Read tool to load the current file content.
+2. Validate every question has at least one checked box or a "Custom:" response.
+3. If any critical question is unanswered, ask inline (one concise message, not another file).
+4. Extract confirmed decisions and carry them forward. Reference the question file path in all generated artifacts and the QA log.
+
+## Output
+
+- `$AIDLC open-questions/YYYYMMDD-{slug}.md` — question file (before resume)
+- On resume: confirmed decision set, referenced by path in the calling skill's output
+
+## Rules
+
+- Never ask 3+ questions inline — always write a question file.
+- Never guess or assume answers to unresolved questions.
+- Always re-read the file from disk on resume; never trust in-memory question content.
+- Log confirmed decisions in `knowledge-base/19-requirements.md` section `## 4. Iterated QA Log`.

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

@@ -29,9 +29,19 @@ Act as a detailed Business Analyst and Technical Architect persona. Analyze the
      - framework patterns used in 80% or more of similar code
    - Surface confirmed dominant patterns as constraints in the requirements document.
 
-2. **Formulate Scoping Questions** — Identify gaps, ambiguities, and edge cases. Ask the user 3 to 5 targeted questions covering:
+2. **Formulate Scoping Questions** — Determine clarity level from the analysis:
+
+   | Clarity | Undefined ambiguities | Action |
+   |---|---|---|
+   | Clear | 0–2 minor gaps | Ask inline; proceed after user responds |
+   | Vague | 3–5 gaps or unclear scope | Use `question-file-engine` to write a structured question file; **stop and wait** |
+   | Incomplete | Missing critical info | Use `question-file-engine`; do not proceed until all critical questions are answered |
+
+   When using `question-file-engine`, invoke it now and stop. Do not continue this procedure until the user signals answers are ready.
+
+   When asking inline (Clear clarity), keep to 3–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?
+   - **Agile Story Shape**: Which user role, 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?

package/templates/canonical/workflows/decompose-backlog.md

@@ -0,0 +1,37 @@
+---
+description: Autonomously decompose a high-level initiative into a durable Epic to Feature to Ticket backlog with dependencies, execution order, and a per-feature approval gate, without modifying product code.
+---
+
+# Decompose Backlog
+
+Use the `backlog-decomposition-engine` capability to turn a high-level initiative into a complete, durable backlog. Optionally use `issue-tracker-sync-engine` to mirror the result to an external tracker.
+
+## Input
+
+Analyze the user-supplied initiative: a product brief, epic-sized request, or large feature description. If the intent, personas, or success criteria are ambiguous, ask focused questions or run discovery before decomposing — never assume.
+
+## Pipeline
+
+1. **Clarify Scope** — If the initiative description is vague or missing key decisions (target users, excluded scope, phasing, integration boundaries), use `question-file-engine` to write a structured clarification file at `.engineering-intelligence/aidlc/open-questions/`. Stop and wait for the user to fill answers and signal "questions answered, continue" before decomposing.
+2. **Read Intelligence** — Consult `knowledge-base/`, `.engineering-intelligence/graph/`, `.engineering-intelligence/memory/`, and existing `.engineering-intelligence/aidlc/` artifacts.
+3. **Decompose** — Run `backlog-decomposition-engine` to frame epics, slice features, and cut tickets with stable IDs (`EPIC-XXX`, `FEAT-XXX`, `TKT-XXX`).
+4. **Write Backlog** — Create artifacts under `.engineering-intelligence/aidlc/agile/backlog/`: `backlog-index.md`, `epics/`, `features/`, `tickets/`, and `dependency-graph.md`. Keep `agile/product-backlog.md` and `execution-plan.md` consistent.
+5. **Map Dependencies** — Emit a topological execution order and mark parallel-safe work in `dependency-graph.md`.
+6. **Set Approval Gates** — Every feature is created with `Approval: pending`. No implementation occurs in this workflow.
+7. **Optional Sync** — If the user requested it, or a GitHub remote is detected and sync is enabled, run `issue-tracker-sync-engine` and record `sync/tracker-sync-map.md`.
+
+## Completion Report
+
+Finish with:
+- The created epics, features, and tickets with their IDs and statuses
+- The execution order and any parallel-safe features
+- The features awaiting approval (`Approval: pending`)
+- The exact next command: `/deliver-backlog` to begin gated delivery, or `/deliver-backlog FEAT-XXX` for a specific feature
+
+## Rules
+
+- Ask for clarification when the initiative is ambiguous — never assume scope.
+- Produce independently implementable tickets, each mapping to one `/engineering-intelligence` command.
+- Keep `backlog-index.md` counters and the child files consistent.
+
+**Contract**: This workflow plans and writes backlog artifacts only. It must not modify product code.

package/templates/canonical/workflows/deliver-backlog.md

@@ -0,0 +1,50 @@
+---
+description: Drive delivery of a decomposed backlog feature by feature, enforcing a human approval gate before implementing each feature, then implementing its tickets through the engineering intelligence pipeline.
+---
+
+# Deliver Backlog
+
+Execute a backlog produced by `decompose-backlog`. This workflow **does** modify product code, one approved feature at a time. It uses `aidlc-lifecycle-engine` for durable state and `engineering-intelligence-skill` to implement each ticket.
+
+## Input
+
+Optional scope: a feature ID (`FEAT-XXX`) or epic ID (`EPIC-XXX`) to deliver. With no scope, select the next ready feature from the execution order in `.engineering-intelligence/aidlc/agile/backlog/dependency-graph.md`.
+
+## Pipeline
+
+1. **Load Backlog** — Read `backlog-index.md`, `dependency-graph.md`, and the relevant feature and ticket files. Resume from `aidlc-state.md`/`checkpoints.md` if a feature was already in progress.
+2. **Select Feature** — Pick the highest-priority feature whose dependencies are `done`, honoring any user-supplied scope.
+3. **Approval Gate (mandatory)** — If the feature's `Approval` is not `approved`:
+   - Present the feature: user story, acceptance criteria, child tickets, affected files, risk, and execution order.
+   - Ask the human to approve, request changes, or skip.
+   - Record the decision in the feature file (`Approval: approved | changes-requested`) and append it to `aidlc/audit.md`.
+   - Do **not** implement until `Approval: approved` is recorded. On `changes-requested`, return to `decompose-backlog` for that feature.
+4. **Implement Tickets** — For each ticket in dependency order, when its Definition of Ready holds:
+   - Mark the ticket `in-progress`.
+   - Run the ticket's implementation command through `engineering-intelligence-skill` (impact report, delivery-mode selection, implementation, tests, safety gates, validation, sync, change record).
+   - Mark the ticket `in-review`, then `done` once its Definition of Done is satisfied with evidence.
+5. **Roll Up Status** — Update `backlog-index.md`, the feature status, and the epic status as tickets complete. A feature is `done` when all its tickets are `done`; an epic is `done` when all its features are `done`.
+6. **Optional Sync** — If tracker sync is enabled, run `issue-tracker-sync-engine` so the external tracker reflects new statuses (closing issues for `done` work).
+7. **Continue Or Stop** — After a feature completes, stop and report, or proceed to the next ready feature only if the user requested continuous delivery. Each new feature re-enters the approval gate.
+
+## Stop Conditions
+
+- A feature awaiting approval halts delivery until a human approves.
+- Irreversible actions (database migrations, destructive changes, deletions) require explicit approval even within an approved feature.
+- A hard blocker (failing safety gate that cannot be resolved, missing dependency) is logged in `open-questions.md` and halts the affected feature.
+
+## Completion Report
+
+Finish with:
+- Features and tickets delivered this run with their final statuses
+- Validation evidence per ticket (tests, type checks, scans run/failed/unavailable)
+- Updated rollup in `backlog-index.md`
+- The next ready feature awaiting approval, if any
+- `AI-DLC: <phase> -> <stage> -> <status>` breadcrumb
+
+## Rules
+
+- Never implement a feature whose `Approval` is not `approved`.
+- One feature at a time; re-enter the approval gate for every feature.
+- Validate honestly through environmental backpressure; never claim success without execution.
+- Keep backlog status, AI-DLC state, and any tracker mirror consistent.

package/templates/canonical/workflows/scope-requirement.md

@@ -9,8 +9,10 @@ Use the `requirement-scoper` capability to interactively scope and document a us
 ## Pipeline
 
 1. **Read Context** — Read `knowledge-base/`, `.engineering-intelligence/aidlc/`, `.engineering-intelligence/memory/`, and `.engineering-intelligence/graph/` mapping files.
-2. **Draft Questions** — Generate 3 to 5 targeted business/tech questions clarifying the requirements, user story, acceptance criteria, dependencies, and Definition of Ready.
-3. **Iterate** — Prompt the user for answers in the chat pane.
+2. **Draft Questions** — Assess clarity level:
+   - **Vague or Incomplete** (3+ ambiguities, unclear scope, or missing critical info): Use `question-file-engine` to write a structured MCQ clarification file at `.engineering-intelligence/aidlc/open-questions/`. Stop and wait for the user to fill answers and signal "questions answered, continue" before proceeding.
+   - **Clear** (0–2 minor gaps): Ask 3–5 targeted questions inline and iterate.
+3. **Iterate** — Wait for user responses (from question file or inline). Adjust assumptions based on answers.
 4. **Document Scoping** — Create or update `knowledge-base/19-requirements.md` and `.engineering-intelligence/aidlc/agile/` artifacts with goals, user stories, acceptance criteria, edge cases, dependencies, and the Q&A log.
 5. **Finalize Prompt** — Output the exact `/engineering-intelligence` command required to build the ready story.