prizmkit 1.1.1 → 1.1.4

package/bundled/skills/recovery-workflow/SKILL.md

@@ -1,378 +1,237 @@
 ---
 name: "recovery-workflow"
-description: "Recover and resume interrupted feature pipeline sessions. Detects partial work (code changes, spec/plan artifacts, branch state, test results) from failed or interrupted sessions and intelligently resumes from the correct phase — instead of discarding everything and restarting from scratch. Use this skill whenever a pipeline session fails mid-execution, times out, gets interrupted, or when the user wants to salvage partial work from a failed feature. Trigger on: 'recover feature', 'resume session', 'continue from where it stopped', 'salvage partial work', 'fix failed feature', 'session interrupted', 'recover F-XXX', 'resume F-XXX', 'continue F-XXX', 'feature stuck', 'pick up where it left off', 'session timed out', 'don't want to restart from scratch', 'token limit exceeded'. (project)"
+description: "Recover and resume interrupted interactive workflow sessions. Auto-detects which workflow (feature-workflow, bug-fix-workflow, refactor-workflow) was interrupted and what phase it reached by inspecting git branch names, characteristic artifacts, and pipeline state — then resumes from the breakpoint. Use this skill whenever an AI CLI session is interrupted mid-workflow, times out, or hits token limits. Trigger on: 'recover', 'resume', 'continue where I left off', 'session interrupted', 'session timed out', 'pick up where it left off', 'token limit exceeded', 'salvage partial work'. (project)"
 ---
 
 # Recovery Workflow
 
-Intelligently recover and resume interrupted feature pipeline sessions. Instead of discarding partial work and restarting from scratch (which wastes tokens and time), this skill inspects the actual filesystem state — code changes, artifacts, git branches, test results — and continues from the right point.
+Auto-detect and resume interrupted interactive workflow sessions. When a user's AI CLI session is interrupted mid-workflow (timeout, token limit, crash, manual stop), this skill inspects the workspace to determine which workflow was running and what phase it reached, then continues from the breakpoint.
 
 ## When to Use
 
 User says:
-- "Recover F-007", "Resume F-007", "Continue F-007 from where it stopped"
-- "Feature session failed/timed out, salvage the work"
-- "Pipeline interrupted, don't want to restart from scratch"
-- "F-003 is stuck, pick up where it left off"
-- "Session timed out but there's code already written"
+- "Recover", "Resume", "Continue where I left off"
+- "Session interrupted / timed out / token limit exceeded"
+- "Pick up where it left off"
+- "Don't want to restart from scratch"
 
 **Do NOT use when:**
-- User wants a clean retry from scratch → `retry-feature.sh` or `reset-feature.sh --clean --run`
-- Pipeline is still running normally → `dev-pipeline-launcher` (Intent B: Check Status)
-- User wants to fix a specific bug → `bug-fix-workflow`
-- Feature never started (no state at all) → `dev-pipeline-launcher` (Intent E: Retry)
+- Pipeline interrupted → use `retry-feature.sh` / `retry-bugfix.sh`
+- User wants a clean restart → use the original workflow skill directly (`/feature-workflow`, `/bug-fix-workflow`, `/refactor-workflow`)
+- Nothing was ever started → use the original workflow skill
 
-## Why This Skill Exists
+## Supported Workflows
 
