@windyroad/itil 1.2.0 → 2.0.0-preview.1111

package/skills/list-problems/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "WR ITIL: List Problems"
+  short_description: "List open problems in WSJF order."

package/skills/list-stories/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: wr-itil:list-stories
-description: List INVEST-shaped story tickets from docs/stories/ as a markdown table. Read-only display — no edits, no interaction. Optional `--rfc RFC-<NNN>` filter to surface a specific RFC's ordered story list per ADR-060 Phase 2.
+description: List INVEST-shaped story tickets from docs/stories/ as a markdown table. Read-only display — no edits, no interaction. Optional `--rfc RFC-<NNN>` filter to surface a specific RFC's ordered story list per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Phase 2.
 allowed-tools: Read, Bash, Grep, Glob
 ---
 
 # List Stories
 
-Display the story corpus from `docs/stories/` as a markdown table. Read-only view of the story tier per ADR-060 Phase 2; this skill does not edit, transition, close, or create stories. For those operations, use the dedicated skills (`/wr-itil:capture-story`, `/wr-itil:manage-story`).
+Display the story corpus from `docs/stories/` as a markdown table. Read-only view of the story tier per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Phase 2; this skill does not edit, transition, close, or create stories. For those operations, use the dedicated skills (`/wr-itil:capture-story`, `/wr-itil:manage-story`).
 
-Mirrors the `/wr-itil:list-problems` precedent (P071 phased-landing split per ADR-010 amended Skill Granularity rule: one skill per distinct user intent). The list-stories surface separates the read-only view from the heavyweight `/wr-itil:manage-story list` subcommand route (which is itself a candidate for phased-landing split in a future slice).
+Mirrors the `/wr-itil:list-problems` precedent (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem phased-landing split per the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended Skill Granularity rule: one skill per distinct user intent). The list-stories surface separates the read-only view from the heavyweight `/wr-itil:manage-story list` subcommand route (which is itself a candidate for phased-landing split in a future slice).
 
 ## Scope
 
@@ -16,26 +16,26 @@ Stories live under `docs/stories/<state>/STORY-<NNN>-<slug>.md` in lifecycle sub
 
 - `docs/stories/draft/*.md` — draft (captured via `/wr-itil:capture-story`; pre-INVEST-acceptance)
 - `docs/stories/accepted/*.md` — accepted (INVEST-shape verified per I10; pre-implementation)
-- `docs/stories/in-progress/*.md` — in-progress (implementation underway; auto-transitioned from accepted on first `Refs: STORY-<NNN>` commit AFTER the capture commit per ADR-060 line 292)
+- `docs/stories/in-progress/*.md` — in-progress (implementation underway; auto-transitioned from accepted on first `Refs: STORY-<NNN>` commit AFTER the capture commit per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 292)
 - `docs/stories/done/*.md` — done (acceptance-criteria all-ticked + linked RFC closes; auto-transitioned from in-progress)
 - `docs/stories/archived/*.md` — archived (closed without completion; manual transition)
 
-Per ADR-060 I11 invariant (Phase 2 deferred): stories MUST NOT carry a WSJF field. Legacy RFC files retain their ordered frontmatter `stories:` array. Under ADR-103, newer RFCs are release rows and their story sequence comes from the row's cards on the map, NOT from per-story WSJF.
+Per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule I11 invariant (Phase 2 deferred): stories MUST NOT carry a WSJF field. Legacy RFC files retain their ordered frontmatter `stories:` array. Under the "A release row is the RFC, and the map is the approval surface" architecture rule, newer RFCs are release rows and their story sequence comes from the row's cards on the map, NOT from per-story WSJF.
 
 ## Argument grammar
 
-**Positional (optional)**: `--rfc RFC-<NNN>` flag-style filter. When provided, the display lists ONLY stories that trace to the named RFC, IN THE ORDER specified by the RFC's frontmatter `stories:` array per ADR-060 line 259. Without the flag, all stories across all lifecycle states are listed grouped by state.
+**Positional (optional)**: `--rfc RFC-<NNN>` flag-style filter. When provided, the display lists ONLY stories that trace to the named RFC, IN THE ORDER specified by the RFC's frontmatter `stories:` array per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 259. Without the flag, all stories across all lifecycle states are listed grouped by state.
 
 ```
 /wr-itil:list-stories                    # All stories, grouped by lifecycle state
-/wr-itil:list-stories --rfc RFC-002      # Only stories under RFC-002, in execution order
+/wr-itil:list-stories --rfc the ": docs/problems/ flat layout migration — per-state subdirs + adopter auto-migration" release design      # Only stories under the ": docs/problems/ flat layout migration — per-state subdirs + adopter auto-migration" release design, in execution order
 ```
 
 ## Steps
 
 ### 1. Check `docs/stories/README.md` cache freshness
 
-Reuse the same `git log`-based freshness test as `/wr-itil:list-problems` Step 1 (per P031 — filesystem mtime is unreliable in worktrees and fresh checkouts):
+Reuse the same `git log`-based freshness test as `/wr-itil:list-problems` Step 1 (per the "Problem 031: `manage-problem work` incorrectly determines cache is fresh" problem — filesystem mtime is unreliable in worktrees and fresh checkouts):
 
 ```bash
 readme_commit=$(git log -1 --format=%H -- docs/stories/README.md 2>/dev/null)
@@ -108,7 +108,7 @@ For each `STORY-<NNN>` in the ordered list, resolve to a file under `docs/storie
 
 Omit empty sections rather than rendering empty headers. The Estimated Effort column is omitted from the Draft section because effort is deferred at capture and only required at accepted per I10 INVEST Estimable.
 
-**The `Approved by` column (ADR-103, Accepted + In Progress sections only).** A story carries no oversight field; approval is its map's. Name the ratified map that approves it, since that is what the human actually looked at, and leave the column empty when no map in the story's `story-maps:` field is ratified. Derive it with `story_is_approved` — never by reading a `human-oversight:` line off the story, which no longer exists.
+**The `Approved by` column (the "A release row is the RFC, and the map is the approval surface" architecture rule, Accepted + In Progress sections only).** A story carries no oversight field; approval is its map's. Name the ratified map that approves it, since that is what the human actually looked at, and leave the column empty when no map in the story's `story-maps:` field is ratified. Derive it with `story_is_approved` — never by reading a `human-oversight:` line off the story, which no longer exists.
 
 **Filtered mode** (`--rfc RFC-<NNN>`) — render a single ordered table:
 
