prizmkit 1.1.80 → 1.1.82

package/bundled/skills/refactor-pipeline-launcher/references/configuration.md

@@ -52,3 +52,37 @@ Not exposed in interactive menu, pass via `--env`:
 | `opencli` not installed | Browser verification skipped for opencli refactors (non-blocking). Install opencli for Chrome session-based browser verification |
 | Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/refactor/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
 | Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-refactor-daemon.sh .prizmkit/dev-pipeline/run-refactor.sh` |
+
+## Advanced Configuration Round
+
+Only run this when the user answered "Yes" to the **Advanced config?** question in step 6. It applies to a minority of sessions.
+
+Ask a second round of `AskUserQuestion` with these 4 questions:
+
+**Question 1 — Session timeout** (multiSelect: false):
+- None (default) — No timeout
+- 30 min — `SESSION_TIMEOUT=1800`
+- 1 hour — `SESSION_TIMEOUT=3600`
+- 2 hours — `SESSION_TIMEOUT=7200`
+
+**Question 2 — Stop on failure** (multiSelect: false):
+- Off (default) — Pipeline continues to next task after failure
+- On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
+
+**Question 3 — Critic review** (multiSelect: false):
+- Off (default) — Skip adversarial review
+- On — Enable adversarial critic review: an independent AI agent reviews the refactor plan for completeness and the implementation for regressions, missed edge cases, and behavior violations. Adds ~5-10 min per refactor task.
+
+**Question 4 — Deploy after completion?** (multiSelect: false):
+- No (default) — Skip deployment after pipeline completes
+- Yes — Run /prizmkit-deploy automatically after all refactors complete successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any refactor did not complete successfully (status not 'completed' or manually 'skipped').
+
+Then ask about reasoning effort in a follow-up `AskUserQuestion` call:
+
+**Question — Reasoning effort** (multiSelect: false):
+- Default (none) — Use CLI default
+- low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+- medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+- high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+- xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+- max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)

package/bundled/skills/refactor-planner/SKILL.md

@@ -78,7 +78,7 @@ Do NOT use this skill when the user wants to:
    - Read `${SKILL_DIR}/references/behavior-preservation.md` for preservation strategy selection
 
 4. **Load on-demand references when triggered**:
-   - Validation errors or interrupted session -> read error recovery patterns (similar to feature-planner)
+   - Validation errors or interrupted session -> see the "Error Recovery & Resume" section below
 
 5. **Always validate output via script**:
    - Run:
@@ -268,8 +268,6 @@ See `${SKILL_DIR}/references/planning-phases.md` for the full 5-step review chec
 | **CP-RP-5** | Completeness OK | DAG valid, preservation strategies declared, no gaps | 6 |
 | **CP-RP-6** | Output Valid | `.prizmkit/plans/refactor-list.json` passes validation script | 7 |
 
-**Resume Detection**: If existing artifacts found (partial `.prizmkit/plans/refactor-list.json`, draft `refactor-list.draft.json` in `.prizmkit/plans/`), offer to resume from the appropriate checkpoint.
-
 ## Output Rules
 
 `.prizmkit/plans/refactor-list.json` must satisfy:
@@ -337,6 +335,8 @@ Key behaviors:
 
 ### Resume Detection
 
+If existing artifacts are found, offer to resume from the appropriate checkpoint/phase:
+
 | Artifact Found | Resume From |
 |---------------|------------|
 | Nothing | Phase 1: Project Context |
@@ -344,18 +344,16 @@ Key behaviors:
 | Partial `.prizmkit/plans/refactor-list.json` | Phase 6: Completeness Review |
 | Valid `.prizmkit/plans/refactor-list.json` | Mode D: Summary |
 
-## Session Exit Gate
+### Session Exit Gate
 
 Prevent accidental session exit without deliverable completion.
 
-### Trigger Conditions
-Activate exit gate when ALL are true:
+**Trigger conditions** — activate the exit gate when ALL are true:
 - User invoked `/refactor-planner` (not just mentioned refactoring)
 - Current phase < Phase 7 (validation not yet passed)
 - No valid `.prizmkit/plans/refactor-list.json` has been written in this session
 
-### Gate Behavior
-When the session appears to be ending:
+**Gate behavior** — when the session appears to be ending:
 1. **Remind**: "You set out to produce `.prizmkit/plans/refactor-list.json` but we haven't completed it yet."
 2. **Offer 3 options**:
    - **(a) Continue to completion** — resume from current phase

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

@@ -26,39 +26,12 @@ User says:
 
 ## Overview
 
-```
-refactor-workflow <target / goals>
-   │
-   ├── Phase 1: Brainstorm → clarify type → collect materials → parallel deep read → discuss plan
-   │
-   ├── Phase 2: Plan → refactor-planner → .prizmkit/plans/refactor-list.json
-   │
-   ├── Phase 3: Launch → refactor-pipeline-launcher → pipeline execution
-   │
-   └── Phase 4: Monitor → track progress → report results
-```
-
-### What This Skill Does
-
-| Phase | Action | Result |
-|-------|--------|--------|
-| 1 | **Brainstorm** — clarify type, collect reference materials, parallel deep read code & docs, discuss plan grounded in real code | Fully clarified refactoring goals |
-| 2 | Call `refactor-planner` with clarified goals | `.prizmkit/plans/refactor-list.json` with N refactor items |
-| 3 | Call `refactor-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
-| 4 | Monitor progress | Status updates, completion report |
-
-### Why This Skill Exists
-
-Without this skill, users must:
-1. Figure out all refactoring goals and scope themselves
-2. Invoke `refactor-planner` → wait for .prizmkit/plans/refactor-list.json
-3. Invoke `refactor-pipeline-launcher` → wait for pipeline start
-4. Manually check progress
+Four phases take a rough refactoring idea to verified, behavior-preserving code so the user doesn't have to manually chain planner → launcher → monitoring:
 