-Current retry tools have a fundamental limitation:
-
-| Tool | What it does | What's lost |
-|------|-------------|-------------|
-| `retry-feature.sh` | Cleans all artifacts, resets status, spawns fresh session | All code changes, spec, plan — everything |
-| `reset-feature.sh --clean --run` | Even more thorough clean + retry | Same, plus session history |
-| `run.sh --resume-phase N` | Tells new session "start from phase N" via prompt | Better, but doesn't inspect actual worktree state — the new AI session has no memory of what was done |
-
-The gap: when a session is interrupted mid-implementation, the **worktree already has real code changes** — possibly a spec, plan, partial or complete implementation, even passing tests. Discarding all of this wastes significant tokens and time. This skill bridges that gap by inspecting the actual filesystem state and resuming intelligently within the current interactive session.
+| Workflow | Branch Pattern | Key Artifacts |
+|----------|---------------|---------------|
+| bug-fix-workflow | `fix/<BUG_ID>-*` | `.prizmkit/bugfix/<BUG_ID>/fix-plan.md`, `fix-report.md` |
+| feature-workflow | `feat/*` | `feature-list.json`, `dev-pipeline/state/features/` |
+| refactor-workflow | `refactor/*` | `refactor-list.json`, `dev-pipeline/state/refactors/` |
 
 ---
 
 ## Overview
 
 ```
-recovery-workflow <feature-id>
-   │
-   ├── Phase 0: Identify feature and gather context
-   │
-   ├── Phase 1: Detect state (artifacts, code, tests, branch)
-   │
-   ├── Phase 2: Diagnose and present recovery options
-   │
-   └── Phase 3: Execute recovery (chain remaining prizmkit skills)
+recovery-workflow
+  │
+  ├── Phase 0: Auto-detect
+  │   ├── Read current branch name
+  │   ├── Scan characteristic artifacts
+  │   ├── Match workflow signature → determine workflow type
+  │   ├── Based on artifact presence → infer current phase
+  │   └── No match → reject and guide user
+  │
+  ├── Phase 1: Report + user confirmation
+  │   ├── Display detection results
+  │   ├── If code changes exist → run test suite
+  │   └── User confirms "continue" → proceed
+  │
+  └── Phase 2: Execute remaining steps
+      ├── Read target workflow's SKILL.md
+      ├── Read existing artifacts to restore context
+      └── Execute from inferred phase through completion
 ```
 
-## Input
+---
 
-| Input | Required | Example |
-|-------|----------|---------|
-| Feature ID | Yes | `F-007` |
-| Feature list path | No (default: `feature-list.json`) | `my-features.json` |
+## Phase 0: Auto-detect
 
----
+**Goal**: Identify which workflow was interrupted and what phase it reached.
+
+Run the detection script:
 
-## Phase 0: Feature Identification
-
-**Goal**: Locate the feature and its context.
-
-1. **Parse feature ID** from user input (e.g., "recover F-007", "resume F-007")
-2. **Read feature-list.json** to get feature metadata:
-   ```bash
-   python3 -c "
-   import json, re
-   with open('feature-list.json') as f:
-       data = json.load(f)
-   for feat in data.get('features', []):
-       if feat.get('id') == 'F-007':
-           print(json.dumps(feat, indent=2))
-   "
-   ```
-3. **Compute feature slug** (same algorithm the pipeline uses):
-   ```python
-   # F-007 + "User Authentication" → "007-user-authentication"
-   numeric = feature_id.replace('F-', '').zfill(3)
-   slug = re.sub(r'[^a-z0-9\s-]', '', title.lower())
-   slug = re.sub(r'[\s]+', '-', slug.strip()).strip('-')
-   slug = f"{numeric}-{slug}"
-   ```
-
-If the feature is not found, ask the user for the correct ID or file path.
+```bash
+python3 ${SKILL_DIR}/scripts/detect-recovery-state.py
+```
 
----
+The script uses **priority-ordered signature matching**:
+
+```
+1. Current branch matches fix/*           → bug-fix-workflow
+2. .prizmkit/bugfix/ directory has content → bug-fix-workflow
+3. Current branch matches refactor/*       → refactor-workflow
+4. refactor-list.json exists               → refactor-workflow
+5. Current branch matches feat/*           → feature-workflow
+6. feature-list.json exists                → feature-workflow
+7. None of the above                       → no workflow detected
+```
 
-## Phase 1: State Detection
+Bug-fix-workflow has highest priority because it is purely interactive and benefits most from recovery (no pipeline retry fallback).
 
-**Goal**: Build a complete picture of what exists from the interrupted session.
+### If no workflow detected
 
-Run the detection script:
+Show guidance and exit:
 
-```bash
-python3 ${SKILL_DIR}/scripts/detect-recovery-state.py \
-  --feature-id <FEATURE_ID> \
-  --feature-list feature-list.json
 ```
+No interrupted workflow detected in this workspace.
 
