prizmkit 1.1.79 → 1.1.81

package/bundled/skills-windows/prizmkit-retrospective/SKILL.md

@@ -27,7 +27,7 @@ For initial doc setup, validation, or migration, use `/prizmkit-prizm-docs` inst
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing spec.md, plan.md, review-report.md. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a `plan.md`. If no artifact directory found, run in standalone mode (structural sync only from `git diff`). |
+| `artifact_dir` | No | Directory containing spec.md, plan.md, review-report.md. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a `plan.md`. When invoked as a handoff step, reuse the caller's `artifact_dir` rather than re-detecting. If no artifact directory found, run in standalone mode (structural sync only from `git diff`). |
 
 ## When NOT to Use
 

package/bundled/skills-windows/prizmkit-retrospective/references/structural-sync-steps.md

@@ -36,7 +36,7 @@ git diff HEAD --name-status
 **1g. TRAPS staleness check** (only when an L2 doc's TRAPS section has > 10 entries):
 
 Perform a quick staleness scan on existing TRAPS to prevent unbounded accumulation:
-1. If a TRAP has `STALE_IF:` and the glob-matched files no longer exist (verified via `Get-ChildItem`) → delete the TRAP entry
+1. If a TRAP has `STALE_IF:` and the glob-matched files no longer exist (verified via `ls`) → delete the TRAP entry
 2. If a TRAP has `REF:` → check if the referenced file still exists and the REF commit is less than 180 days old (via `git log --since="180 days ago" <hash> 2>$null`). If the file is deleted OR the REF commit is older than 180 days → prepend `[REVIEW]` to the severity, signaling it needs verification during the next retrospective Job 2
 3. Process at most 5 of the oldest TRAPS per L2 doc per session (to bound context cost)
 

package/bundled/skills-windows/prizmkit-test/SKILL.md

@@ -108,94 +108,11 @@ Compare what exists against what should exist, across three levels:
 
 ### Phase 4: Generate Missing Tests
 
-Generate tests in priority order: unit → integration → E2E. After each batch, run immediately.
-
-When generated tests fail, distinguish two cases:
-- **Test bug** (syntax error, wrong import, wrong mock, wrong framework API usage) → fix the test and re-run
-- **Assertion failure** (test is valid but code returns unexpected result) → mark as "needs review" in report; do NOT modify production code. This is a potential bug discovered by the generated test.
-
-If a test fails repeatedly after 2 fix attempts, skip it and mark as "unresolved" in the report.
-
-**4a. Unit Tests (always applicable)**
-
-For each uncovered interface:
-- Read the source file to understand function signature and logic
-- Generate test file matching project conventions (framework, naming, directory, import style, mock/fixture patterns)
-- Common naming patterns to match:
-  - `src/foo.ts` → `src/__tests__/foo.test.ts` or `src/foo.spec.ts` or `tests/foo_test.py`
-  - Mirror the existing pattern; if no tests exist, use the framework's default convention
-- Cover: happy path, edge cases (null/undefined/empty), error conditions, boundary values
-- Do NOT test framework internals or third-party library behavior
-- Run tests immediately after generating
-
-**4b. Integration Tests**
-
-For each module with dependencies:
-- Generate tests for the module's primary interface exercising its real dependencies
-- If API endpoints exist: request/response tests (valid input, invalid input, missing params, auth)
-- If database operations exist: CRUD tests using the project's existing test database config
-- Run tests immediately after generating
-
-**4c. E2E Tests (conditional)**
-
-Preconditions (ALL must be met):
-- Playwright is available (`@playwright/test` or `playwright` in package.json dependencies, or `npx playwright --version` succeeds as fallback)
-- Playwright browsers are installed (check `npx playwright install --dry-run 2>/dev/null` exits cleanly, or `node_modules/.cache/ms-playwright/` directory exists; if missing, warn in report and skip E2E)
-- Project has a UI layer
-- Project can be started (start/dev script in package.json)
-- Acceptance criteria exist in spec.md files
-
-If ALL met:
-- **Before starting dev server**: detect whether it's already running: (1) check `package.json` scripts for port flags (`--port`, `-p`, `PORT=`), (2) fall back to framework defaults (3000 for React/Next/Express, 5173 for Vite, 8000 for Django, 5000 for Flask), (3) if still unknown, ask the user. Use the detected port in `lsof -i :<port>` to check. If running, tell user: "Dev server appears to be already running on port {N}. Use this running instance for E2E tests?" If user confirms, use existing instance. If user declines, skip E2E.
-- Start the project dev server (only if not already running). Wait for it to be ready.
-- For each uncovered acceptance criterion, generate a Playwright test script
-- Run generated E2E tests, capture screenshots of failures
-- **Only stop dev server if you started it.** Never stop a server that was already running.
-
-If NOT met:
-- Note what was skipped and why in the report
-- If only the server wasn't startable: still generate E2E script files but mark as "not run — manual execution needed"
+Read `${SKILL_DIR}/references/test-generation-steps.md` for the detailed generation procedure — priority order (unit → integration → E2E), failure handling rules, and generation patterns for each test level.
 
 ### Phase 5: Unified Report
 
-Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` directory.
-
-**test-report.md** format:
-
-```markdown
-# Test Report — {timestamp}
-
-## Summary
-- Scope: {full / module: name / feature: ###-name}
-- Architecture: {frontend / backend / fullstack}
-- Test framework: {name}
-- Mode: {interactive / headless}
-
-## Existing Tests
-- Total: {N} | Passed: {N} | Failed: {N}
-{failed test details or "All passing"}
-{or "No existing tests found — generated first batch"}
-
-## Coverage Gaps Found
-| Module | Interface | Type | Status |
-|--------|-----------|------|--------|
-| ... | ... | unit/integration/e2e | covered / generated / needs-review / unresolved / skipped |
-
-## Generated Tests
-- Unit: {N} generated, {N} needs-review, {N} unresolved
-- Integration: {N} generated, {N} needs-review, {N} unresolved
-- E2E: {N} generated, {N} skipped ({reason})
-
-## Final Status
-- All tests passing: {yes / no}
-- Needs human review: {list of tests marked needs-review}
-{remaining failures if any}
-```
-
-Also save:
-- `existing-test-output.txt` — raw output from Phase 2
-- `generated-tests/` — copies of all generated test files
-- `e2e-output/` — E2E logs and failure screenshots (if applicable)
+Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` directory. Read `${SKILL_DIR}/references/test-report-template.md` for the full report format and artifact list.
 
 ## Output
 
@@ -211,71 +128,6 @@ If the session is interrupted:
 
 ## Examples
 
-### Example 1: Full-Project Quality Check with Test Generation
-
-**User**: `/prizmkit-test`
-
-**Phase 0 — Architecture Detection**:
-```
-Detected: Fullstack (React + Express)
-Test framework: Vitest (7 existing test files)
-```
-
-**Phase 1 — Scope Selection** (user selects option 1):
-```
-Scope: Full project (all modules, all specs)
-```
-
-**Phase 2 — Existing Tests**: 7 test files found, 20 tests run, 18 passed, 2 pre-existing failures (recorded, not fixed).
-
-**Phase 3 — Gap Analysis** (excerpt):
-| Module | Interface | Type | Status |
-|--------|-----------|------|--------|
-| auth | login() | unit | missing |
-| auth | register() | unit | missing |
-| payment | processPayment() | unit | missing |
-| payment | api/checkout | integration | missing |
-| — | Checkout flow | e2e | missing |
-
-**Phase 4**: Generated 5 unit tests (3 passing, 2 assertion failures marked "needs-review"), 1 integration test (passing), 1 E2E test (passing).
-
-**Phase 5 — Report Summary**:
-```
-Generated: 5 unit (2 needs-review), 1 integration, 1 E2E
-Report: .prizmkit/test/2026_05_23_14_30_00_testresult/test-report.md
-Needs human review: processPayment (returns 400 for negative amounts, expected 422), refund (missing authorization header causes 500 instead of 401)
-```
-
-### Example 2: Single-Feature Targeted Test
-
-**User**: `/prizmkit-test`
-
-**Phase 0 — Architecture Detection**:
-```
-Detected: Backend (Express)
-Test framework: Vitest
-```
-
-**Phase 1 — Scope Selection** (user selects option 3, then picks "042-payment-gateway"):
-```
-Scope: Single feature — 042-payment-gateway
-Test files in scope: 2
-
-**Phase 2 — Existing Tests**: 2 test files, 8 tests, all passing.
-
-**Phase 3 — Gap Analysis** (excerpt):
-| Module | Interface | Type | Status |
-|--------|-----------|------|--------|
-| payment | processPayment() | unit | missing |
-| payment | refund() | unit | missing |
-
-**Phase 4**: Generated 2 unit tests (both passing). No integration/E2E applicable for this scope.
-
-**Phase 5 — Report Summary**:
-```
-Generated: 2 unit tests (all passing)
-Report: .prizmkit/test/2026_05_23_15_00_00_testresult/test-report.md
-All tests passing. Ready for commit.
-```
+Read `${SKILL_DIR}/references/examples.md` for worked examples of full-project and single-feature test runs.
 
 **HANDOFF:** Independent skill — no handoff. User may proceed to `/prizmkit-committer` if all tests pass, or fix issues manually if tests are marked "needs-review".

package/bundled/skills-windows/prizmkit-test/references/examples.md

@@ -0,0 +1,70 @@
+# Test Examples
+
+## Example 1: Full-Project Quality Check with Test Generation
+
+**User**: `/prizmkit-test`
+
+**Phase 0 — Architecture Detection**:
+```
+Detected: Fullstack (React + Express)
+Test framework: Vitest (7 existing test files)
+```
+
+**Phase 1 — Scope Selection** (user selects option 1):
+```
+Scope: Full project (all modules, all specs)
+```
+
+**Phase 2 — Existing Tests**: 7 test files found, 20 tests run, 18 passed, 2 pre-existing failures (recorded, not fixed).
+
+**Phase 3 — Gap Analysis** (excerpt):
+| Module | Interface | Type | Status |
+|--------|-----------|------|--------|
+| auth | login() | unit | missing |
+| auth | register() | unit | missing |
+| payment | processPayment() | unit | missing |
+| payment | api/checkout | integration | missing |
+| — | Checkout flow | e2e | missing |
+
+**Phase 4**: Generated 5 unit tests (3 passing, 2 assertion failures marked "needs-review"), 1 integration test (passing), 1 E2E test (passing).
+
+**Phase 5 — Report Summary**:
+```
+Generated: 5 unit (2 needs-review), 1 integration, 1 E2E
+Report: .prizmkit/test/2026_05_23_14_30_00_testresult/test-report.md
+Needs human review: processPayment (returns 400 for negative amounts, expected 422), refund (missing authorization header causes 500 instead of 401)
+```
+
+## Example 2: Single-Feature Targeted Test
+
+**User**: `/prizmkit-test`
+
+**Phase 0 — Architecture Detection**:
+```
+Detected: Backend (Express)
+Test framework: Vitest
+```
+
+**Phase 1 — Scope Selection** (user selects option 3, then picks "042-payment-gateway"):
+```
+Scope: Single feature — 042-payment-gateway
+Test files in scope: 2
+
+**Phase 2 — Existing Tests**: 2 test files, 8 tests, all passing.
+
+**Phase 3 — Gap Analysis** (excerpt):
+| Module | Interface | Type | Status |
+|--------|-----------|------|--------|
+| payment | processPayment() | unit | missing |
+| payment | refund() | unit | missing |
+
+**Phase 4**: Generated 2 unit tests (both passing). No integration/E2E applicable for this scope.
+
+**Phase 5 — Report Summary**:
+```
+Generated: 2 unit tests (all passing)
+Report: .prizmkit/test/2026_05_23_15_00_00_testresult/test-report.md
+All tests passing. Ready for commit.
+```
+
+**HANDOFF**: Independent skill — no handoff. User may proceed to `/prizmkit-committer` if all tests pass, or fix issues manually if tests are marked "needs-review".

package/bundled/skills-windows/prizmkit-test/references/test-generation-steps.md

@@ -0,0 +1,49 @@
+# Test Generation Steps (Phase 4)
+
+Generate tests in priority order: unit → integration → E2E. After each batch, run immediately.
+
+When generated tests fail, distinguish two cases:
+- **Test bug** (syntax error, wrong import, wrong mock, wrong framework API usage) → fix the test and re-run
+- **Assertion failure** (test is valid but code returns unexpected result) → mark as "needs review" in report; do NOT modify production code. This is a potential bug discovered by the generated test.
+
+If a test fails repeatedly after 2 fix attempts, skip it and mark as "unresolved" in the report.
+
+## 4a. Unit Tests (always applicable)
+
+For each uncovered interface:
+- Read the source file to understand function signature and logic
+- Generate test file matching project conventions (framework, naming, directory, import style, mock/fixture patterns)
+- Common naming patterns to match:
+  - `src/foo.ts` → `src/__tests__/foo.test.ts` or `src/foo.spec.ts` or `tests/foo_test.py`
+  - Mirror the existing pattern; if no tests exist, use the framework's default convention
+- Cover: happy path, edge cases (null/undefined/empty), error conditions, boundary values
+- Do NOT test framework internals or third-party library behavior
+- Run tests immediately after generating
+
+## 4b. Integration Tests
+
+For each module with dependencies:
+- Generate tests for the module's primary interface exercising its real dependencies
+- If API endpoints exist: request/response tests (valid input, invalid input, missing params, auth)
+- If database operations exist: CRUD tests using the project's existing test database config
+- Run tests immediately after generating
+
+## 4c. E2E Tests (conditional)
+
+Preconditions (ALL must be met):
+- Playwright is available (`@playwright/test` or `playwright` in package.json dependencies, or `npx playwright --version` succeeds as fallback)
+- Playwright browsers are installed (check `npx playwright install --dry-run 2>/dev/null` exits cleanly, or `node_modules/.cache/ms-playwright/` directory exists; if missing, warn in report and skip E2E)
+- Project has a UI layer
+- Project can be started (start/dev script in package.json)
+- Acceptance criteria exist in spec.md files
+
+If ALL met:
+- **Before starting dev server**: detect whether it's already running: (1) check `package.json` scripts for port flags (`--port`, `-p`, `PORT=`), (2) fall back to framework defaults (3000 for React/Next/Express, 5173 for Vite, 8000 for Django, 5000 for Flask), (3) if still unknown, ask the user. Use the detected port in `lsof -i :<port>` to check. If running, tell user: "Dev server appears to be already running on port {N}. Use this running instance for E2E tests?" If user confirms, use existing instance. If user declines, skip E2E.
+- Start the project dev server (only if not already running). Wait for it to be ready.
+- For each uncovered acceptance criterion, generate a Playwright test script
+- Run generated E2E tests, capture screenshots of failure.
+- **Only stop dev server if you started it.** Never stop a server that was already running.
+
+If NOT met:
+- Note what was skipped and why in the report
+- If only the server wasn't startable: still generate E2E script files but mark as "not run — manual execution needed"

package/bundled/skills-windows/prizmkit-test/references/test-report-template.md

@@ -0,0 +1,42 @@
+# Test Report Output Template
+
+Used in Phase 5 of `/prizmkit-test`. Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` directory and write `test-report.md`.
+
+## test-report.md Format
+
+```markdown
+# Test Report — {timestamp}
+
+## Summary
+- Scope: {full / module: name / feature: ###-name}
+- Architecture: {frontend / backend / fullstack}
+- Test framework: {name}
+- Mode: {interactive / headless}
+
+## Existing Tests
+- Total: {N} | Passed: {N} | Failed: {N}
+{failed test details or "All passing"}
+{or "No existing tests found — generated first batch"}
+
+## Coverage Gaps Found
+| Module | Interface | Type | Status |
+|--------|-----------|------|--------|
+| ... | ... | unit/integration/e2e | covered / generated / needs-review / unresolved / skipped |
+
+## Generated Tests
+- Unit: {N} generated, {N} needs-review, {N} unresolved
+- Integration: {N} generated, {N} needs-review, {N} unresolved
+- E2E: {N} generated, {N} skipped ({reason})
+
+## Final Status
+- All tests passing: {yes / no}
+- Needs human review: {list of tests marked needs-review}
+{remaining failures if any}
+```
+
+## Artifacts
+
+Also save alongside `test-report.md`:
+- `existing-test-output.txt` — raw output from Phase 2
+- `generated-tests/` — copies of all generated test files
+- `e2e-output/` — E2E logs and failure screenshots (if applicable)

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

@@ -55,30 +55,24 @@ Pipeline commands (for reference — Phase 1.3 will present these as a selectabl
 
 ## Overview
 
-```
-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: Diagnose + report + user choice
-  │   ├── Check branch and working tree state
-  │   ├── Scan all pipelines for failed/in-progress tasks
-  │   ├── Find residual dev branches from failed tasks
-  │   ├── Display diagnosis + detection results
-  │   ├── If code changes exist → run test suite
-  │   ├── If multiple failed tasks → ask user which to recover
-  │   └── User chooses: run-recovery.ps1 (recommended) | interactive | start fresh
-  │
-  └── Phase 2: Execute remaining steps
-      ├── Read target workflow's SKILL.md
-      ├── Read existing artifacts to restore context
-      └── Execute from inferred phase through completion
-```
+1. **Phase 0: Auto-detect**
+   1. Read current branch name
+   2. Scan characteristic artifacts
+   3. Match workflow signature → determine workflow type
+   4. Based on artifact presence → infer current phase
+   5. No match → reject and guide user
+2. **Phase 1: Diagnose + report + user choice**
+   1. Check branch and working tree state
+   2. Scan all pipelines for failed/in-progress tasks
+   3. Find residual dev branches from failed tasks
+   4. Display diagnosis + detection results
+   5. If code changes exist → run test suite
+   6. If multiple failed tasks → ask user which to recover
+   7. User chooses: run-recovery.ps1 (recommended) | interactive | start fresh
+3. **Phase 2: Execute remaining steps**
+   1. Read target workflow's SKILL.md
+   2. Read existing artifacts to restore context
+   3. Execute from inferred phase through completion
 
 ---
 
@@ -86,58 +80,7 @@ recovery-workflow
 
 **Goal**: Identify which workflow was interrupted and what phase it reached.
 
-Run the detection script:
-
-```powershell
-function Invoke-PrizmPython {
-  param([Parameter(ValueFromRemainingArguments = $true)][string[]]$Arguments)
-  $python = Get-Command python -ErrorAction SilentlyContinue
-  if ($python) {
-    & $python.Source -c 'import sys; raise SystemExit(0 if sys.version_info[0] == 3 else 1)' *> $null
-    if ($LASTEXITCODE -eq 0) {
-      & $python.Source @Arguments
-      return
-    }
-  }
-  $py = Get-Command py -ErrorAction SilentlyContinue
-  if ($py) {
-    & $py.Source -3 -c 'import sys; raise SystemExit(0 if sys.version_info[0] == 3 else 1)' *> $null
-    if ($LASTEXITCODE -eq 0) {
-      & $py.Source -3 @Arguments
-      return
-    }
-  }
-  throw "Python 3 is required. Install Python and ensure python or py is in PATH."
-}
-Invoke-PrizmPython ${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. .prizmkit/plans/refactor-list.json exists               → refactor-workflow
-5. Current branch matches feat/*           → feature-workflow
-6. .prizmkit/plans/feature-list.json exists                → feature-workflow
-7. None of the above                       → no workflow detected
-```
-
-Bug-fix-workflow has highest priority because it is purely interactive and benefits most from recovery (no pipeline retry fallback).
-
-### If no workflow detected
-
-Show guidance and exit:
-
-```
-No interrupted workflow detected in this workspace.
-
-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
-```
+Run the detection script (`Invoke-PrizmPython ${SKILL_DIR}/scripts/detect-recovery-state.py`). For the full signature matching table, phase inference tables (bug-fix/feature/refactor), and no-workflow-detected guidance, read `${SKILL_DIR}/references/detection.md`.
 
 **CHECKPOINT CP-REC-0**: Workflow type and phase identified.
 
@@ -341,53 +284,19 @@ This step replaces the context that was lost when the AI session was interrupted
 
 ---
 
-### 2.1 Bug-Fix-Workflow Recovery
+### 2.1 Per-Workflow Phase Inference
 
-Phase inference table:
+Read `${SKILL_DIR}/references/detection.md` for the per-workflow phase-inference tables (bug-fix / feature / refactor) that map detected state → the phase to resume from and its actions.
 
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis | Read bug description from `.prizmkit/plans/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 |
-
-**Note**: Bug-fix Phases 1-3 (Diagnosis, Triage, Reproduce) collapse to Phase 1 for detection purposes because these phases don't produce persistent artifacts. If interrupted during these phases, recovery restarts from Phase 1 (diagnosis), which re-derives understanding from available inputs (bug description, code) without interactive Q&A.
-
-**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.
+**Bug-fix execution**: Follow the bug-fix-workflow SKILL.md instructions exactly. Call the same prizmkit sub-commands (`/prizmkit-code-review`, `/prizmkit-committer`) at the same points.
 
 **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.
 
----
-
-### 2.2 Feature-Workflow Recovery
+**Feature recovery**: Phases 3-4 are pipeline-driven. The main recovery value is avoiding re-brainstorming (Phase 1) when `.prizmkit/plans/feature-list.json` already exists.
 
-Phase inference table:
-
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| No `.prizmkit/plans/feature-list.json` | Phase 1: Brainstorm | Cannot recover conversation context. Start requirement clarification, but leverage any workspace content (README, existing code) for context |
-| `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `feature-pipeline-launcher` to start the pipeline |
-| `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status via `feature-pipeline-launcher` (Intent B: Check Status) |
-
-**Note**: Feature-workflow recovery is simpler because Phases 3-4 are pipeline-driven. The main recovery value is avoiding re-brainstorming (Phase 1) when `.prizmkit/plans/feature-list.json` already exists.
-
----
-
-### 2.3 Refactor-Workflow Recovery
-
-Phase inference table (mirrors feature-workflow):
-
-| Detected State | Resume From | Actions |
-|---------------|------------|---------|
-| No `.prizmkit/plans/refactor-list.json` | Phase 1: Brainstorm | Start refactoring goal clarification |
-| `.prizmkit/plans/refactor-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `refactor-pipeline-launcher` to start the pipeline |
-| `.prizmkit/plans/refactor-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status |
-
----
+**Refactor recovery**: Mirrors feature-workflow (brainstorm → launch → monitor).
 
 ### 2.4 Post-Recovery Report
 
@@ -439,16 +348,6 @@ Recovery complete.
 
 ---
 
-## Comparison with Previous Version
-
-| 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
 
 - Resumed and completed workflow from the breakpoint

package/bundled/skills-windows/recovery-workflow/references/detection.md

@@ -0,0 +1,58 @@
+# Recovery Phase Detection
+
+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. .prizmkit/plans/refactor-list.json exists               → refactor-workflow
+5. Current branch matches feat/*           → feature-workflow
+6. .prizmkit/plans/feature-list.json exists                → feature-workflow
+7. None of the above                       → no workflow detected
+```
+
+Bug-fix-workflow has highest priority because it is purely interactive and benefits most from recovery (no pipeline retry fallback).
+
+## If No Workflow Detected
+
+Show guidance and exit:
+
+```
+No interrupted workflow detected in this workspace.
+
+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
+```
+
+## Phase Inference Tables
+
+### Bug-Fix-Workflow Recovery
+
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis | Read bug description from `.prizmkit/plans/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 |
+
+Note: Bug-fix Phases 1-3 (Diagnosis, Triage, Reproduce) collapse to Phase 1 because they don't produce persistent artifacts. If interrupted during these phases, recovery restarts from Phase 1.
+
+### Feature-Workflow Recovery
+
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| No `.prizmkit/plans/feature-list.json` | Phase 1: Brainstorm | Cannot recover conversation context. Start requirement clarification, leverage workspace content |
+| `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `feature-pipeline-launcher` |
+| `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status via `feature-pipeline-launcher` (Intent B) |
+
+### Refactor-Workflow Recovery
+
+| Detected State | Resume From | Actions |
+|---------------|------------|---------|
+| No `.prizmkit/plans/refactor-list.json` | Phase 1: Brainstorm | Start refactoring goal clarification |
+| `.prizmkit/plans/refactor-list.json` exists, no pipeline state | Phase 3: Launch | Invoke `refactor-pipeline-launcher` |
+| `.prizmkit/plans/refactor-list.json` + pipeline state exists | Phase 4: Monitor | Check pipeline status |