@@ -124,13 +124,13 @@ Omit empty sections rather than rendering empty headers. The Estimated Effort co
 ...
 ```
 
-The Order column makes the execution sequence visible — critical for the working-the-problem flow per ADR-060 line 314 ("read frontmatter `stories:` array (ordered) → pick first not-done story").
+The Order column makes the execution sequence visible — critical for the working-the-problem flow per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 314 ("read frontmatter `stories:` array (ordered) → pick first not-done story").
 
 ### 4. Trailing suggestions
 
 After the table(s), print one short pointer depending on output:
 
-- **Filtered mode + first not-done story exists**: `Run /wr-itil:work-problem to advance the next story under RFC-<NNN> (STORY-<NNN> — <title>).` (Note: working-the-problem traversal per ADR-060 line 300-320 lands in Slice 13.)
+- **Filtered mode + first not-done story exists**: `Run /wr-itil:work-problem to advance the next story under RFC-<NNN> (STORY-<NNN> — <title>).` (Note: working-the-problem traversal per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 300-320 lands in Slice 13.)
 - **Filtered mode + all stories done**: `All stories under RFC-<NNN> are done. Run /wr-itil:manage-rfc <RFC-<NNN>> verifying to transition the RFC.`
 - **Unfiltered mode + Draft section non-empty**: `Run /wr-itil:manage-story <STORY-<NNN>> accepted to advance a draft through INVEST gates.`
 - **Unfiltered mode + only Done section non-empty**: `No active stories. Run /wr-itil:capture-story to draft a new story.`
@@ -141,18 +141,18 @@ After the table(s), print one short pointer depending on output:
 
 ## Related
 
-- **ADR-060** — Problem-RFC-Story framework + Phase 2 amendment 2026-05-12 (story tier).
-- **ADR-060 line 259** — RFC frontmatter `stories:` ORDERED array (execution sequence).
-- **ADR-060 line 294** — `/wr-itil:list-stories` skill description with `--rfc RFC-<NNN>` filter.
-- **ADR-060 lines 300-320** — working-the-problem flow (Slice 13 lands the traversal).
-- **ADR-060 line 253** — I11 no-WSJF-leak invariant (Phase 2).
-- **P071** — phased-landing split precedent (list-problems split from manage-problem list).
-- **ADR-010 amended** — Skill Granularity rule.
-- **ADR-022** — lifecycle conventions (story lifecycle mirrors problem lifecycle).
-- **ADR-037** — contract-assertion bats pattern.
-- **P031** — git-history freshness check rationale.
-- **JTBD-008** — Decompose a Fix Into Coordinated Changes. The list view supports the working-the-problem flow that operationalises JTBD-008's "first-class entity" Desired Outcome.
-- **JTBD-006** — Progress the Backlog While I'm Away. Filtered mode (`--rfc`) feeds the AFK orchestrator's per-RFC iter dispatch (Slice 13).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule** — Problem-RFC-Story framework + Phase 2 amendment 2026-05-12 (story tier).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 259** — RFC frontmatter `stories:` ORDERED array (execution sequence).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 294** — `/wr-itil:list-stories` skill description with `--rfc RFC-<NNN>` filter.
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule lines 300-320** — working-the-problem flow (Slice 13 lands the traversal).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 253** — I11 no-WSJF-leak invariant (Phase 2).
+- **the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem** — phased-landing split precedent (list-problems split from manage-problem list).
+- **the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended** — Skill Granularity rule.
+- **the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule** — lifecycle conventions (story lifecycle mirrors problem lifecycle).
+- **the "Skill testing strategy — contract-assertion bats companion to" architecture rule** — contract-assertion bats pattern.
+- **the "Problem 031: `manage-problem work` incorrectly determines cache is fresh" problem** — git-history freshness check rationale.
+- **the ": Decompose a Fix Into Coordinated Changes" user outcome** — Decompose a Fix Into Coordinated Changes. The list view supports the working-the-problem flow that operationalises the ": Decompose a Fix Into Coordinated Changes" user outcome's "first-class entity" Desired Outcome.
+- **the ": Progress the Backlog While I'm Away" user outcome** — Progress the Backlog While I'm Away. Filtered mode (`--rfc`) feeds the AFK orchestrator's per-RFC iter dispatch (Slice 13).
 - `packages/itil/skills/list-problems/SKILL.md` — direct precedent shape.
 - `packages/itil/skills/list-incidents/SKILL.md` — sibling list-* skill at the incident tier.
 

package/skills/list-stories/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "WR ITIL: List Stories"
+  short_description: "List delivery stories and lifecycle state."

package/skills/list-story-maps/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: wr-itil:list-story-maps
-description: List story-map artefacts from docs/story-maps/ as a markdown table. Read-only display — no edits, no interaction. Renders <meta> block data (problems / rfcs / jtbd / status) from each HTML map per ADR-060 § Phase 2 encoding amendment 2026-05-12.
+description: List story-map artefacts from docs/story-maps/ as a markdown table. Read-only display — no edits, no interaction. Renders <meta> block data (problems / rfcs / jtbd / status) from each HTML map per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule § Phase 2 encoding amendment 2026-05-12.
 allowed-tools: Read, Bash, Grep, Glob
 ---
 
 # List Story Maps
 
-Display the story-map corpus from `docs/story-maps/` as a markdown table. Read-only view per ADR-060 Phase 2; does not edit, transition, or create maps.
+Display the story-map corpus from `docs/story-maps/` as a markdown table. Read-only view per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule Phase 2; does not edit, transition, or create maps.
 
-Mirrors `/wr-itil:list-stories` precedent (P071 phased-landing split per ADR-010). I5 invariant: story-maps MUST NOT carry WSJF (no Story Rankings table — maps are planning artefacts, not work items per ADR-060 line 145).
+Mirrors `/wr-itil:list-stories` precedent (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem phased-landing split per the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule). I5 invariant: story-maps MUST NOT carry WSJF (no Story Rankings table — maps are planning artefacts, not work items per the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 145).
 
 ## Scope
 
@@ -68,7 +68,7 @@ Render lifecycle-grouped sections:
 (same shape; sections omitted when empty)
 ```
 
-NO WSJF column per I5. NO ranking table per the "story-maps are planning artefacts, not work items" principle (ADR-060 line 145).
+NO WSJF column per I5. NO ranking table per the "story-maps are planning artefacts, not work items" principle (the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 145).
 
 ### 4. Trailing suggestions
 
@@ -82,12 +82,12 @@ Does not modify, rename, or commit files. Cache-stale path performs live scan on
 
 ## Related
 
-- **ADR-060** — Problem-RFC-Story framework; Phase 2 amendment lines 145-189 (story-map tier spec).
-- **ADR-060 line 145** — story-maps are planning artefacts; no WSJF (I5).
-- **ADR-060 lines 381-435** — HTML encoding schema; `<meta>` block parse target.
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule** — Problem-RFC-Story framework; Phase 2 amendment lines 145-189 (story-map tier spec).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule line 145** — story-maps are planning artefacts; no WSJF (I5).
+- **the "Problem-RFC-Story framework with mandatory problem-trace and unified problem ontology" architecture rule lines 381-435** — HTML encoding schema; `<meta>` block parse target.
 - **`docs/story-maps/README.md`** — story-map directory index.
 - **`/wr-itil:list-stories`** — sibling read-only display at the story tier.
-- **`/wr-itil:list-problems`** — sibling at the problem tier (P071 precedent).
-- **JTBD-008** — Decompose a Fix Into Coordinated Changes.
+- **`/wr-itil:list-problems`** — sibling at the problem tier (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem precedent).
+- **the ": Decompose a Fix Into Coordinated Changes" user outcome** — Decompose a Fix Into Coordinated Changes.
 
 $ARGUMENTS

package/skills/list-story-maps/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "WR ITIL: List Story Maps"
+  short_description: "List story maps, traces, and approval state."

package/skills/manage-incident/SKILL.md

@@ -60,7 +60,7 @@ Prefer **reversible** mitigations over forward fixes:
 
 Record every attempt, successful or not.
 
-**Mitigation SELECTION is agent-owned — do NOT defer "which mitigation" to the user (ADR-044 framework-mediated surface; category-4 silent-framework family).** Choosing *which* mitigation to attempt — traversing the ladder above, backed by cited evidence, within risk appetite — is the agent's call, not a user-authority decision. The framework already resolved it (the ladder is the selection mechanism, the evidence-first gate is the quality bar, RISK-POLICY appetite is the bound). Do NOT surface "which mitigation should I attempt?" via `AskUserQuestion` **or** a prose-ask ("I'll wait for your direction on which mitigation to attempt"). Authority: ADR-013 Rule 5; JTBD-201 ("reversible mitigations are preferred"); user direction 2026-05-10 — *"mitigations don't belong to me. You are empowered."* (P180). Genuine user-authority surfaces are unchanged: the evidence-gate bypass (ADR-044 category-2, Step 6) and the risk-above-appetite commit (category-3, Step 14). Mitigation execution is delegated to `/wr-itil:mitigate-incident` (Step 7), which carries the same empowerment annotation.
+**Mitigation SELECTION is agent-owned — do NOT defer "which mitigation" to the user (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule framework-mediated surface; category-4 silent-framework family).** Choosing *which* mitigation to attempt — traversing the ladder above, backed by cited evidence, within risk appetite — is the agent's call, not a user-authority decision. The framework already resolved it (the ladder is the selection mechanism, the evidence-first gate is the quality bar, RISK-POLICY appetite is the bound). Do NOT surface "which mitigation should I attempt?" via `AskUserQuestion` **or** a prose-ask ("I'll wait for your direction on which mitigation to attempt"). Authority: the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 5; the "Restore Service Fast with an Audit Trail" user outcome ("reversible mitigations are preferred"); user direction 2026-05-10 — *"mitigations don't belong to me. You are empowered."* (the "Agent defers mitigation selection to user during active incident — surfaces mitigation choice as user-authority when SKILL contract empowers agent-driven reversible mitigations" problem). Genuine user-authority surfaces are unchanged: the evidence-gate bypass (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category-2, Step 6) and the risk-above-appetite commit (category-3, Step 14). Mitigation execution is delegated to `/wr-itil:mitigate-incident` (Step 7), which carries the same empowerment annotation.
 
 ## Severity, not WSJF
 