-The script scans four categories of state and outputs structured JSON:
-
-### 1.1 Pipeline State
-- `dev-pipeline/state/features/{FEATURE_ID}/status.json` — pipeline tracking status, retry count, session history
-- Last session directory — path for log inspection
-
-### 1.2 PrizmKit Artifacts
-- `.prizmkit/specs/{slug}/spec.md` — specification generated?
-- `.prizmkit/specs/{slug}/plan.md` — plan generated?
-- If plan.md exists: count completed vs total tasks (look for `[x]` vs `[ ]` checkboxes)
-
-### 1.3 Git State
-- **Feature branch**: does `feat/{slug}` exist?
-- **Current branch**: are we already on the feature branch?
-- **Uncommitted changes**: `git diff --stat` (working tree changes)
-- **Staged changes**: `git diff --cached --stat`
-- **Commits ahead of main**: `git log main..HEAD --oneline`
-
-### 1.4 Code Changes
-- Number of modified/added/deleted files
-- Which directories were touched
-- Whether test files were created/modified
-
-### Detection Output
-
-The script produces a structured JSON report:
-
-```json
-{
-  "feature_id": "F-007",
-  "feature_title": "User Authentication",
-  "feature_slug": "007-user-authentication",
-  "pipeline": {
-    "status": "failed",
-    "retry_count": 1,
-    "last_session_id": "F-007-20260329101500",
-    "last_session_dir": "dev-pipeline/state/features/F-007/sessions/F-007-20260329101500"
-  },
-  "artifacts": {
-    "spec_exists": true,
-    "plan_exists": true,
-    "spec_path": ".prizmkit/specs/007-user-authentication/spec.md",
-    "plan_path": ".prizmkit/specs/007-user-authentication/plan.md",
-    "plan_tasks_total": 5,
-    "plan_tasks_completed": 3
-  },
-  "git": {
-    "feature_branch": "feat/007-user-authentication",
-    "branch_exists": true,
-    "on_feature_branch": true,
-    "uncommitted_files": 8,
-    "staged_files": 0,
-    "commits_ahead_of_main": 0
-  },
-  "code": {
-    "files_modified": 6,
-    "files_added": 4,
-    "test_files_touched": 2,
-    "directories_touched": ["src/auth/", "src/middleware/", "tests/"]
-  },
-  "recovery": {
-    "recommended_action": "continue_implementation",
-    "recommended_phase": "implement",
-    "reason": "spec and plan exist, 3/5 plan tasks completed, code changes present",
-    "remaining_work": "2 tasks + review + commit"
-  }
-}
+To start a new workflow:
+  • /feature-workflow   — build features from idea to code
+  • /bug-fix-workflow   — fix a specific bug interactively
+  • /refactor-workflow  — behavior-preserving code restructuring
 ```
 
-**CHECKPOINT CP-RW-0**: State detection complete, structured report available.
+**CHECKPOINT CP-RW-0**: Workflow type and phase identified.
 
 ---
 
-## Phase 2: Diagnosis & Recovery Options
+## Phase 1: Report + User Confirmation
 
-**Goal**: Present findings to user and agree on a recovery strategy.
+**Goal**: Show the user what was found and get confirmation before executing.
 
-### 2.1 Present Discovery Summary
+### 1.1 Display Detection Report
 
-Read the detection script output and show the user a clear summary:
+Read the script output and present a formatted summary:
 
 ```
 ═══════════════════════════════════════════════════
-  Recovery Report: F-007 — User Authentication
+  Recovery Report
 ═══════════════════════════════════════════════════
 
-  Pipeline Status:  FAILED (retry 1)
-  Feature Branch:   feat/007-user-authentication
+  Workflow:     bug-fix-workflow
+  Branch:       fix/B-001-login-crash
+  Phase:        5 — Review
 
   Artifacts Found:
-    ✓ spec.md (specification)
-    ✓ plan.md (5 tasks, 3 completed)
-    ✓ Code changes (10 files — 6 modified, 4 new)
-    ✓ Test files (2 found)
+    ✓ fix-plan.md (fix approach documented)
+    ✗ fix-report.md (not yet created)
+    ✓ Code changes (4 files — 3 modified, 1 new)
+    ✓ Test files (1 touched)
 
-  Recommended: Continue implementation
-  Remaining:   2 tasks + review + commit
+  Reason:   fix-plan.md exists + code changes present
+  Remaining: code review → user verification → commit & merge
 ═══════════════════════════════════════════════════
 ```
 
