@windyroad/itil 0.2.0-preview.62 → 0.3.0-preview.68

package/README.md

@@ -6,16 +6,25 @@ Part of [Windy Road Agent Plugins](../../README.md).
 
 ## What It Does
 
-Bugs recur. Incidents repeat. Without a problem management process, you fix symptoms instead of causes. This plugin brings lightweight ITIL problem management to your AI coding workflow:
+Bugs recur. Incidents repeat. Without a disciplined process, you fix symptoms instead of causes — or worse, jump to conclusions during a live outage. This plugin brings lightweight ITIL service management to your AI coding workflow:
+
+**Problem management** — track underlying causes and prioritise fixes:
 
 - **Create problem tickets** when incidents or failures surface during a session
 - **Track root cause analysis** as investigation progresses
 - **Transition status** through a structured lifecycle: Open, Known Error, Closed
 - **Prioritise** using Weighted Shortest Job First (WSJF) to focus on the highest-value fixes
 
-Problem tickets live in `docs/problems/` as markdown files -- version-controlled and always accessible.
+**Incident management** — restore service fast with an audit trail:
+
+- **Declare incidents** when production is actively broken
+- **Evidence-first discipline** — hypotheses must cite evidence before any mitigation
+- **Reversible mitigations first** — rollback, feature flag, restart, route away
+- **Automatic handoff** to problem management once service is restored
 
-Room is reserved for peer ITIL skills (incident, change) under the same plugin as they are added.
+Tickets live in `docs/problems/` and `docs/incidents/` as markdown files — version-controlled and always accessible.
+
+Room is reserved for peer ITIL skills (change, continual improvement) under the same plugin as they are added.
 
 ## Install
 
@@ -31,18 +40,23 @@ Restart Claude Code after installing.
 
 ## Usage
 
-**Create or update a problem ticket:**
+**Manage a problem ticket:**
 
 ```
 /wr-itil:manage-problem
 ```
 
-This supports:
+Supports creating new problems, updating root cause analysis, transitioning status (Open → Known Error → Closed), and closing problems with resolution details.
+
+**Manage an incident:**
+
+```
+/wr-itil:manage-incident
+```
+
+Supports declaring new incidents, recording evidence-first observations and hypotheses, logging mitigation attempts, transitioning lifecycle (Investigating → Mitigating → Restored → Closed), and automatically handing off to `manage-problem` when service is restored.
 
-- Creating new problems from an incident or observed failure
-- Updating root cause analysis with investigation findings
-- Transitioning status (Open -> Known Error -> Closed)
-- Closing problems with resolution details
+See [ADR-011](../../docs/decisions/011-manage-incident-skill.proposed.md) for the incident-vs-problem split and [JTBD-201](../../docs/jtbd/tech-lead/JTBD-201-restore-service-fast.proposed.md) for the job this serves.
 
 ## How It Works
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "0.2.0-preview.62",
+  "version": "0.3.0-preview.68",
   "description": "ITIL-aligned IT service management for Claude Code (problem, and future incident/change skills)",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/manage-incident/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: wr-itil:manage-incident