@@ -82,11 +82,11 @@ Determine the operation from `$ARGUMENTS`:
 - If arguments start with `I<NNN>` or a bare number → this is an update
 - Otherwise → declare a new incident
 
-#### Deprecated-argument forwarders (ADR-010 amended + P071)
+#### Deprecated-argument forwarders (the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended + the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem)
 
-Per ADR-010's amended Skill Granularity section, word-argument subcommands that name distinct user intents are being split into their own named skills. During the deprecation window, this skill's Step 1 parser retains the legacy argument routes as **thin-router forwarders** that re-invoke the new named skill via the Skill tool AND emit a one-line systemMessage with the canonical deprecation notice so the user learns the new invocation shape.
+Per the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule's amended Skill Granularity section, word-argument subcommands that name distinct user intents are being split into their own named skills. During the deprecation window, this skill's Step 1 parser retains the legacy argument routes as **thin-router forwarders** that re-invoke the new named skill via the Skill tool AND emit a one-line systemMessage with the canonical deprecation notice so the user learns the new invocation shape.
 
-**Forwarder for `list`** (P071 split slice 5 — new skill `/wr-itil:list-incidents`):
+**Forwarder for `list`** (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 5 — new skill `/wr-itil:list-incidents`):
 
 When `$ARGUMENTS` contains the word `list` as a top-level argument (not inside an incident body edit), delegate to `/wr-itil:list-incidents` via the Skill tool and emit this systemMessage verbatim:
 