-With this skill, users can:
-1. Say "Refactor the auth module to extract shared middleware" with a rough idea
-2. The skill brainstorms to fill in all gaps (scope, risks, behavior contracts)
-3. All planning + execution happens automatically
+1. **Brainstorm** — clarify type, collect reference materials, parallel deep read code & docs, discuss plan grounded in real code → fully clarified refactoring goals
+2. **Plan** — call `refactor-planner` → `.prizmkit/plans/refactor-list.json` with N refactor items
+3. **Launch** — call `refactor-pipeline-launcher` → pipeline started (execution mode chosen by user via launcher)
+4. **Monitor** — track progress → status updates, completion report
 
 ### Branch Management
 
@@ -80,21 +53,9 @@ Natural language description of the refactoring goals. Can be:
 
 Flow: brainstorm → refactor-planner → refactor-pipeline-launcher → monitor
 
-**Mode B: From existing .prizmkit/plans/refactor-list.json**
+**Mode B: From existing `.prizmkit/plans/refactor-list.json`** — user says "run pipeline from existing file", or the file already exists. Skip ahead per the [Resume table](#resume--interruption-recovery).
 
-When user says "run pipeline from existing file" or .prizmkit/plans/refactor-list.json already exists:
-- Skip brainstorm and `refactor-planner` (file already exists)
-- Invoke `refactor-pipeline-launcher` directly
-- Monitor and report progress
-
-**Mode C: Incremental (add to existing refactor plan)**
-
-When user says "add more refactors" or the project already has a .prizmkit/plans/refactor-list.json:
-- Brainstorm new refactoring goals with the user
-- Invoke `refactor-planner` in incremental mode (reads existing .prizmkit/plans/refactor-list.json)
-- Append new refactor items to existing list
-- Invoke `refactor-pipeline-launcher`
-- Monitor and report progress
+**Mode C: Incremental (add to existing refactor plan)** — user says "add more refactors". Brainstorm new goals, then invoke `refactor-planner` in incremental mode (appends to existing list) → launch → monitor.
 
 ---
 
@@ -176,28 +137,6 @@ After confirming refactoring goals, assess whether this refactor needs the full
 - Existing tests fully cover the affected code paths
 - No risk of behavior change
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
-
-```
-AskUserQuestion:
-  question: "This refactoring appears straightforward. How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Refactor now (fast path)"
-      description: "Plan and refactor directly in this session using /prizmkit-plan + /prizmkit-implement"
-    - label: "Add to refactor list (pipeline)"
-      description: "Generate .prizmkit/plans/refactor-list.json via refactor-planner, then launch pipeline for autonomous execution"
-```
-
-- **Refactor now** → Fast Path Workflow:
-  1. Invoke `/prizmkit-plan` with the refactoring goals → generates `spec.md` + `plan.md`
-  2. Invoke `/prizmkit-implement` to execute the plan (behavior preservation verified by tests)
-  3. After implementation, run `/prizmkit-code-review` for quality check
-  4. Commit via `/prizmkit-committer` with `refactor(<scope>):` prefix
-  5. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
-  6. **End workflow** — skip Phase 2/3/4
-- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline)
-
 **Complex refactor → Planning Path** (ANY is true):
 - Cross-module impact (>2 modules affected)
 - Public API or interface changes required