+description: Declare, triage, mitigate, and close an incident using an evidence-first workflow. Restores service first, then hands off to manage-problem for root-cause work.
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill
+---
+
+# Incident Management Skill
+
+Declare, triage, mitigate, and close an incident using an evidence-first, cool-headed workflow. This skill's primary goal is **restoring service**. Once service is restored, the skill hands off to `wr-itil:manage-problem` so the underlying cause is tracked.
+
+Incidents are time-bound events. Problems are persistent root causes. One problem can cause many incidents; one incident may (or may not) link to a problem.
+
+## Operations
+
+- **Declare**: `incident <title or symptoms>` — creates a new investigating incident
+- **Update**: `incident <NNN> <details>` — append observations, evidence, or actions
+- **Mitigate**: `incident <NNN> mitigate <action>` — record a mitigation attempt and outcome
+- **Restore**: `incident <NNN> restored` — transition to `.restored.md` and trigger problem handoff
+- **Close**: `incident <NNN> close` — only allowed when the linked problem is Known Error or Closed (or an explicit "no problem required" justification is recorded)
+- **List**: `incident list` — active incidents, severity-sorted
+- **Link**: `incident <NNN> link P<MMM>` — link an incident to an existing problem
+
+## Lifecycle
+
+| Status | File suffix | Meaning | Entry criteria |
+|--------|-------------|---------|----------------|
+| **Investigating** | `.investigating.md` | Symptoms reported, scope being established | Incident declared |
+| **Mitigating** | `.mitigating.md` | Mitigation(s) in flight | At least one ranked hypothesis with cited evidence |
+| **Restored** | `.restored.md` | Service verified restored | Mitigation applied + verification signal recorded |
+| **Closed** | `.closed.md` | Incident complete | Linked problem is Known Error or Closed (or "no problem required" justification documented) |
+
+## Evidence-First Workflow (The Cool-Headed Commitment)
+
+During an incident, the instinct to jump to conclusions is strong. This skill forces evidence-first discipline via a required template. **Do not act on a hypothesis without at least one cited evidence source.**
+
+### Required sections in every incident file
+
+```markdown
+## Observations
+- [timestamp] <what was seen, from where — e.g. "14:02 UTC, 500s on /api/orders in Datadog dashboard foo">
+
+## Hypotheses
+- [ranked] <hypothesis> — Evidence: <log/repro/diff/metric reference>. Confidence: <low|med|high>.
+
+## Mitigation attempts
+- [timestamp] <action> → <outcome / verification signal>
+```
+
+### Mitigation preference
+
+Prefer **reversible** mitigations over forward fixes:
+
+1. Rollback to a known-good version
+2. Feature flag off
+3. Restart / cycle the affected component
+4. Route traffic away
+5. Scale up
+6. Only after reversibles are exhausted: forward fix
+
+Record every attempt, successful or not.
+
+## Severity, not WSJF
+
+Incidents are severity-driven and time-boxed. **WSJF does not apply to incidents** — the "effort" divisor is meaningless during a live event. WSJF applies to the resulting problem created via handoff.
+
+Severity uses the Impact × Likelihood matrix from `RISK-POLICY.md`, interpreted as "right now, what's the live business impact?" — not "in general, how bad could this be?".
+
+## Steps
+
+### 1. Parse the request
+
+Determine the operation from `$ARGUMENTS`:
+
+- If arguments start with "list" → show active incidents summary
+- If arguments start with `I<NNN>` or a bare number → this is an update, mitigate, restore, close, or link
+- Otherwise → declare a new incident
+
+### 2. For new incidents: Check for duplicates FIRST
+
+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`:
+   - "I found active incidents that may be related: I003 (checkout 500s, mitigating), I007 (login slowness, investigating). Would you like to (a) update an existing incident, (b) declare a new incident anyway, or (c) cancel?"
+4. If the user chooses to update, switch to the update flow for that incident ID
+5. If no matches, proceed to create
+
+### 3. For new incidents: Assign the next ID
+
+Create `docs/incidents/` if it does not exist. Then scan for the highest existing `I<NNN>` and increment:
+
+```bash
+mkdir -p docs/incidents
+last=$(ls docs/incidents/I*.md 2>/dev/null | sed 's/.*\///' | grep -oE '^I[0-9]+' | sed 's/^I//' | sort -n | tail -1)
+next=$(printf 'I%03d' $((10#${last:-0} + 1)))
+echo "$next"
+```
+
+### 4. For new incidents: Gather information
+
+Use `AskUserQuestion` for anything not in `$ARGUMENTS`:
+
+- **Title**: short kebab-case-friendly description
+- **Symptoms**: what is observable (errors, latency, missing data)?
+- **Scope**: who/what is affected (users, endpoints, regions)?
+- **Start time**: when did symptoms begin? (UTC, as precise as known)
+- **Severity**: Impact (1-5) × Likelihood (1-5) per `RISK-POLICY.md`, interpreted as live impact
+
+Do not ask for fields that can be inferred:
+
+- **Reported**: today's date (UTC)
+- **Status**: always "Investigating" for new incidents
+
+### 5. For new incidents: Write the incident file
+
+**File path**: `docs/incidents/<I###>-<kebab-case-title>.investigating.md`
+
+**Template**:
+
+```markdown
+# Incident <I###>: <Title>
+
+**Status**: Investigating
+**Reported**: <YYYY-MM-DD HH:MM UTC>
+**Severity**: <score> (<label>) — Impact: <label> (<n>) x Likelihood: <label> (<n>)
+**Scope**: <who/what is affected>
+
+## Timeline
+
+- [<start-time> UTC] Symptoms began
+- [<reported-time> UTC] Incident declared
+
+## Observations
+
+- [<timestamp> UTC] <what was seen, from where>
+
+## Hypotheses
+
+- [ranked] <hypothesis> — Evidence: <log/repro/diff/metric reference>. Confidence: <low|med|high>.
+
+## Mitigation attempts
+
+*(none yet)*
+
+## Linked Problem
+
+*(none yet — added on restore transition)*
+```
+
+### 6. For updates: Edit the existing file
+
+Find the file by ID:
+
+```bash
+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, ask via `AskUserQuestion` what evidence supports it before writing.
+
+### 7. For mitigate: Record and transition to mitigating
+
+When the first mitigation attempt is made:
+
+1. `git mv docs/incidents/<I###>-<title>.investigating.md docs/incidents/<I###>-<title>.mitigating.md`
+2. Update the **Status** field to "Mitigating"
+3. Append to **Mitigation attempts**: `[<timestamp> UTC] <action> → <outcome>` (outcome may be "pending verification" initially; update once the verification signal is known)
+
+Pre-flight check before first mitigation: the file must contain at least one hypothesis with cited evidence. If not, block the transition and ask the user what evidence supports the chosen action.
+
+### 8. For restore: Transition and hand off to manage-problem
+
+Pre-flight checks before restore:
+
+- [ ] At least one mitigation attempt is recorded with outcome
+- [ ] A verification signal is captured (e.g., "error rate back to baseline per Datadog", "user reports normal", "synthetic probe passing")
+
+If checks pass:
+
+1. `git mv docs/incidents/<I###>-<title>.mitigating.md docs/incidents/<I###>-<title>.restored.md`
+2. Update the **Status** field to "Restored"
+3. Append to **Timeline**: `[<timestamp> UTC] Service restored — <verification signal>`
+
+Then perform the **handoff to problem management**:
+
+1. Ask via `AskUserQuestion`: "Service restored. Should I create or update a problem record for the root cause? (a) yes — recommended, (b) no — document why (trivial/one-off)"
+2. If yes, construct a handoff payload:
+   - Incident ID and title
+   - Timeline summary
+   - Top-ranked hypothesis + cited evidence
+   - Mitigation applied + verification signal
+3. Invoke `wr-itil:manage-problem` via the `Skill` tool with the payload as arguments. The problem skill's existing dedupe flow handles new-vs-update.
+4. Capture the returned `P<NNN>` and write a **Linked Problem** section into the incident file:
+   ```markdown
+   ## Linked Problem
+   P<NNN> (<title>) — <status>
+   ```
+5. If the user chose "no", write a **No Problem** section with the justification and skip the handoff:
+   ```markdown
+   ## No Problem
+   <reason — e.g. "one-off cosmic-bit-flip; not reproducible">
+   ```
+
+### 9. For close: Gate on linked problem status
+
+The close operation checks the linked problem's file suffix:
+
+```bash
+linked_id=<extracted from Linked Problem section>
+linked_file=$(ls docs/problems/${linked_id}-*.md 2>/dev/null | head -1)
+```
+
+- If `linked_file` ends with `.known-error.md` or `.closed.md` → close is allowed
+- If `linked_file` ends with `.open.md` → close is blocked; report "Linked problem ${linked_id} is still Open. Transition it to Known Error first, or update the Linked Problem reference."
+- If no linked problem and the file has a **No Problem** section → close is allowed
+
+On close:
+
+1. `git mv docs/incidents/<I###>-<title>.restored.md docs/incidents/<I###>-<title>.closed.md`
+2. Update the **Status** field to "Closed"
+3. Append to **Timeline**: `[<timestamp> UTC] Incident closed`
+
+### 10. For list: Show active incidents
+
+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: Attach a problem
+
+When the user runs `incident <I###> link P<MMM>`:
+
+1. Verify `docs/problems/P<MMM>-*.md` exists
+2. Read or add the **Linked Problem** section with `P<MMM> (<title>) — <status>`
+3. Report the link
+
+### 12. Edge cases
+
+- **No problem required** — record a **No Problem** section with justification; close immediately.
+- **Multiple incidents → one problem** — each incident links to the same `P<NNN>`; the problem file accumulates "Reported by incident" entries via `manage-problem`'s update flow.
+- **Problem re-opens after the incident closed** — the closed incident stays closed; a new incident is declared for the new occurrence, linked to the re-opened problem.
+- **Low-severity / solo-developer lightweight path** — for Sev 4-5 incidents, the skill may skip the Hypotheses section if the user confirms no investigation is needed. Timeline, Observations, and at least one mitigation attempt remain mandatory.
+
+### 13. Quality checks
+
+After any operation, verify:
+
+- **ID uniqueness**: no duplicate `I<NNN>` in `docs/incidents/`
+- **Naming convention**: `I<NNN>-<kebab-case-title>.<status>.md`
+- **Status consistency**: Status field matches filename suffix
+- **Required sections**: Timeline, Observations, Hypotheses (or documented skip), Mitigation attempts
+- **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
+
+After any operation, report:
+
+- The file path created/modified
+- The incident ID and title
+- The current status
+- For restore: the linked problem ID (or "No Problem" note)
+- Any quality-check warnings
+
+Do not commit. The user will commit when ready.
+
+$ARGUMENTS

package/skills/manage-incident/test/manage-incident.bats

@@ -0,0 +1,171 @@
+#!/usr/bin/env bats
+# Functional tests for the manage-incident skill (Option A-lite per ADR-011).
+#
+# Scope: execute the bash fragments the SKILL.md instructs Claude to run
+# (ID assignment, file-path construction, directory creation) and assert on
+# the mocked Skill-tool handoff contract between manage-incident and
+# manage-problem. Source-grep assertions on SKILL.md prose are NOT used
+# (P011 ban). A single structural check asserts SKILL.md exists and has
+# frontmatter — file-existence checks are a Permitted Exception per ADR-005.
+
+setup() {
+  SKILL_DIR="$(cd "$(dirname "$BATS_TEST_FILENAME")/.." && pwd)"
+  SKILL_FILE="${SKILL_DIR}/SKILL.md"
+
+  TEST_ROOT="$(mktemp -d "${TMPDIR:-/tmp}/manage-incident-bats-XXXXXX")"
+  INCIDENTS_DIR="${TEST_ROOT}/docs/incidents"
+  PROBLEMS_DIR="${TEST_ROOT}/docs/problems"
+}
+
+teardown() {
+  rm -rf "$TEST_ROOT"
+}
+
+# --- Fragment: next-ID computation (I###) ---
+# SKILL.md instructs: scan docs/incidents/ for existing I<NNN> files, take the
+# highest numeric ID, increment by 1, zero-pad to 3 digits.
+next_incident_id() {
+  local dir="$1"
+  local last
+  last=$(ls "$dir"/I*.md 2>/dev/null | sed 's/.*\///' | grep -oE '^I[0-9]+' | sed 's/^I//' | sort -n | tail -1)
+  if [[ -z "$last" ]]; then
+    printf 'I001'
+  else
+    printf 'I%03d' $((10#$last + 1))
+  fi
+}
+
+# --- Fragment: file path construction ---
+incident_path() {
+  local dir="$1" id="$2" slug="$3" status="$4"
+  printf '%s/%s-%s.%s.md' "$dir" "$id" "$slug" "$status"
+}
+
+# --- Mock: Skill-tool invocation contract ---
+# The SKILL.md instructs Claude to invoke wr-itil:manage-problem via the
+# Skill tool on restoration. The contract (skill name + argument shape) is
+# asserted by a mock that writes the payload to a file the test reads back.
+invoke_skill_mock() {
+  local tool="$1" skill="$2" args="$3"
+  printf '%s\n%s\n%s\n' "$tool" "$skill" "$args" > "${TEST_ROOT}/skill-invocation.log"
+}
+
+# ---- Tests ----
+
+@test "SKILL.md exists and has frontmatter" {
+  [ -f "$SKILL_FILE" ]
+  run head -1 "$SKILL_FILE"
+  [ "$status" -eq 0 ]
+  [ "$output" = "---" ]
+}
+
+@test "next_incident_id returns I001 when docs/incidents is empty" {
+  mkdir -p "$INCIDENTS_DIR"
+  run next_incident_id "$INCIDENTS_DIR"
+  [ "$status" -eq 0 ]
+  [ "$output" = "I001" ]
+}
+
+@test "next_incident_id returns I001 when docs/incidents does not exist" {
+  run next_incident_id "$INCIDENTS_DIR"
+  [ "$status" -eq 0 ]
+  [ "$output" = "I001" ]
+}
+
+@test "next_incident_id increments past the highest existing ID" {
+  mkdir -p "$INCIDENTS_DIR"
+  : > "$INCIDENTS_DIR/I001-foo.closed.md"
+  : > "$INCIDENTS_DIR/I002-bar.restored.md"
+  : > "$INCIDENTS_DIR/I005-baz.investigating.md"
+  run next_incident_id "$INCIDENTS_DIR"
+  [ "$status" -eq 0 ]
+  [ "$output" = "I006" ]
+}
+
+@test "next_incident_id zero-pads three digits" {
+  mkdir -p "$INCIDENTS_DIR"
+  : > "$INCIDENTS_DIR/I098-foo.closed.md"
+  run next_incident_id "$INCIDENTS_DIR"
+  [ "$status" -eq 0 ]
+  [ "$output" = "I099" ]
+}
+
+@test "next_incident_id ignores non-incident files" {
+  mkdir -p "$INCIDENTS_DIR"
+  : > "$INCIDENTS_DIR/README.md"
+  : > "$INCIDENTS_DIR/notes.md"
+  run next_incident_id "$INCIDENTS_DIR"
+  [ "$status" -eq 0 ]
+  [ "$output" = "I001" ]
+}
+
+@test "incident_path builds investigating file path" {
+  run incident_path "$INCIDENTS_DIR" "I001" "login-500s" "investigating"
+  [ "$status" -eq 0 ]
+  [ "$output" = "${INCIDENTS_DIR}/I001-login-500s.investigating.md" ]
+}
+
+@test "incident_path supports all lifecycle suffixes" {
+  for suffix in investigating mitigating restored closed; do
+    run incident_path "$INCIDENTS_DIR" "I042" "x" "$suffix"
+    [ "$status" -eq 0 ]
+    [ "$output" = "${INCIDENTS_DIR}/I042-x.${suffix}.md" ]
+  done
+}
+
+@test "docs/incidents is auto-created on first declaration" {
+  [ ! -d "$INCIDENTS_DIR" ]
+  mkdir -p "$INCIDENTS_DIR"
+  [ -d "$INCIDENTS_DIR" ]
+  id=$(next_incident_id "$INCIDENTS_DIR")
+  path=$(incident_path "$INCIDENTS_DIR" "$id" "test" "investigating")
+  : > "$path"
+  [ -f "$path" ]
+}
+
+@test "restore handoff invokes Skill tool with wr-itil:manage-problem and payload" {
+  invoke_skill_mock "Skill" "wr-itil:manage-problem" "incident I001 login-500s — rollback v1.4.3 restored service at 14:30 UTC"
+  [ -f "${TEST_ROOT}/skill-invocation.log" ]
+  run cat "${TEST_ROOT}/skill-invocation.log"
+  [ "$status" -eq 0 ]
+  [ "${lines[0]}" = "Skill" ]
+  [ "${lines[1]}" = "wr-itil:manage-problem" ]
+  [[ "${lines[2]}" == *"I001"* ]]
+  [[ "${lines[2]}" == *"rollback"* ]]
+}
+
+@test "restore handoff payload carries incident ID and mitigation" {
+  invoke_skill_mock "Skill" "wr-itil:manage-problem" "incident I042 — mitigation: feature flag off — verified via Datadog"
+  run cat "${TEST_ROOT}/skill-invocation.log"
+  [[ "${lines[2]}" == *"I042"* ]]
+  [[ "${lines[2]}" == *"feature flag off"* ]]
+  [[ "${lines[2]}" == *"Datadog"* ]]
+}
+
+@test "handoff contract rejects invocation with wrong skill name" {
+  invoke_skill_mock "Skill" "wr-itil:manage-change" "incident I001"
+  run grep -c '^wr-itil:manage-problem$' "${TEST_ROOT}/skill-invocation.log"
+  [ "$output" = "0" ]
+}
+
+@test "close is blocked when linked problem file is .open.md" {
+  mkdir -p "$PROBLEMS_DIR"
+  : > "$PROBLEMS_DIR/P050-root.open.md"
+  # close-gate: close only if linked P### is known-error or closed
+  linked=$(ls "$PROBLEMS_DIR"/P050-*.md 2>/dev/null | head -1)
+  [[ "$linked" != *".known-error.md" && "$linked" != *".closed.md" ]]
+}
+
+@test "close is allowed when linked problem file is .known-error.md" {
+  mkdir -p "$PROBLEMS_DIR"
+  : > "$PROBLEMS_DIR/P050-root.known-error.md"
+  linked=$(ls "$PROBLEMS_DIR"/P050-*.md 2>/dev/null | head -1)
+  [[ "$linked" == *".known-error.md" || "$linked" == *".closed.md" ]]
+}
+
+@test "close is allowed when linked problem file is .closed.md" {
+  mkdir -p "$PROBLEMS_DIR"
+  : > "$PROBLEMS_DIR/P050-root.closed.md"
+  linked=$(ls "$PROBLEMS_DIR"/P050-*.md 2>/dev/null | head -1)
+  [[ "$linked" == *".known-error.md" || "$linked" == *".closed.md" ]]
+}

package/skills/manage-problem/SKILL.md

@@ -83,6 +83,12 @@ What "work" means depends on the problem's status:
 3. Include the problem doc closure in the fix commit (`git mv` to `.closed.md`, update Status)
 4. Push, create changeset, release per the lean release principle
 
+**Scope expansion during work:** If investigation or architect review reveals that the problem's scope has grown significantly (e.g., effort re-sized from S to L, additional files discovered), use `AskUserQuestion` before continuing:
+- Option 1: `Continue with expanded scope` — keep working this problem at its new size
+- Option 2: `Update problem and re-rank` — save findings to the problem file, re-score WSJF, and re-run the work selection to let the user pick from the updated queue
+- Option 3: `Pick a different problem` — park this one and work something else
+- Use `header: "Scope change"` and `multiSelect: false`
+
 **In both cases:** After completing work on one problem, run `problem work` again to pick up the next highest-WSJF problem. Keep going until the user says stop or no more problems are actionable.
 
 ## Steps
@@ -239,7 +245,7 @@ Read `RISK-POLICY.md` to get the current impact levels (1-5), likelihood levels
     - Update the Status field to "Known Error"
     - This happens automatically — do not ask the user
 
-**Step 9c: Present summary**
+**Step 9c: Present summary and select problem to work**
 
 After reviewing all problems, present a WSJF-ranked table:
 
@@ -253,6 +259,18 @@ Highlight:
 - Problems that have been fixed but not closed (check git history for fix commits)
 - Known errors with a `## Fix Released` section (pending user verification)
 
+**When the operation is `work` (not just `review`), select the problem to work using `AskUserQuestion`:**
+
+- If one problem has a strictly higher WSJF than all others, present it as the recommended option:
+  - Option 1: `Work P<NNN>: <title> (Recommended)` — with description showing WSJF score and status
+  - Option 2: `Pick a different problem` — let the user name a specific ID
+- If two or more problems tie for the highest WSJF, present the tied problems as options:
+  - One option per tied problem: `Work P<NNN>: <title>` — with description showing WSJF and a one-line rationale for why this one
+  - Final option: `Pick a different problem`
+- Use `header: "Next problem"` and `multiSelect: false`
+
+**Never present the selection as prose "(a)/(b)/(c)" or "which would you like?"** — always use `AskUserQuestion` so the decision is structured and auditable.
+
 **Step 9d: Check for pending verifications**
 
 For each known-error that has a `## Fix Released` section, use `AskUserQuestion` to ask the user if the fix has been verified in production. If the user confirms, close the problem (`git mv` to `.closed.md`, update Status). If the user says no or is unsure, leave it as known-error.