-### 2.2 Run Tests (if code changes exist)
+### 1.2 Run Tests (if code changes exist)
 
-Before presenting options, run the project's test suite to understand the health of existing code:
+If the detection report shows code changes (`code.has_changes == true`), run the project's test suite:
 
 ```bash
-# detect test command from .prizmkit/config.json or package.json
+# detect test command from package.json or .prizmkit/config.json
 npm test   # or the appropriate test command
 ```
 
-Include test results in the summary:
+Include test results in the report:
 - How many tests pass/fail
-- If there are failures — which tests and why
-
-### 2.3 Present Recovery Options
-
-Based on the detected state, offer the appropriate options. The most common scenarios:
-
-**Scenario A: Implementation in progress** (spec + plan + code changes)
-Most common case — session died mid-implementation.
-
-| Option | Description |
-|--------|-------------|
-| **(a) Smart Resume** (recommended) | Fix test failures if any, complete remaining plan tasks, then review → commit |
-| **(b) Review & Commit Only** | If implementation looks complete (all tasks done, tests passing), skip to code review |
-| **(c) Re-implement from Plan** | Keep spec and plan, discard code changes, re-implement. Useful if partial code is low quality |
-| **(d) Clean Restart** | Discard everything, start from scratch (equivalent to `reset-feature.sh --clean --run`) |
-
-**Scenario B: Only planning artifacts** (spec/plan exist, no code changes)
-Session died during or after planning, before implementation started.
-
-| Option | Description |
-|--------|-------------|
-| **(a) Start Implementation** (recommended) | Plan is ready, begin implementing |
-| **(b) Re-plan** | Keep spec, regenerate plan (useful if plan was incomplete or poor) |
-| **(c) Clean Restart** | Discard everything and start over |
+- If failures exist — which tests and why
 
-**Scenario C: Code changes but no artifacts** (git changes, no .prizmkit artifacts)
-Unusual — might be manual work or artifacts were cleaned.
+### 1.3 Ask User to Confirm
 
-| Option | Description |
-|--------|-------------|
-| **(a) Adopt & Continue** | Read existing code, proceed to review + commit |
-| **(b) Clean Restart** | Discard and restart |
-
-**Scenario D: Already committed** (feature branch has commits ahead of main)
-Session completed implementation but didn't finish post-commit steps.
-
-| Option | Description |
-|--------|-------------|
-| **(a) Complete Post-commit** (recommended) | Run code review, retrospective, handle merge |
-| **(b) Clean Restart** | Discard and restart |
-
-**Scenario E: No state found** (no branch, no artifacts, no code)
-Feature was never executed or was fully cleaned.
-
-| Option | Description |
-|--------|-------------|
-| **(a) Run from Scratch** | Suggest using `dev-pipeline-launcher` (Intent E) or `retry-feature.sh` instead |
+```
+Ready to resume from Phase 5 (Review). Continue?
+```
 
-Ask the user to choose. Default to the recommended option.
+If the user declines, suggest alternatives:
+- "Use `/bug-fix-workflow` to start fresh"
+- "Use `/feature-workflow` to start fresh"
+- "Use `/refactor-workflow` to start fresh"
 
-**CHECKPOINT CP-RW-1**: User confirmed recovery strategy.
+**CHECKPOINT CP-RW-1**: User confirmed recovery.
 
 ---
 
-## Phase 3: Execute Recovery
-
-**Goal**: Execute the remaining phases based on the user's chosen strategy.
+## Phase 2: Execute Remaining Steps
 
-### 3.0 Branch Setup
+**Goal**: Read the target workflow's SKILL.md and execute from the inferred phase.
 
-Ensure we're on the right branch:
+### 2.0 Read Target Workflow
 