@@ -206,21 +145,21 @@ AskUserQuestion:
 - Insufficient test coverage in target area (risk of hidden behavior changes)
 - Requires coordination with other ongoing work
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
+**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options. Tailor the question text to the assessment ("This refactoring appears straightforward…" for simple, "This refactoring is complex and will benefit from structured planning…" for complex), but the two options are always the same:
 
 ```
 AskUserQuestion:
-  question: "This refactoring is complex and will benefit from structured planning. How would you like to proceed?"
+  question: <tailored to simple vs complex assessment>
   header: "Approach"
   options:
-    - label: "Plan and refactor now"
-      description: "Create a plan and refactor in this session using /prizmkit-plan + /prizmkit-implement"
+    - label: "Refactor now (fast path)"
+      description: "Plan and refactor directly in this session using /prizmkit-plan + /prizmkit-implement"
     - label: "Add to refactor list (pipeline)"
       description: "Generate .prizmkit/plans/refactor-list.json via refactor-planner, then launch pipeline for autonomous execution"
 ```
 
-- **Plan and refactor now** → Invoke `/prizmkit-plan` with goals → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-committer` → `/prizmkit-retrospective`. **End workflow** — skip Phase 2/3/4.
-- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline)
+- **Refactor now** → Fast Path: `/prizmkit-plan` (goals → `spec.md` + `plan.md`) → `/prizmkit-implement` (behavior preservation verified by tests) → `/prizmkit-code-review` → `/prizmkit-committer` (`refactor(<scope>):` prefix) → `/prizmkit-retrospective` (sync `.prizmkit/prizm-docs/`). **End workflow** — skip Phase 2/3/4.
+- **Add to refactor list** → Continue to Phase 2 (Plan via pipeline).
 
 **NEVER proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 
@@ -251,7 +190,7 @@ AskUserQuestion:
 
 **CHECKPOINT CP-RW-1**: `.prizmkit/plans/refactor-list.json` generated and validated.
 
-**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
+**If `.prizmkit/plans/refactor-list.json` already exists or user says `--from <file>`**: skip ahead per the [Resume table](#resume--interruption-recovery).
 
 ---
 

package/bundled/skills-windows/app-planner/SKILL.md

@@ -12,7 +12,7 @@ Plan an application from idea to actionable project context through interactive
 - Architecture decision capture
 - Project brief accumulation (`.prizmkit/plans/project-brief.md`)
 
-This skill captures **project-level context only**: vision, tech stack, conventions, architecture decisions, and project brief. It does NOT do feature decomposition or generate `feature-list.json` — that is `feature-planner`'s job.
+This skill captures **project-level context only**: vision, tech stack, conventions, architecture decisions, and project brief. It does not do feature decomposition. (See **Scope Boundary** for the authoritative output rules.)
 
 For adding features to an **existing** project that already has a project brief, use `feature-planner` directly.
 
@@ -56,14 +56,7 @@ If you believe the task is better suited for a different workflow, you MUST:
 
 ## When to Use
 
-Trigger this skill for requests like:
-- "Plan an app", "Design a project", "Design a new application"
-- "Start from scratch", "Build something new", "Create a new product"
-- "Help me figure out what to build", "Brainstorm an app idea"
-- "What tech stack should I use?", "Help me choose frameworks"
-- "Create a project brief for my existing project"
-- "Help me document what this project is about"
-- "I have a codebase but no project plan yet"
+The skill `description` lists the trigger phrases. Beyond those, use this section to disambiguate from `feature-planner` and other workflows.
 
 Do NOT use this skill when:
 - The user already has a project brief and wants to add features → use `feature-planner`

package/bundled/skills-windows/app-planner/references/rules/backend/derivation-rules.md

@@ -4,6 +4,16 @@
 
 ---
 
+## Table of Contents
+
+- [Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)](#phase-2-answer-direct-fill-table-copy-user-answer-text-directly-into-placeholders)
+- [Trigger Map](#trigger-map)
+- [Rule Block Definitions](#rule-block-definitions)
+- [Template Placeholder Coverage Self-Check](#template-placeholder-coverage-self-check)
+
+---
+
+
 ## Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)
 
 | Template Placeholder | Source | Example Fill |

package/bundled/skills-windows/app-planner/references/rules/database/derivation-rules.md

@@ -4,6 +4,15 @@
 
 ---
 
+## Table of Contents
+
+- [Phase 2 Answer Direct-Fill Table](#phase-2-answer-direct-fill-table)
+- [Trigger Map](#trigger-map)
+- [Rule Block Definitions](#rule-block-definitions)
+
+---
+
+
 ## Phase 2 Answer Direct-Fill Table
 
 | Template Placeholder | Source | Example Fill |

package/bundled/skills-windows/app-planner/references/rules/frontend/derivation-rules.md

@@ -6,6 +6,16 @@
 
 ---
 
+## Table of Contents
+
+- [Phase 2 Answer Direct-Fill Table (no derivation needed; copy the user's answer text directly into the placeholder)](#phase-2-answer-direct-fill-table-no-derivation-needed-copy-the-users-answer-text-directly-into-the-placeholder)
+- [Trigger Map](#trigger-map)
+- [Rule Block Definitions](#rule-block-definitions)
+- [Template Placeholder Coverage Self-Check Table (Mandatory Check Before Phase 4 Rendering)](#template-placeholder-coverage-self-check-table-mandatory-check-before-phase-4-rendering)
+
+---
+
+
 ## Phase 2 Answer Direct-Fill Table (no derivation needed; copy the user's answer text directly into the placeholder)
 
 > These placeholders **don't need rule blocks**. In Phase 4, the AI directly writes the answers collected in Phase 2 into them.

package/bundled/skills-windows/app-planner/references/rules/frontend/question-bank.md

@@ -6,6 +6,23 @@
 
 ---
 
+## Table of Contents
+
+- [Asking Rules](#asking-rules)
+- [Group Overview](#group-overview)
+- [G1 — Tech Stack](#g1--tech-stack)
+- [G2 — Styling](#g2--styling)
+- [G3 — State & Data Fetching](#g3--state--data-fetching)
+- [G4 — Design System](#g4--design-system)
+- [G5 — Responsive & Adaptation](#g5--responsive--adaptation)
+- [G6 — i18n & Accessibility](#g6--i18n--accessibility)
+- [G7 — Testing & Quality](#g7--testing--quality)
+- [G8 — AI Vibecoding Constraints](#g8--ai-vibecoding-constraints)
+- [G9 — Performance Baseline](#g9--performance-baseline)
+
+---
+
+
 ## Asking Rules
 
 1. **Group order**: G1 → G2 → G3 → G4 → G5 → G6 → G7 → G8 → G9. Do not skip.

package/bundled/skills-windows/app-planner/references/rules/frontend/template.md

@@ -13,6 +13,25 @@
 
 ---
 
+## Table of Contents
+
+- [0. TL;DR — Key Decisions at a Glance](#0-tldr--key-decisions-at-a-glance)
+- [1. Design System](#1-design-system)
+- [2. Engineering Architecture](#2-engineering-architecture)
+- [3. Code Quality (Non-Negotiable)](#3-code-quality-non-negotiable)
+- [4. State & Data](#4-state--data)
+- [5. User Experience](#5-user-experience)
+- [6. Testing & Quality Assurance](#6-testing--quality-assurance)
+- [7. AI Vibecoding Behavior Constraints](#7-ai-vibecoding-behavior-constraints)
+- [8. Collaboration Process](#8-collaboration-process)
+- [9. Security Baseline](#9-security-baseline)
+- [Appendix A: Deny List (Quick Reference)](#appendix-a-deny-list-quick-reference)
+- [Appendix B: Recommended Libraries & Tools](#appendix-b-recommended-libraries--tools)
+- [Appendix C: References](#appendix-c-references)
+
+---
+
+
 ## 0. TL;DR — Key Decisions at a Glance
 
 | Dimension | Decision |

package/bundled/skills-windows/app-planner/references/rules/mobile/derivation-rules.md

@@ -4,6 +4,16 @@
 
 ---
 
+## Table of Contents
+
+- [Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)](#phase-2-answer-direct-fill-table-copy-user-answer-text-directly-into-placeholders)
+- [Trigger Map](#trigger-map)
+- [Rule Block Definitions](#rule-block-definitions)
+- [Template Placeholder Coverage Self-Check](#template-placeholder-coverage-self-check)
+
+---
+
+
 ## Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)
 
 | Template Placeholder | Source | Example Fill |

package/bundled/skills-windows/bug-fix-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "bug-fix-workflow"
-description: "Interactive single-bug fix in current session. Guides through deep diagnosis Q&A → triage → reproduce → fix → review → commit without the background pipeline. Use this skill when the user wants to fix one specific bug right now, interactively. Trigger on: 'fix this bug', 'debug this', 'fix B-001', 'help me fix', 'let me fix this bug myself', 'fix this bug', 'interactive fix', 'manually fix bug'."
+description: "Interactive single-bug fix in current session. Guides through deep diagnosis Q&A → triage → reproduce → fix → review → commit without the background pipeline. Use this skill when the user wants to fix one specific bug right now, interactively. Trigger on: 'fix this bug', 'debug this', 'fix B-001', 'help me fix', 'let me fix this bug myself', 'interactive fix', 'manually fix bug'."
 ---
 
 # Bug Fix Workflow
@@ -10,7 +10,6 @@ Fix a single bug interactively within the current AI CLI session. This is the in
 ## When to Use
 
 - User wants to fix **one specific bug** right now, with full visibility
-- User says "fix this bug", "debug this error", "help me fix B-001", "fix this bug"
 - User has a stack trace or error and wants interactive debugging
 - User prefers hands-on fixing over background pipeline
 
@@ -121,12 +120,7 @@ Ask the user: "Is this summary accurate? Any details to add?"
 
 After confirming bug understanding, assess whether this bug needs structured planning:
 
-**Simple bug → Fast Path candidate** (ALL must be true):
-- Root cause is immediately obvious (typo, missing null check, wrong variable name, off-by-one)
-- Fix is ≤10 lines of code in a single file
-- No cross-module impact
-- Existing tests cover the affected path (or bug is in untested utility)
-- No data model or API changes
+**Simple bug → Fast Path candidate**: meets ALL of the Fast Path §Eligibility Criteria (obvious root cause, ≤10 lines, single file, no cross-module impact, no data/API changes).
 
 **User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
 
@@ -320,28 +314,28 @@ If user reports the fix is NOT working:
 
 The workflow supports resuming from the last completed phase by detecting existing artifacts.
 
-**Detection logic**: Check `.prizmkit/bugfix/<BUG_ID>/` and git branch state:
+**Detection logic**: Resume from git branch state plus, for the complex "Plan and fix now" path, the planning docs under `.prizmkit/bugfix/<BUG_ID>/`:
 
-| Artifact Found | Resume From |
+| State Found | Resume From |
 |---------------|------------|
-| (nothing) | Phase 0: Branch Setup |
-| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis |
-| `fix-plan.md` only | Phase 4: Fix |
-| `fix-plan.md` + code changes exist | Phase 5: Review |
-| All docs + review passed | Phase 6: User Verification |
-| All docs + committed | Phase 7: Merge decision |
+| Not on a `fix/<BUG_ID>-*` branch | Phase 0: Branch Setup |
+| On `fix/<BUG_ID>-*` branch, no diagnosis done | Phase 1: Deep Bug Diagnosis |
+| `spec.md` + `plan.md` exist, no code changes | Phase 4: Fix (complex path) |
+| Reproduction test written, fix not yet green | Phase 4: Fix |
+| Fix code + passing tests, not yet reviewed | Phase 5: Review |
+| Review passed, not committed | Phase 6: User Verification |
+| Committed on fix branch | Phase 7: Merge decision |
 
-**Resume**: If `<BUG_ID>` matches an existing `.prizmkit/bugfix/<BUG_ID>/` directory, resume instead of starting fresh.
+**Resume**: If a `fix/<BUG_ID>-*` branch already exists (and, for the complex path, a matching `.prizmkit/bugfix/<BUG_ID>/` directory), resume from the detected state instead of starting fresh.
 
 ---
 
 ## Artifacts
 
-Bug fix artifacts are stored at `.prizmkit/bugfix/<BUG_ID>/`:
-- `fix-plan.md` — Triage output (diagnosis, root cause, fix approach)
-- `fix-report.md` — Post-fix summary (what changed, test results, TRAPS added)
+This workflow favors code + tests over documents — a bug fix is an incomplete feature, not new architecture worth heavy documentation. What gets produced depends on the path taken:
 
-Only 2 artifact files per bug, consistent with the pipeline convention.
+- **Fast path / interactive path** (Phase 2–7): no markdown artifacts. Output is the fix code, a reproduction test, and a git commit on the fix branch. Diagnosis and triage are presented inline to the user, not written to disk.
+- **Complex "Plan and fix now" path**: `/prizmkit-plan` writes `spec.md` (bug description + acceptance criteria) and `plan.md` (fix strategy + test specs) under `.prizmkit/bugfix/<BUG_ID>/`. These are the only persisted documents, and they double as resume anchors.
 
 ## Comparison with Pipeline Bug Fix
 
@@ -354,7 +348,7 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 | Visibility | Full user interaction at each phase | Async, check status periodically |
 | User verification | Yes (Phase 6) | No (automated) |
 | Best for | Complex bugs needing user input | Batch of well-defined bugs |
-| Artifacts | Same (fix-plan.md + fix-report.md) | Same |
+| Artifacts | Code + test (+ spec/plan on complex path) | Pipeline-managed |
 | Commit prefix | `fix(<scope>):` | `fix(<scope>):` |
 
 ## Error Handling
@@ -381,6 +375,5 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 ## Output
 
 - Fixed code with reproduction test
-- `.prizmkit/bugfix/<BUG_ID>/fix-plan.md`
-- `.prizmkit/bugfix/<BUG_ID>/fix-report.md`
+- On the complex path only: `.prizmkit/bugfix/<BUG_ID>/spec.md` + `plan.md`
 - Git commit with `fix(<scope>):` prefix on dedicated fix branch

package/bundled/skills-windows/bug-fix-workflow/references/bug-diagnosis.md

@@ -35,32 +35,7 @@ Ask questions across these dimensions until every aspect is clear. **Adapt to wh
 - Server-side logs?
 - Network request/response details?
 
-## Complexity Assessment
-
-### Simple bug → Fast Path candidate (ALL must be true)
-- Root cause is immediately obvious (typo, missing null check, wrong variable name, off-by-one)
-- Fix is ≤10 lines of code in a single file
-- No cross-module impact
-- Existing tests cover the affected path (or bug is in untested utility)
-- No data model or API changes
-
-### Complex bug → Planning Path (ANY is true)
-- Cross-module impact (>2 files affected)
-- Data model or API changes required
-- Root cause is uncertain or multi-layered
-- Fix requires structural changes
-- Multiple interrelated symptoms
-
-## Comparison with Pipeline Bug Fix
-
-| Dimension | bug-fix-workflow | bugfix-pipeline-launcher |
-|-----------|-------------------|----------------------------|
-| Scope | One bug at a time | All bugs in batch |
-| Execution | Interactive, in-session | Foreground or background daemon |
-| Diagnosis | Deep interactive Q&A with user | Automated from bug description |
-| Branch | Creates `fix/<BUG_ID>-*` branch | Pipeline manages branches |
-| Visibility | Full user interaction at each phase | Async, check status periodically |
-| User verification | Yes (Phase 6) | No (automated) |
-| Best for | Complex bugs needing user input | Batch of well-defined bugs |
-| Artifacts | Same (fix-plan.md + fix-report.md) | Same |
-| Commit prefix | `fix(<scope>):` | `fix(<scope>):` |
+> Complexity assessment (simple vs complex routing) and the comparison with the
+> background pipeline live in the skill body (§Step 1.4 and §Comparison with
+> Pipeline Bug Fix) — they are flow-control decisions, kept here only by pointer
+> to avoid drift.

package/bundled/skills-windows/bug-planner/SKILL.md

@@ -51,10 +51,8 @@ When the user provides detailed specifications, rules, or implementation require
    - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
 
 ## When to Use
-- "plan bug fixes", "report bugs", "create bug list"
-- "generate bug list", "I have some bugs to fix"
-- "these tests are failing", "here's an error log", "parse these errors"
-- After receiving bug reports, error logs, or failed test output
+
+The `description` frontmatter declares the trigger phrases for this skill. Beyond those:
 
 **Do NOT use when:**
 - User wants to start fixing bugs now → use `bugfix-pipeline-launcher`
@@ -63,15 +61,15 @@ When the user provides detailed specifications, rules, or implementation require
 
 ## Intent Routing
 
-This skill handles multiple operations. Determine the user's intent and execute the matching operation:
+This skill handles multiple operations. Determine the user's intent and dispatch to the matching operation section below — each operation's authoritative trigger phrases live in its own **Operation:** section.
 
-| User Intent | Operation | Trigger Phrases |
-|---|---|---|
-| Plan bugs interactively | **Interactive Planning** | "plan bug fixes", "report bugs" |
-| Parse error logs into bugs | **From Log** | "parse this error log", "here's a stack trace", "parse these errors" |
-| Parse test failures into bugs | **From Tests** | "these tests are failing", "parse test output" |
-| Validate existing bug list | **Validate** | "validate bug list", "check .prizmkit/plans/bug-fix-list.json" |
-| Summarize bug list | **Summary** | "bug summary", "show bug list", "list bugs" |
+| User Intent | Operation Section |
+|---|---|
+| Plan bugs interactively | **Operation: Interactive Planning** |
+| Parse error logs into bugs | **Operation: From Log** |
+| Parse test failures into bugs | **Operation: From Tests** |
+| Validate existing bug list | **Operation: Validate** |
+| Summarize bug list | **Operation: Summary** |
 
 ## PowerShell Python Helper
 
@@ -126,6 +124,8 @@ Actions:
 
 ## Operation: Interactive Planning
 
+Triggers: "plan bug fixes", "report bugs".
+
 Launch the interactive bug planning process through 5 phases.
 
 ### Phase 1: Project Context
@@ -289,6 +289,8 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 
 ## Operation: From Log
 
+Triggers: "parse this error log", "here's a stack trace", "parse these errors".
+
 Batch-parse error logs to generate bug entries without interactive prompts:
 
 1. Accept log file path or piped content
@@ -309,6 +311,8 @@ Batch-parse error logs to generate bug entries without interactive prompts:
 
 ## Operation: From Tests
 
+Triggers: "these tests are failing", "parse test output".
+
 Batch-parse failed test output:
 
 1. Accept test runner output (Jest, pytest, Go test, etc.)
@@ -323,6 +327,8 @@ Batch-parse failed test output:
 
 ## Operation: Validate
 
+Triggers: "validate bug list", "check .prizmkit/plans/bug-fix-list.json".
+
 Validate existing `.prizmkit/plans/bug-fix-list.json`:
 
 1. Check JSON syntax
@@ -336,6 +342,8 @@ Validate existing `.prizmkit/plans/bug-fix-list.json`:
 
 ## Operation: Summary
 
+Triggers: "bug summary", "show bug list", "list bugs".
+
 Print human-readable summary:
 
 ```