@@ -94,15 +94,15 @@ When `$ARGUMENTS` contains the word `list` as a top-level argument (not inside a
 
 The forwarder does NOT re-implement the list logic locally — it invokes the Skill tool with `wr-itil:list-incidents` and returns the new skill's output verbatim. Duplicating the scan logic would harden the deprecation window into a permanent fork.
 
-**Forwarder for `<I###> mitigate <action>`** (P071 split slice 6a — new skill `/wr-itil:mitigate-incident`):
+**Forwarder for `<I###> mitigate <action>`** (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6a — new skill `/wr-itil:mitigate-incident`):
 
 When `$ARGUMENTS` matches the shape `<I###> mitigate <action>` (an incident ID followed by the literal word `mitigate` followed by a free-text action), delegate to `/wr-itil:mitigate-incident <I###> <action>` via the Skill tool and emit this systemMessage verbatim:
 
 > `/wr-itil:manage-incident <I###> mitigate <action> is deprecated; use /wr-itil:mitigate-incident <I###> <action> directly. This forwarder will be removed in @windyroad/itil's next major version.`
 
-The forwarder does NOT re-implement the mitigation logic locally — it invokes the Skill tool with `wr-itil:mitigate-incident`, passes `<I###> <action>` through as the data parameters, and returns the new skill's output verbatim. Duplicating the rename + evidence-gate + timeline-append logic would harden the deprecation window into a permanent fork. The data-parameter shape `<I###> <action>` is permitted under ADR-010 amended — only the verb word `mitigate` is being split out.
+The forwarder does NOT re-implement the mitigation logic locally — it invokes the Skill tool with `wr-itil:mitigate-incident`, passes `<I###> <action>` through as the data parameters, and returns the new skill's output verbatim. Duplicating the rename + evidence-gate + timeline-append logic would harden the deprecation window into a permanent fork. The data-parameter shape `<I###> <action>` is permitted under the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended — only the verb word `mitigate` is being split out.
 
-**Forwarder for `<I###> restored`** (P071 split slice 6b — new skill `/wr-itil:restore-incident`):
+**Forwarder for `<I###> restored`** (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6b — new skill `/wr-itil:restore-incident`):
 
 When `$ARGUMENTS` matches the shape `<I###> restored` (an incident ID followed by the literal word `restored`), delegate to `/wr-itil:restore-incident <I###>` via the Skill tool and emit this systemMessage verbatim:
 
@@ -110,7 +110,7 @@ When `$ARGUMENTS` matches the shape `<I###> restored` (an incident ID followed b
 
 The forwarder does NOT re-implement the restore logic locally — it invokes the Skill tool with `wr-itil:restore-incident`, passes `<I###>` through as the data parameter, and returns the new skill's output verbatim. Duplicating the rename + verification-signal prompt + manage-problem handoff logic would harden the deprecation window into a permanent fork.
 
-**Forwarder for `<I###> close`** (P071 split slice 6c — new skill `/wr-itil:close-incident`):
+**Forwarder for `<I###> close`** (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6c — new skill `/wr-itil:close-incident`):
 
 When `$ARGUMENTS` matches the shape `<I###> close` (an incident ID followed by the literal word `close`), delegate to `/wr-itil:close-incident <I###>` via the Skill tool and emit this systemMessage verbatim:
 
@@ -118,24 +118,24 @@ When `$ARGUMENTS` matches the shape `<I###> close` (an incident ID followed by t
 
 The forwarder does NOT re-implement the close logic locally — it invokes the Skill tool with `wr-itil:close-incident`, passes `<I###>` through as the data parameter, and returns the new skill's output verbatim. Duplicating the linked-problem gate + rename logic would harden the deprecation window into a permanent fork.
 
-**Forwarder for `<I###> link P<MMM>`** (P071 split slice 6d — new skill `/wr-itil:link-incident`):
+**Forwarder for `<I###> link P<MMM>`** (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6d — new skill `/wr-itil:link-incident`):
 
 When `$ARGUMENTS` matches the shape `<I###> link P<MMM>` (an incident ID followed by the literal word `link` followed by a problem ID), delegate to `/wr-itil:link-incident <I###> P<MMM>` via the Skill tool and emit this systemMessage verbatim:
 
 > `/wr-itil:manage-incident <I###> link P<MMM> is deprecated; use /wr-itil:link-incident <I###> P<MMM> directly. This forwarder will be removed in @windyroad/itil's next major version.`
 
-The forwarder does NOT re-implement the link logic locally — it invokes the Skill tool with `wr-itil:link-incident`, passes `<I###> P<MMM>` through as the data parameters, and returns the new skill's output verbatim. Duplicating the problem-file-lookup + Linked Problem section write logic would harden the deprecation window into a permanent fork. The data-parameter shape `<I###> P<MMM>` is permitted under ADR-010 amended — only the verb word `link` is being split out.
+The forwarder does NOT re-implement the link logic locally — it invokes the Skill tool with `wr-itil:link-incident`, passes `<I###> P<MMM>` through as the data parameters, and returns the new skill's output verbatim. Duplicating the problem-file-lookup + Linked Problem section write logic would harden the deprecation window into a permanent fork. The data-parameter shape `<I###> P<MMM>` is permitted under the "Rename `wr-problem` Plugin to `wr-itil`" architecture rule amended — only the verb word `link` is being split out.
 
-### 2. For new incidents: Check for duplicates FIRST (ADR-044 category-1 direction-setting)
+### 2. For new incidents: Check for duplicates FIRST (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category-1 direction-setting)
 
 Before creating, search `docs/incidents/` for active (non-closed) incidents with overlapping symptoms or scope. The user may already have an incident open for this outage.
 
 1. Extract keywords from the description (e.g., "500 errors", "checkout", "login").
 2. `grep -l` the keywords across `docs/incidents/*.{investigating,mitigating,restored}.md`.
-3. If matches are found, present them via `AskUserQuestion` (this is the ADR-044 **category-1 (direction-setting)** surface — only the user knows whether the new symptoms describe the same outage as an existing ticket; the framework cannot resolve semantic similarity deterministically). Construct the call as:
+3. If matches are found, present them via `AskUserQuestion` (this is the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule **category-1 (direction-setting)** surface — only the user knows whether the new symptoms describe the same outage as an existing ticket; the framework cannot resolve semantic similarity deterministically). Construct the call as:
    - `header: "Active incidents found"`
    - `multiSelect: false`
-   - `question` body (plain prose, no parenthetical option-letters and no prose-ask phrasing per ADR-013 Confirmation criterion #1; the structured `options[]` below replaces both): `"I found active incidents that may be related: I003 (checkout 500s, mitigating), I007 (login slowness, investigating). Choose how to proceed:"`
+   - `question` body (plain prose, no parenthetical option-letters and no prose-ask phrasing per the "Structured User Interaction for Governance-Skill Decisions" architecture rule Confirmation criterion #1; the structured `options[]` below replaces both): `"I found active incidents that may be related: I003 (checkout 500s, mitigating), I007 (login slowness, investigating). Choose how to proceed:"`
    - `options[]`:
      1. `Update an existing incident` — description: "Switch to the update flow for the chosen incident ID; you'll name the ID in the next step."
      2. `Declare a new incident anyway` — description: "Proceed to Step 3 (assign next ID) and treat this as a distinct event."
@@ -154,34 +154,34 @@ next=$(printf 'I%03d' $((10#${last:-0} + 1)))
 echo "$next"
 ```
 
-### 4. For new incidents: Gather information (P132 derive-first; ADR-044 category-4 silent-framework on derivable fields; category-1 direction-setting fallback only on Scope)
+### 4. For new incidents: Gather information (the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem derive-first; the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category-4 silent-framework on derivable fields; category-1 direction-setting fallback only on Scope)
 
-**Shared dispatch helper**: this surface invokes `packages/itil/lib/derive-first-dispatch.sh` for the canonical slug derivation (Title), RISK-POLICY matrix lookup (Severity), and I2-isomorphic stderr advisory format. The helper is sourced by `/wr-itil:capture-problem`, `/wr-itil:manage-incident`, and `/wr-itil:manage-problem`; drift in the advisory shape re-opens P132. Surface-specific signal definitions (severity impact / likelihood regex lists, start-time evidence sources) stay inline below — the helper owns the mechanism, not the per-surface signals (architect verdict 2026-05-15 P132 Phase 2a-iii-A: "Helper must preserve per-surface signal definitions; only the dispatch mechanism is shared").
+**Shared dispatch helper**: this surface invokes `packages/itil/lib/derive-first-dispatch.sh` for the canonical slug derivation (Title), RISK-POLICY matrix lookup (Severity), and I2-isomorphic stderr advisory format. The helper is sourced by `/wr-itil:capture-problem`, `/wr-itil:manage-incident`, and `/wr-itil:manage-problem`; drift in the advisory shape re-opens the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem. Surface-specific signal definitions (severity impact / likelihood regex lists, start-time evidence sources) stay inline below — the helper owns the mechanism, not the per-surface signals (architect verdict 2026-05-15 the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem Phase 2a-iii-A: "Helper must preserve per-surface signal definitions; only the dispatch mechanism is shared").
 
 **Derive-first dispatch.** Incident declarations carry observable evidence in the user's prose, the working tree, `RISK-POLICY.md`, and the wall-clock — the framework can resolve most fields without firing `AskUserQuestion`. Only **Scope** is genuinely user-judgment (semantic blast-radius the framework cannot infer); only **Scope** retains the AskUserQuestion gate.
 
-The P132 inverse-P078 trap (`docs/problems/known-error/132-...md`) is the load-bearing motivation: the I001 declaration regression fired a 4-question AskUserQuestion with 3 of 4 sub-questions being lazy classifications (Title kebab-derivable, Severity matrix-derivable, Start time git-log-derivable). This dispatch closes that regression on the manage-incident surface and mirrors `/wr-itil:capture-problem` Step 1.5's worked-example pattern (P185 derive-first refactor).
+The "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem inverse-the "Problem 078: Assistant does not offer to capture a problem ticket when the user delivers strong-signal correction" problem trap (`docs/problems/known-error/132-...md`) is the load-bearing motivation: the I001 declaration regression fired a 4-question AskUserQuestion with 3 of 4 sub-questions being lazy classifications (Title kebab-derivable, Severity matrix-derivable, Start time git-log-derivable). This dispatch closes that regression on the manage-incident surface and mirrors `/wr-itil:capture-problem` Step 1.5's worked-example pattern (the "`/wr-itil:capture-problem` asks a classification question (technical vs user-business) that it can answer itself from the description's observable evidence" problem derive-first refactor).
 
 Resolve each field via the following dispatch. **The order is load-bearing** — every field except Scope resolves silently with a stderr advisory citing the source; Scope alone fires `AskUserQuestion` as the genuine category-1 surface.
 
-| Field | Dispatch | ADR-044 category |
+| Field | Dispatch | the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category |
 |-------|----------|------------------|
 | **Title** | Derive silently. Kebab-case the first 8-10 non-stopword tokens of the user's prose description (same slug derivation as `/wr-itil:capture-problem` Step 1.4 and `/wr-itil:manage-problem` Step 4). Emit stderr advisory: `manage-incident: derived title='<slug>' from description; re-invoke or rename the file if the slug is wrong`. Do NOT fire AskUserQuestion. | category-4 silent-framework |
 | **Symptoms** | Pull from user prose verbatim — the description text IS the symptoms surface for declaration. Place into the `## Observations` section template at Step 5. Do NOT fire AskUserQuestion. | category-4 silent-framework |
 | **Start time** | Derive silently, three sources in priority order: (a) explicit timestamp in description (regex `\b\d{4}-\d{2}-\d{2}([ T]\d{2}:\d{2})?\b`, or relative form `"<N> (minutes|hours|days) ago"` resolved against current wall-clock); (b) if the description cites a specific file or directory, run `git log --diff-filter=A --follow -- <path> \| tail -1` for first-touch evidence; (c) otherwise default to current wall-clock UTC. Emit stderr advisory: `manage-incident: start-time derived as <ts> from <source>; cite an additional evidence anchor in the Timeline section if symptoms began earlier`. Do NOT fire AskUserQuestion. | category-4 silent-framework |
-| **Severity** | Derive silently when evidence maps to a clear `RISK-POLICY.md` Impact × Likelihood cell. Cross-reference description signals against the matrix: (a) impact signals (service disruption keywords like `down` / `degraded` / `unavailable` → high; latency / throughput keywords → moderate; cosmetic / typo keywords → low); (b) likelihood signals (`reproducible` / `every request` → high; `intermittent` / `flaky` → medium; `one-off` / `single user` → low); (c) named anchors (held-cluster age cited → use that age to map cell; scorer state cited → use the cited band). When the cross-reference produces a single clear cell, set it silently and emit stderr advisory: `manage-incident: severity derived as <score> (<label>) from RISK-POLICY matrix + evidence: <evidence list>; re-invoke or update if mis-rated`. **Ambiguous-evidence fallback** (no mappable signal in description, or signals point to conflicting cells): fire AskUserQuestion with the Impact (1-5) × Likelihood (1-5) options as the genuine ADR-044 **category-5 (taste)** fallback surface. The fallback is genuine ambiguity, NOT defaults. | category-4 silent-framework (derivable); category-5 fallback (ambiguous) |
-| **Scope** | Retain AskUserQuestion. Scope is the user-judgment surface — only the user knows whether downstream-adopter-risk is in scope, whether mobile is affected, whether the blast radius extends past the cited symptoms. The framework cannot resolve semantic scope deterministically (same reasoning as Step 2 duplicate-check). Construct the call with `header: "Incident scope"`, `multiSelect: false` if a closed enum applies or free-text capture otherwise. This is the canonical ADR-044 **category-1 (direction-setting)** surface — *"only the user knows the goals that haven't been written down yet."* | category-1 direction-setting |
+| **Severity** | Derive silently when evidence maps to a clear `RISK-POLICY.md` Impact × Likelihood cell. Cross-reference description signals against the matrix: (a) impact signals (service disruption keywords like `down` / `degraded` / `unavailable` → high; latency / throughput keywords → moderate; cosmetic / typo keywords → low); (b) likelihood signals (`reproducible` / `every request` → high; `intermittent` / `flaky` → medium; `one-off` / `single user` → low); (c) named anchors (held-cluster age cited → use that age to map cell; scorer state cited → use the cited band). When the cross-reference produces a single clear cell, set it silently and emit stderr advisory: `manage-incident: severity derived as <score> (<label>) from RISK-POLICY matrix + evidence: <evidence list>; re-invoke or update if mis-rated`. **Ambiguous-evidence fallback** (no mappable signal in description, or signals point to conflicting cells): fire AskUserQuestion with the Impact (1-5) × Likelihood (1-5) options as the genuine the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule **category-5 (taste)** fallback surface. The fallback is genuine ambiguity, NOT defaults. | category-4 silent-framework (derivable); category-5 fallback (ambiguous) |
+| **Scope** | Retain AskUserQuestion. Scope is the user-judgment surface — only the user knows whether downstream-adopter-risk is in scope, whether mobile is affected, whether the blast radius extends past the cited symptoms. The framework cannot resolve semantic scope deterministically (same reasoning as Step 2 duplicate-check). Construct the call with `header: "Incident scope"`, `multiSelect: false` if a closed enum applies or free-text capture otherwise. This is the canonical the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule **category-1 (direction-setting)** surface — *"only the user knows the goals that haven't been written down yet."* | category-1 direction-setting |
 
 **Inferred fields (no ask, no advisory needed)**:
 
 - **Reported**: today's date (UTC)
 - **Status**: always "Investigating" for new incidents
 
-**Stderr advisory contract**: each derived field emits a SINGLE line to stderr (NOT stdout, NOT in the ticket body) per the capture-problem Step 1.5 pattern. The advisory text shape is I2-isomorphic — identical sentence structure across fields beyond substituted values + source names. Embedding the advisory in stdout would risk machine-readers parsing it as a ticket-body line; embedding it in the ticket body would violate ADR-011's required-section schema. Stderr is the correct channel — visible to interactive maintainers in the terminal; invisible to ticket consumers; loggable by orchestrators that capture subprocess stderr.
+**Stderr advisory contract**: each derived field emits a SINGLE line to stderr (NOT stdout, NOT in the ticket body) per the capture-problem Step 1.5 pattern. The advisory text shape is I2-isomorphic — identical sentence structure across fields beyond substituted values + source names. Embedding the advisory in stdout would risk machine-readers parsing it as a ticket-body line; embedding it in the ticket body would violate the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule's required-section schema. Stderr is the correct channel — visible to interactive maintainers in the terminal; invisible to ticket consumers; loggable by orchestrators that capture subprocess stderr.
 
-**ADR-026 cost-source grounding**: each derived field cites its source in the advisory (description token sequence for Title; explicit-regex / `git log` / wall-clock for Start time; RISK-POLICY matrix cell + named evidence for Severity). The `re-invoke or update if mis-rated` clause carries the reversibility marker ADR-026 mandates for ungrounded outputs.
+**the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule cost-source grounding**: each derived field cites its source in the advisory (description token sequence for Title; explicit-regex / `git log` / wall-clock for Start time; RISK-POLICY matrix cell + named evidence for Severity). The `re-invoke or update if mis-rated` clause carries the reversibility marker the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule mandates for ungrounded outputs.
 
-**AFK fail-safe (ADR-013 Rule 6)**: under AFK orchestration, all derivable fields resolve without interactive input; only Scope's AskUserQuestion can block. The orchestrator should halt-with-stderr citing which field needed input rather than guess (Scope is genuinely user-judgment per JTBD-006's "Problems requiring my judgment ... are queued for my return, not guessed at"). manage-incident is rarely AFK-invoked because incidents are interactive by design (JTBD-201), so the halt-on-Scope path is the expected behaviour, not a regression.
+**AFK fail-safe (the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 6)**: under AFK orchestration, all derivable fields resolve without interactive input; only Scope's AskUserQuestion can block. The orchestrator should halt-with-stderr citing which field needed input rather than guess (Scope is genuinely user-judgment per the ": Progress the Backlog While I'm Away" user outcome's "Problems requiring my judgment ... are queued for my return, not guessed at"). manage-incident is rarely AFK-invoked because incidents are interactive by design (the "Restore Service Fast with an Audit Trail" user outcome), so the halt-on-Scope path is the expected behaviour, not a regression.
 
 ### 5. For new incidents: Write the incident file
 
@@ -219,7 +219,7 @@ Resolve each field via the following dispatch. **The order is load-bearing** —
 *(none yet — added on restore transition)*
 ```
 
-### 6. For updates: Edit the existing file (evidence gate is ADR-044 category-2 deviation-approval)
+### 6. For updates: Edit the existing file (evidence gate is the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category-2 deviation-approval)
 
 Find the file by ID:
 
@@ -227,13 +227,13 @@ Find the file by ID:
 ls docs/incidents/<I###>-*.md 2>/dev/null
 ```
 
-Append new observations, hypotheses, or timeline entries. **Every hypothesis must cite evidence.** If the user proposes a hypothesis without evidence, fire the **3-option evidence gate** — same shape as `/wr-itil:mitigate-incident` Step 3, for cross-skill cool-headed-commitment consistency. This is the ADR-044 **category-2 (deviation-approval)** surface: ADR-011's evidence-first rule is the existing decision; "Record anyway" is the user-approved deviation in this specific case. The user is the right authority for the bypass shape.
+Append new observations, hypotheses, or timeline entries. **Every hypothesis must cite evidence.** If the user proposes a hypothesis without evidence, fire the **3-option evidence gate** — same shape as `/wr-itil:mitigate-incident` Step 3, for cross-skill cool-headed-commitment consistency. This is the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule **category-2 (deviation-approval)** surface: the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule's evidence-first rule is the existing decision; "Record anyway" is the user-approved deviation in this specific case. The user is the right authority for the bypass shape.
 
 Construct the `AskUserQuestion` call as:
 
 - `header: "Evidence gate"`
 - `multiSelect: false`
-- `question` body: `"Hypothesis '<one-line summary>' has no cited evidence reference. Per ADR-011 evidence-first rule, every hypothesis must cite a log / repro / diff / metric reference. Choose how to proceed:"`
+- `question` body: `"Hypothesis '<one-line summary>' has no cited evidence reference. Per the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule evidence-first rule, every hypothesis must cite a log / repro / diff / metric reference. Choose how to proceed:"`
 - `options[]`:
   1. `Add evidence now` — description: "Provide the evidence reference (log line, dashboard URL, repro steps, diff hash, etc.); the hypothesis lands with the cited evidence."
   2. `Record anyway with audit-trail bypass` — description: "Land the hypothesis without cited evidence; agent appends `[<timestamp> UTC] Evidence-gate bypassed by user — reason: <justification>` to the incident file's `## Audit trail` section."
@@ -241,19 +241,19 @@ Construct the `AskUserQuestion` call as:
 
 On option 2 (bypass), append the `Evidence-gate bypassed by user — reason: <justification>` line to the `## Audit trail` section of the incident file before writing the hypothesis. If the section does not exist, create it. The bypass-marker prose is fixed verbatim so post-incident review can locate every bypassed gate via grep.
 
-### 7. For mitigate: delegate to `/wr-itil:mitigate-incident` (P071 split slice 6a)
+### 7. For mitigate: delegate to `/wr-itil:mitigate-incident` (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6a)
 
 The `mitigate` subcommand is now hosted by the `/wr-itil:mitigate-incident` skill. This step exists as a thin-router forwarder — the Step 1 parser recognises the `<I###> mitigate <action>` shape and delegates via the Skill tool. This body is intentionally empty of implementation logic; the canonical documentation of the rename, Status update, evidence-gate pre-flight, and Mitigation attempts append lives in `/wr-itil:mitigate-incident`.
 
 Do not re-implement the rename or the evidence gate here — delegate. See "Deprecated-argument forwarders" under Step 1 for the canonical systemMessage.
 
-### 8. For restore: delegate to `/wr-itil:restore-incident` (P071 split slice 6b)
+### 8. For restore: delegate to `/wr-itil:restore-incident` (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6b)
 
 The `restored` subcommand is now hosted by the `/wr-itil:restore-incident` skill. This step exists as a thin-router forwarder — the Step 1 parser recognises the `<I###> restored` shape and delegates via the Skill tool. This body is intentionally empty of implementation logic; the canonical documentation of the pre-flight checks, rename, Status update, Timeline append, and manage-problem handoff lives in `/wr-itil:restore-incident`.
 
 Do not re-implement the rename or the problem handoff here — delegate. See "Deprecated-argument forwarders" under Step 1 for the canonical systemMessage.
 
-### 9. For close: delegate to `/wr-itil:close-incident` (P071 split slice 6c)
+### 9. For close: delegate to `/wr-itil:close-incident` (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6c)
 
 The `close` subcommand is now hosted by the `/wr-itil:close-incident` skill. This step exists as a thin-router forwarder — the Step 1 parser recognises the `<I###> close` shape and delegates via the Skill tool. This body is intentionally empty of implementation logic; the canonical documentation of the Linked-Problem gate (accepting `.known-error.md`, `.verifying.md`, and `.closed.md`), the No Problem bypass, and the rename lives in `/wr-itil:close-incident`.
 
@@ -263,7 +263,7 @@ Do not re-implement the close gate or the rename here — delegate. See "Depreca
 
 Read all `.investigating.md`, `.mitigating.md`, and `.restored.md` files in `docs/incidents/`. Extract ID, title, severity, and status. Sort by severity (highest first). Display as a markdown table.
 
-### 11. For link: delegate to `/wr-itil:link-incident` (P071 split slice 6d)
+### 11. For link: delegate to `/wr-itil:link-incident` (the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem split slice 6d)
 
 The `link` subcommand is now hosted by the `/wr-itil:link-incident` skill. This step exists as a thin-router forwarder — the Step 1 parser recognises the `<I###> link P<MMM>` shape and delegates via the Skill tool. This body is intentionally empty of implementation logic; the canonical documentation of the problem-file lookup and the `## Linked Problem` section write (including the retroactive-link-from-No-Problem case) lives in `/wr-itil:link-incident`.
 
@@ -287,7 +287,7 @@ After any operation, verify:
 - **Evidence discipline**: every Hypothesis has a cited evidence reference
 - **Linked Problem** section present and consistent (or **No Problem** with justification) once the incident reaches Restored
 
-### 14. Report (risk-above-appetite commit is ADR-044 category-3 one-time-override)
+### 14. Report (risk-above-appetite commit is the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule category-3 one-time-override)
 
 After any operation, report:
 
@@ -297,23 +297,23 @@ After any operation, report:
 - For restore: the linked problem ID (or "No Problem" note)
 - Any quality-check warnings
 
-Commit the completed work per ADR-014 (governance skills commit their own work):
+Commit the completed work per the "Governance Skills Commit Their Own Completed Work" architecture rule (governance skills commit their own work):
 1. `git add` all created/modified files for this operation
-2. Delegate to `wr-risk-scorer:pipeline` (subagent_type: `wr-risk-scorer:pipeline`) to assess the staged changes and create a bypass marker. If the subagent type is not available in the current tool set (e.g. this skill is running inside a spawned subagent), invoke `/wr-risk-scorer:assess-release` via the Skill tool instead — per ADR-015 it wraps the same pipeline subagent.
+2. Delegate to `wr-risk-scorer:pipeline` (subagent_type: `wr-risk-scorer:pipeline`) to assess the staged changes and create a bypass marker. If the subagent type is not available in the current tool set (e.g. this skill is running inside a spawned subagent), invoke `/wr-risk-scorer:assess-release` via the Skill tool instead — per the "On-Demand Assessment Skills for Governance Plugins" architecture rule it wraps the same pipeline subagent.
 3. `git commit -m "<message>"` using the convention for the operation type:
    - New incident: `docs(incidents): open I<NNN> <title>`
    - Incident mitigated: `docs(incidents): I<NNN> mitigated — <mitigation summary>`
    - Incident restored: `docs(incidents): I<NNN> restored — <action>`
    - Incident closed: `docs(incidents): close I<NNN>`
-4. If commit risk is above appetite: this is **framework-mediated, NOT a category-3 one-time-override ask** (P377/RFC-029 amendment 2026-06-24 — there is no incident carve-out). Per **ADR-042 Rule 1b (incident-context scoring)**: an active incident is a risk being realised (Likelihood already 5), so the incident-response change is scored against that live realised-risk baseline — weighing P(the change increases impact) vs P(it reduces impact & likelihood / restores service) + P(it introduces a new incident). If net risk-reducing, it takes the risk-reducing path (the `reducing` bypass — `RISK_BYPASS: reducing`) and proceeds, no ask. This is *better* for restore-service-fast (JTBD-201): a genuine hotfix clears via scoring with no consent gate mid-outage. If the change is NOT net-reducing, auto-remediate per ADR-042 Rule 1 or halt per Rule 5. **MUST NOT commit above appetite; MUST NOT `AskUserQuestion` "commit anyway".** If `AskUserQuestion` is unavailable, the ADR-013 Rule 6 fail-safe applies — skip the commit and report the uncommitted state.
+4. If commit risk is above appetite: this is **framework-mediated, NOT a category-3 one-time-override ask** (the "Skills, agents, and hooks override RISK-POLICY appetite instead of applying it" problem/the ": Apply RISK-POLICY appetite faithfully across all surfaces" release design amendment 2026-06-24 — there is no incident carve-out). Per **the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 1b (incident-context scoring)**: an active incident is a risk being realised (Likelihood already 5), so the incident-response change is scored against that live realised-risk baseline — weighing P(the change increases impact) vs P(it reduces impact & likelihood / restores service) + P(it introduces a new incident). If net risk-reducing, it takes the risk-reducing path (the `reducing` bypass — `RISK_BYPASS: reducing`) and proceeds, no ask. This is *better* for restore-service-fast (the "Restore Service Fast with an Audit Trail" user outcome): a genuine hotfix clears via scoring with no consent gate mid-outage. If the change is NOT net-reducing, auto-remediate per the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 1 or halt per Rule 5. **MUST NOT commit above appetite; MUST NOT `AskUserQuestion` "commit anyway".** If `AskUserQuestion` is unavailable, the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 6 fail-safe applies — skip the commit and report the uncommitted state.
 
-### 15. Auto-release when changesets are queued (ADR-020)
+### 15. Auto-release when changesets are queued (the "Governance skills auto-release when changesets are queued" architecture rule)
 
-**Skip this step if the skill is running inside an AFK orchestrator.** Orchestrators handle release cadence themselves per ADR-018 (Step 6.5). When in doubt, defer to the orchestrator by skipping this step.
+**Skip this step if the skill is running inside an AFK orchestrator.** Orchestrators handle release cadence themselves per the "Inter-iteration release cadence for AFK loops" architecture rule (Step 6.5). When in doubt, defer to the orchestrator by skipping this step.
 
 Otherwise, after the commit in step 14 lands, drain the release queue so the fix actually lands on npm without requiring manual user action.
 
-**Mechanism — delegate, do not re-implement scoring (per ADR-015):**
+**Mechanism — delegate, do not re-implement scoring (per the "On-Demand Assessment Skills for Governance Plugins" architecture rule):**
 
 1. Invoke the release scorer. Two paths are valid:
    - **Primary**: delegate to subagent type `wr-risk-scorer:pipeline` via the Agent tool.
@@ -321,7 +321,7 @@ Otherwise, after the commit in step 14 lands, drain the release queue so the fix
 2. Read the returned `RISK_SCORES: commit=X push=Y release=Z` line.
 3. **Drain condition**: if `push` and `release` are both within appetite (≤ 4/25, "Low" band per `RISK-POLICY.md`), AND `.changeset/` is non-empty, proceed to the drain action. Otherwise, skip the drain and report the unreleased state.
 
-**Drain action (non-interactive, policy-authorised per ADR-013 Rule 6):**
+**Drain action (non-interactive, policy-authorised per the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 6):**
 
 1. Run `npm run push:watch` (push + wait for CI to pass).
 2. If `.changeset/` remains non-empty after push (i.e. a release PR is pending), run `npm run release:watch` (merge the release PR + wait for npm publish).
@@ -329,39 +329,39 @@ Otherwise, after the commit in step 14 lands, drain the release queue so the fix
 
 **Failure handling**: If `release:watch` fails (CI failure, publish failure), stop and report the failure clearly. Do not retry non-interactively — the user must intervene.
 
-**Above-appetite branch (per ADR-042)**: If push or release risk is above appetite (≥ 5/25), the skill MUST auto-apply scorer remediations incrementally until residual risk converges within appetite, OR halt the skill per ADR-042 Rule 5 if the scorer cannot produce a convergent plan. **The skill MUST NOT release above appetite under any circumstance.** The skill MUST NOT call `AskUserQuestion` as a shortcut out of the auto-apply loop.
+**Above-appetite branch (per the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule)**: If push or release risk is above appetite (≥ 5/25), the skill MUST auto-apply scorer remediations incrementally until residual risk converges within appetite, OR halt the skill per the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 5 if the scorer cannot produce a convergent plan. **The skill MUST NOT release above appetite under any circumstance.** The skill MUST NOT call `AskUserQuestion` as a shortcut out of the auto-apply loop.
 
-**Auto-apply mechanism (ADR-042 Rule 2):**
+**Auto-apply mechanism (the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 2):**
 
 1. Parse the scorer's `RISK_REMEDIATIONS:` block.
 2. Read the descriptions. Decide what to do. The agent MAY follow a scorer suggestion, adapt it, or do something else entirely. There is no requirement to rank all suggestions upfront or iterate through them in order.
-3. **Verification Pending carve-out (ADR-042 Rule 2b)**: skip remediations that target a commit attached to a `.verifying.md` ticket.
-4. Apply the chosen action using standard primitives (git, Edit, Bash). Each auto-apply is its own commit (ADR-042 Rule 3 — non-AFK has no iteration wrapper to amend into); each commit goes through architect + JTBD + risk-scorer gates per ADR-014.
+3. **Verification Pending carve-out (the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 2b)**: skip remediations that target a commit attached to a `.verifying.md` ticket.
+4. Apply the chosen action using standard primitives (git, Edit, Bash). Each auto-apply is its own commit (the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule Rule 3 — non-AFK has no iteration wrapper to amend into); each commit goes through architect + JTBD + risk-scorer gates per the "Governance Skills Commit Their Own Completed Work" architecture rule.
 5. Re-score via the same delegation path as step 1 above.
 6. **Loop**: within appetite → drain per the Drain action above. Still above → continue working to reduce risk. The agent reads the new remediations and decides what to do next. Loop. Exhausted → Rule 5 halt.
 
 **Rule 5 halt (non-AFK mode)**: halt the skill. Emit the terminal report naming the final `RISK_SCORES:`, the Auto-apply trail, any Verification Pending ticket IDs implicated, and a one-line scorer-gap note. The user resolves interactively.
 
-`push:watch` and `release:watch` are policy-authorised actions when residual risk is within appetite per RISK-POLICY.md, so no `AskUserQuestion` is required for the drain itself (ADR-013 Rule 5). Auto-apply actions under Rules 2–7 are also policy-authorised per ADR-013 Rule 5.
+`push:watch` and `release:watch` are policy-authorised actions when residual risk is within appetite per RISK-POLICY.md, so no `AskUserQuestion` is required for the drain itself (the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 5). Auto-apply actions under Rules 2–7 are also policy-authorised per the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 5.
 
 ## Related
 
-- **P136** (`docs/problems/136-adr-044-alignment-audit-master.open.md`) — ADR-044 alignment audit master. This skill is the third high-ask SKILL audited under Phase 2 (after work-problem singular and mitigate-incident).
-- **ADR-044** (`docs/decisions/044-decision-delegation-contract.proposed.md`) — Decision-Delegation Contract. The skill's AskUserQuestion surfaces align with the 6-class authority taxonomy: Step 2 duplicate-check is **category-1 (direction-setting)**; Step 4 is **category-4 (silent-framework)** on Title / Symptoms / Start time / Severity-when-evidence-present + **category-1 (direction-setting)** on Scope + **category-5 (taste)** fallback on Severity-on-ambiguity (P132 derive-first refactor 2026-05-15 re-classified Step 4 from "single cat-1 declaration" to "derive-first dispatch with cat-1 / cat-5 fallback only"); Step 6 evidence-gate is **category-2 (deviation-approval)**; Step 14 risk-above-appetite is **category-3 (one-time-override)**; the **Mitigation preference** ladder's mitigation-SELECTION surface is **framework-mediated / category-4 silent-framework family** — agent-owned, no AskUserQuestion and no prose-ask (P180 declarative-layer fix; see "Mitigation preference").
-- **P132** (`docs/problems/known-error/132-agents-over-ask-in-interactive-sessions-conflating-mechanical-stages-with-user-interactive-stages.md`) — Agents over-ask in interactive sessions (inverse-P078). Step 4 derive-first refactor closes the 2026-05-06 I001 declaration regression where 3 of 4 sub-questions were lazy classifications. Composes with P185 (capture-problem Step 1.5 derive-first refactor — the in-tree worked-example precedent).
-- **P185** (`docs/problems/...`) — capture-problem Step 1.5 derive-first refactor. Step 4 mirrors the same dispatch shape (silent classifier + stderr advisory + AskUserQuestion only on ambiguity).
-- **ADR-013 amended Rule 1** (`docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md`) — structured user interaction; narrowed in P135 to defer to ADR-044 for framework-resolution boundary. All four surfaces retain `AskUserQuestion` as genuine user-authority surfaces under categories enumerated in ADR-044.
-- **ADR-013 Confirmation criterion #1** — `grep -inE "Options:.*\(a\)\|Your call:\|which would you like\|which way?"` returns zero matches. Step 2's prior prompt body violated this with `Would you like to (a) update...` phrasing; the P136 Phase 2 refactor (2026-04-28) closed the regression by lifting options into the `AskUserQuestion` `options[]` mechanism.
-- **ADR-011** (`docs/decisions/011-manage-incident-skill.proposed.md`) — incident lifecycle; evidence-first workflow; reversible-mitigation preference; Sev 4-5 lightweight path. Step 6's evidence-gate refactor (2026-04-28) extends ADR-011's evidence-first rule with the documented `Record anyway` audit-trail bypass that mitigate-incident already used (cool-headed-commitment consistency across the two incident skills).
-- **ADR-014** — governance skills commit their own work. Step 14 unchanged.
-- **ADR-015** — release scorer delegation pattern. Step 15 unchanged.
-- **ADR-018** + **ADR-020** — release cadence. Step 15 unchanged.
-- **ADR-026** — cost-source grounding. Step 6's audit-trail bypass note preserves grounding by capturing the user's justification at deviation time.
-- **ADR-042** — auto-apply scorer remediations. Step 15 above-appetite branch unchanged.
-- **P071** — skill-split origin (slice 6 — manage-incident is the host with thin-router forwarders for `list`, `mitigate`, `restored`, `close`, `link`).
-- **P081** — structural-grep retrofit; the `manage-incident-adr-044-contract.bats` companion test file carries the `tdd-review: structural-permitted` marker as the bridge until P081 Phase 2 retrofit lands.
-- **JTBD-001** (`docs/jtbd/developer/JTBD-001-enforce-governance.proposed.md`) — Surface 1 refactor preserves the duplicate-check governance gate while removing the prose-ask compliance gap; Surfaces 2 + 3 + 4 retain genuine consent-gate-for-the-genuinely-direction-setting / deviation-approval / one-time-override.
-- **JTBD-101** (`docs/jtbd/plugin-developer/JTBD-101-extend-suite.proposed.md`) — Step 6 evidence-gate refactor brings manage-incident into pattern parity with mitigate-incident's slice-6a evidence-gate. Adopters get one consistent evidence-gate pattern across both incident skills.
-- **JTBD-201** (`docs/jtbd/tech-lead/JTBD-201-restore-service-fast.proposed.md`) — Step 6 explicit `Record anyway` bypass strengthens the audit-trail outcome (implicit-bypass becomes explicit-bypass-with-permanent-trail) without weakening the cool-headed-commitment outcome (`Add evidence` remains the friction-free default; bypass requires conscious second choice).
+- **the "alignment audit — sweep all unaudited skills/hooks/agents/ADRs/JTBDs/READMEs against the framework-resolution boundary (master ticket)" problem** (`docs/problems/136-adr-044-alignment-audit-master.open.md`) — the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule alignment audit master. This skill is the third high-ask SKILL audited under Phase 2 (after work-problem singular and mitigate-incident).
+- **the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule** (`docs/decisions/044-decision-delegation-contract.proposed.md`) — Decision-Delegation Contract. The skill's AskUserQuestion surfaces align with the 6-class authority taxonomy: Step 2 duplicate-check is **category-1 (direction-setting)**; Step 4 is **category-4 (silent-framework)** on Title / Symptoms / Start time / Severity-when-evidence-present + **category-1 (direction-setting)** on Scope + **category-5 (taste)** fallback on Severity-on-ambiguity (the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem derive-first refactor 2026-05-15 re-classified Step 4 from "single cat-1 declaration" to "derive-first dispatch with cat-1 / cat-5 fallback only"); Step 6 evidence-gate is **category-2 (deviation-approval)**; Step 14 risk-above-appetite is **category-3 (one-time-override)**; the **Mitigation preference** ladder's mitigation-SELECTION surface is **framework-mediated / category-4 silent-framework family** — agent-owned, no AskUserQuestion and no prose-ask (the "Agent defers mitigation selection to user during active incident — surfaces mitigation choice as user-authority when SKILL contract empowers agent-driven reversible mitigations" problem declarative-layer fix; see "Mitigation preference").
+- **the "Agents over-ask in interactive sessions — conflating mechanical-stages with user-interactive-stages of multi-stage skill contracts (inverse-)" problem** (`docs/problems/known-error/132-agents-over-ask-in-interactive-sessions-conflating-mechanical-stages-with-user-interactive-stages.md`) — Agents over-ask in interactive sessions (inverse-the "Problem 078: Assistant does not offer to capture a problem ticket when the user delivers strong-signal correction" problem). Step 4 derive-first refactor closes the 2026-05-06 I001 declaration regression where 3 of 4 sub-questions were lazy classifications. Composes with the "`/wr-itil:capture-problem` asks a classification question (technical vs user-business) that it can answer itself from the description's observable evidence" problem (capture-problem Step 1.5 derive-first refactor — the in-tree worked-example precedent).
+- **the "`/wr-itil:capture-problem` asks a classification question (technical vs user-business) that it can answer itself from the description's observable evidence" problem** (`docs/problems/...`) — capture-problem Step 1.5 derive-first refactor. Step 4 mirrors the same dispatch shape (silent classifier + stderr advisory + AskUserQuestion only on ambiguity).
+- **the "Structured User Interaction for Governance-Skill Decisions" architecture rule amended Rule 1** (`docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md`) — structured user interaction; narrowed in the "Decision-delegation contract — agents over-apply Rule 1's interactive default to framework-resolved decisions; codify the framework-resolution boundary + AFK loop's batched-questions-as-deliverable + lazy-AskUserQuestion measurement" problem to defer to the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule for framework-resolution boundary. All four surfaces retain `AskUserQuestion` as genuine user-authority surfaces under categories enumerated in the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule.
+- **the "Structured User Interaction for Governance-Skill Decisions" architecture rule Confirmation criterion #1** — `grep -inE "Options:.*\(a\)\|Your call:\|which would you like\|which way?"` returns zero matches. Step 2's prior prompt body violated this with `Would you like to (a) update...` phrasing; the "alignment audit — sweep all unaudited skills/hooks/agents/ADRs/JTBDs/READMEs against the framework-resolution boundary (master ticket)" problem Phase 2 refactor (2026-04-28) closed the regression by lifting options into the `AskUserQuestion` `options[]` mechanism.
+- **the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule** (`docs/decisions/011-manage-incident-skill.proposed.md`) — incident lifecycle; evidence-first workflow; reversible-mitigation preference; Sev 4-5 lightweight path. Step 6's evidence-gate refactor (2026-04-28) extends the "Add `manage-incident` Skill to `wr-itil` Plugin" architecture rule's evidence-first rule with the documented `Record anyway` audit-trail bypass that mitigate-incident already used (cool-headed-commitment consistency across the two incident skills).
+- **the "Governance Skills Commit Their Own Completed Work" architecture rule** — governance skills commit their own work. Step 14 unchanged.
+- **the "On-Demand Assessment Skills for Governance Plugins" architecture rule** — release scorer delegation pattern. Step 15 unchanged.
+- **the "Inter-iteration release cadence for AFK loops" architecture rule** + **the "Governance skills auto-release when changesets are queued" architecture rule** — release cadence. Step 15 unchanged.
+- **the "Agent output grounding — no fabricated quantitative estimates, cite + persist + uncertainty" architecture rule** — cost-source grounding. Step 6's audit-trail bypass note preserves grounding by capturing the user's justification at deviation time.
+- **the "Auto-apply scorer remediations to reach within appetite — open action-class vocabulary" architecture rule** — auto-apply scorer remediations. Step 15 above-appetite branch unchanged.
+- **the "Problem 071: Argument-based skill subcommands are not discoverable in Claude Code autocomplete" problem** — skill-split origin (slice 6 — manage-incident is the host with thin-router forwarders for `list`, `mitigate`, `restored`, `close`, `link`).
+- **the "Problem 081: Structural source-content tests are wasteful — TDD agent should reject them and require behavioural tests (+ framework / stub enhancements)" problem** — structural-grep retrofit; the `manage-incident-adr-044-contract.bats` companion test file carries the `tdd-review: structural-permitted` marker as the bridge until the "Problem 081: Structural source-content tests are wasteful — TDD agent should reject them and require behavioural tests (+ framework / stub enhancements)" problem Phase 2 retrofit lands.
+- **the ": Enforce Governance Without Slowing Down" user outcome** (`docs/jtbd/developer/the ": Enforce Governance Without Slowing Down" user outcome-enforce-governance.proposed.md`) — Surface 1 refactor preserves the duplicate-check governance gate while removing the prose-ask compliance gap; Surfaces 2 + 3 + 4 retain genuine consent-gate-for-the-genuinely-direction-setting / deviation-approval / one-time-override.
+- **the "Extend the Suite with New Plugins" user outcome** (`docs/jtbd/plugin-developer/the "Extend the Suite with New Plugins" user outcome-extend-suite.proposed.md`) — Step 6 evidence-gate refactor brings manage-incident into pattern parity with mitigate-incident's slice-6a evidence-gate. Adopters get one consistent evidence-gate pattern across both incident skills.
+- **the "Restore Service Fast with an Audit Trail" user outcome** (`docs/jtbd/tech-lead/the "Restore Service Fast with an Audit Trail" user outcome-restore-service-fast.proposed.md`) — Step 6 explicit `Record anyway` bypass strengthens the audit-trail outcome (implicit-bypass becomes explicit-bypass-with-permanent-trail) without weakening the cool-headed-commitment outcome (`Add evidence` remains the friction-free default; bypass requires conscious second choice).
 
 $ARGUMENTS

package/skills/manage-incident/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "WR ITIL: Manage Incident"
+  short_description: "Declare, triage, mitigate, restore, and close incidents."