-```bash
-# If feature branch exists but we're not on it:
-git checkout feat/{slug}
-
-# If no feature branch but code changes are on current branch:
-git checkout -b feat/{slug}
-```
+1. **Read the workflow's SKILL.md** from `core/skills/orchestration-skill/workflows/{workflow-type}/SKILL.md`
+2. **Read existing artifacts** to restore context — check in this order for the most efficient recovery:
+   - If `session-summary.md` exists in the artifact directory → read it first. It provides a lightweight summary of completed tasks, key decisions, active TRAPS, and remaining work from the interrupted session.
+   - Then read remaining artifacts: spec, plan, code diffs, bug descriptions, etc.
+3. **Read relevant `.prizm-docs/`** — load project context (L0 root, relevant L1). If `session-summary.md` was found, use its "Files Changed" section to focus L1/L2 loading on affected modules only.
 
-### 3.1 Read Existing Artifacts
+This step replaces the context that was lost when the AI session was interrupted.
 
-Load the artifacts that were preserved, so we have full context:
-
-1. **Read spec.md** (if exists) — understand what this feature should do
-2. **Read plan.md** (if exists) — understand the implementation plan and task breakdown
-3. **Scan code changes** — `git diff main --stat` to understand what was already done
-4. **Read relevant `.prizm-docs/`** — load project context (L0 root, relevant L1)
-
-This step replaces the Phase 0-2 that the pipeline would have done (project bootstrap, context building, planning). The artifacts serve as memory of the interrupted session.
-
-### 3.2 Fix Existing Test Failures (if any)
+---
 
-If tests are failing from the interrupted session, fix them first. Continuing implementation on top of a broken state compounds errors.
+### 2.1 Bug-Fix-Workflow Recovery
 
-1. Read the test failure output
-2. Read the relevant source files
-3. Apply minimal fixes to make tests pass
-4. Verify: run test suite → all green
+Phase inference table:
 
-If failures cannot be fixed after 3 attempts, ask the user whether to:
-- Continue anyway (if failures are unrelated to this feature)
-- Switch to "Re-implement from Plan" strategy
-- Clean restart
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis | Read bug description from `bug-fix-list.json`. Start interactive diagnosis Q&A |
+| `fix-plan.md` exists, no code changes | Phase 4: Fix | Read fix-plan.md. Implement the fix following the plan |
+| `fix-plan.md` + code changes exist | Phase 5: Review | Invoke `/prizmkit-code-review` on all changes |
+| All docs + review passed | Phase 6: User Verification | Ask user to verify the fix works |
+| All docs + committed | Phase 7: Merge Decision | Ask merge vs keep branch |
 
-### 3.3 Continue Implementation
+**Execution for each remaining phase**: Follow the bug-fix-workflow SKILL.md instructions exactly. Call the same prizmkit sub-commands (`/prizmkit-code-review`, `/prizmkit-committer`) at the same points.
 
-If plan.md exists with incomplete tasks:
+**Special handling**:
+- If resuming from Phase 5 (Review) and tests are failing, fix test failures first (max 3 attempts). If unfixable, ask user whether to continue or restart.
+- If resuming from Phase 4 (Fix), read fix-plan.md to understand the planned approach before writing code.
 
-1. **Read plan.md** and identify remaining tasks — look for unchecked `[ ]` items in the Tasks section
-2. **For each remaining task**:
-   - Read the task description from plan.md
-   - Implement the change following the same approach as `/prizmkit-implement`
-   - Run full test suite after each task
-   - Mark task as complete `[x]` in plan.md
-3. After all tasks complete → full test suite must pass
+---
 
-If no plan.md exists but code changes are present (Scenario C), skip this step — go straight to review.
+### 2.2 Feature-Workflow Recovery
 
-### 3.4 Code Review
+Phase inference table:
 
-Invoke `/prizmkit-code-review` on all changes:
-- Review scope: all files modified/added relative to main branch (`git diff main --stat`)
-- If review returns NEEDS_FIXES → apply fixes, re-review (max 2 rounds)
-- If review returns PASS or PASS_WITH_WARNINGS → proceed
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| No `feature-list.json` | Phase 1: Brainstorm | Cannot recover conversation context. Start requirement clarification, but leverage any workspace content (README, existing code) for context |
+| `feature-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `feature-pipeline-launcher` to start the pipeline |
+| `feature-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status via `feature-pipeline-launcher` (Intent B: Check Status) |
 
-### 3.5 User Verification
+**Note**: Feature-workflow recovery is simpler because Phases 3-4 are pipeline-driven. The main recovery value is avoiding re-brainstorming (Phase 1) when `feature-list.json` already exists.
 
-Ask user: "Implementation recovered and reviewed. Verify before committing?"
-- **(a) Run the app** → suggest and start the dev server
-- **(b) Run a specific command** → execute what the user specifies
-- **(c) Skip** → proceed directly to commit
+---
 
-If user reports issues: return to 3.3 (max 2 additional rounds).
+### 2.3 Refactor-Workflow Recovery
 
-### 3.6 Retrospective & Commit
+Phase inference table (mirrors feature-workflow):
 
-1. **Invoke `/prizmkit-retrospective`** — update `.prizm-docs/` for structural changes caused by this feature
-2. **Invoke `/prizmkit-committer`** — commit with `feat(<scope>): <description>` prefix
-3. **Update pipeline state** — mark feature as completed:
-   ```bash
-   python3 dev-pipeline/scripts/update-feature-status.py \
-     --feature-list feature-list.json \
-     --state-dir dev-pipeline/state \
-     --feature-id <FEATURE_ID> \
-     --action complete
-   ```
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| No `refactor-list.json` | Phase 1: Brainstorm | Start refactoring goal clarification |
+| `refactor-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `refactor-pipeline-launcher` to start the pipeline |
+| `refactor-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status |
 
-### 3.7 Post-Recovery
+---
 
-1. **Ask merge preference**:
-   - (a) Merge to main and delete feature branch
-   - (b) Keep feature branch for PR review
-   - (c) Decide later
+### 2.4 Post-Recovery Report
 
-2. **Report completion**:
-   ```
-   Recovery complete: F-007 — User Authentication
+After all remaining phases complete, output a summary:
 
-   Recovered from: implementation phase (3/5 tasks done)
-   Completed: 2 remaining tasks + test fixes + review + commit
-   Work preserved: spec.md, plan.md, 3 completed tasks
+```
+Recovery complete.
 
-   Next: Check pipeline status for remaining features,
-         or invoke /recovery-workflow for another failed feature.
-   ```
+  Workflow:     bug-fix-workflow
+  Recovered from: Phase 5 (Review)
+  Completed:    code review → user verification → commit & merge
+  Preserved:    fix-plan.md, 4 code files, 1 test file
 
-3. **Suggest next steps**:
-   - If other features are pending/failed → offer to check pipeline status or recover another
-   - If this was the last feature → suggest integration verification
+  Next steps:
+    • Check for other interrupted workflows
+    • Or start a new workflow
+```
 
-**CHECKPOINT CP-RW-2**: Feature recovered, committed, and pipeline state updated.
+**CHECKPOINT CP-RW-2**: Workflow recovered and completed.
 
 ---
 
@@ -380,14 +239,12 @@ If user reports issues: return to 3.3 (max 2 additional rounds).
 
 | Scenario | Action |
 |----------|--------|
-| Feature ID not found in feature-list.json | Ask user for correct ID or file path |
-| No state to recover (never executed) | Inform user, suggest `dev-pipeline-launcher` instead |
-| Feature branch was deleted | Check if changes exist elsewhere; if not, offer clean start |
-| Merge conflicts on feature branch | Show conflicts, help resolve before continuing |
-| Test failures unfixable after 3 attempts | Escalate to user, offer alternative strategies |
-| Code quality too low to salvage | Recommend re-implement from plan |
-| Pipeline state file inconsistent with git | Trust git and filesystem over status.json — git is the ground truth |
-| detection script fails | Fall back to manual detection (Phase 1 checks can be done individually via bash) |
+| No workflow signature matches | Show guidance message, suggest original workflow skills |
+| Branch exists but artifacts are inconsistent | Trust git as ground truth, report discrepancy in detection report |
+| Test failures in existing code | Report in detection summary; user decides whether to continue |
+| Multiple workflows could match (e.g., on main but both feature-list.json and bug-fix artifacts exist) | Pick highest priority (bug-fix > refactor > feature), mention others in report |
+| Detection script fails | Fall back to manual detection (run individual git/file checks in bash) |
+| Bug ID not found in bug-fix-list.json | Continue with branch-only context; note that full bug description is unavailable |
 
 ---
 
@@ -395,34 +252,29 @@ If user reports issues: return to 3.3 (max 2 additional rounds).
 
 | Skill | Relationship |
 |-------|-------------|
-| `dev-pipeline-launcher` | **Upstream** — launcher can suggest this skill when features fail; this skill updates pipeline state after recovery |
-| `retry-feature.sh` | **Alternative** — full clean retry; this skill is the smart alternative |
-| `reset-feature.sh` | **Used by option (d)** — clean restart delegates to reset-feature |
-| `/prizmkit-implement` | **Approach shared in Phase 3.3** — same implementation methodology |
-| `/prizmkit-code-review` | **Called in Phase 3.4** — reviews recovered code |
-| `/prizmkit-committer` | **Called in Phase 3.6** — commits the result |
-| `/prizmkit-retrospective` | **Called in Phase 3.6** — updates .prizm-docs/ |
-| `feature-workflow` | **Sibling** — feature-workflow builds new features; this skill salvages interrupted ones |
+| `feature-workflow` | **Recovery target** — this skill can resume interrupted feature-workflow sessions |
+| `bug-fix-workflow` | **Recovery target** — this skill can resume interrupted bug-fix-workflow sessions |
+| `refactor-workflow` | **Recovery target** — this skill can resume interrupted refactor-workflow sessions |
+| `feature-pipeline-launcher` | **Called in Phase 2.2** — launches or checks pipeline status for feature recovery |
+| `retry-feature.sh` | **Alternative** — full clean retry for pipeline failures; this skill is the smart interactive alternative |
+| `retry-bugfix.sh` | **Alternative** — full clean retry for bugfix pipeline failures |
+| `/prizmkit-code-review` | **Called in Phase 2.1** — reviews recovered bug-fix code |
+| `/prizmkit-committer` | **Called in Phase 2.1** — commits the recovered result |
 
 ---
 
-## Comparison with Existing Recovery Tools
+## Comparison with Previous Version
 
-| Dimension | recovery-workflow | retry-feature.sh | reset + run | run.sh --resume-phase |
-|-----------|------------------|-------------------|-------------|----------------------|
-| State inspection | Deep (git + artifacts + tests) | None | None | None |
-| Preserves code | Yes | No (cleans) | No (cleans) | Prompt-level only |
-| Preserves artifacts | Yes (selective) | No | No | Prompt-level |
-| Runs tests first | Yes | No | No | No |
-| User choice | Multiple strategies | Always clean | Always clean | Fixed phase number |
-| Execution mode | Interactive (in-session) | Spawns new session | Spawns new session | Spawns new session |
-| Token efficiency | High (skips done work) | Low (redo all) | Low (redo all) | Medium |
-| Context continuity | Full (reads existing artifacts) | None (fresh AI session) | None | Partial |
+| Dimension | Previous | Current |
+|-----------|----------|---------|
+| Scope | Feature pipeline only | All 3 interactive workflows |
+| Input | Required `F-XXX` feature ID | No input — fully auto-detect |
+| Detection | Feature-specific (spec/plan/git) | Signature-based (branch + artifacts) |
+| Strategy | Multi-option (5 scenarios × 2-4 options each) | Single path: report → confirm → execute |
+| Intrusion | None | None (zero changes to target workflows) |
 
 ## Output
 
-- Recovered and completed feature implementation
-- Updated pipeline state (feature marked complete)
-- Git commit with `feat(<scope>):` prefix
-- Updated `.prizm-docs/` (via retrospective)
-- Recovery summary showing what was salvaged vs what was re-done
+- Resumed and completed workflow from the breakpoint
+- Same outputs as the original workflow would produce (commits, artifacts, state updates)
+- Recovery summary showing what was preserved vs what was re-done