prizmkit 1.1.80 → 1.1.81

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:
 
 ```

package/bundled/skills-windows/bugfix-pipeline-launcher/SKILL.md

@@ -137,73 +137,15 @@ Detect user intent from their message, then follow the corresponding workflow:
      --action status
    ```
 
-4. **Ask execution mode** (first user decision — SEPARATE `AskUserQuestion` call):
+4. **Ask execution mode** (first user decision — SEPARATE `AskUserQuestion` call with exactly 1 question):
 
-   ⛔ **This MUST be its own standalone `AskUserQuestion` call.** Do NOT combine execution mode with step 5 config questions. The execution mode question is asked ALONE, user responds, THEN you proceed to step 5.
+   Present the three execution modes from the **Execution Mode** section above (Foreground / Background daemon / Manual), multiSelect: false. Then STOP and wait for the user's response before continuing to step 5.
 
-   Use `AskUserQuestion` with exactly 1 question:
+5. **Ask configuration options** — applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 4.
 
-   **Question 1 — Execution mode** (multiSelect: false):
-   - Foreground (Recommended) — pipeline runs in the current session via `run-bugfix.ps1 run`. Visible output and direct error feedback.
-   - Background daemon — pipeline runs fully detached via `launch-bugfix-daemon.ps1`. Survives AI CLI session closure.
-   - Manual — display the final assembled commands only. Do not execute anything. User runs them on their own.
+   RULE: Execution mode (step 4) and configuration (step 5) are two distinct `AskUserQuestion` calls, asked in order, each followed by waiting for the user's answer. Merging them, assuming defaults, or showing the final command before the user has answered both rounds produces a misconfigured pipeline that runs autonomously for a long time — so it MUST NOT happen. If you find yourself writing the final command before the user has answered, STOP.
 
-   ⚠️ STOP HERE and wait for user response before continuing to step 5.
-
-5. **Ask configuration options** ⚠️ MANDATORY INTERACTIVE STEP — applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 4. You MUST ask the user to configure options and WAIT for their response BEFORE proceeding to step 6.
-
-   ⛔ **HARD STOP**: You MUST call `AskUserQuestion` with the 4 questions below and WAIT for the user's response. You MUST NOT:
-   - Combine step 4 and step 5 into one `AskUserQuestion` call (this is the most common violation — execution mode MUST be asked separately in step 4)
-   - Skip this step and jump to the next step
-   - Merge this step and the next step into one response
-   - Assume default values and show the command without asking
-   - Show the command as text and ask "ready?" without presenting the options
-   If you find yourself writing the final command before the user has answered these 4 questions, STOP — you are violating this rule.
-
-   Use `AskUserQuestion` to present ALL 4 configuration choices (the full 4-question budget goes to config, NOT shared with execution mode):
-
-   **Question 1 — Verbose logging** (multiSelect: false):
-   - On (default) — Detailed AI session logs including tool calls and subagent activity
-   - Off — Minimal logging
-
-   **Question 2 — Max retries** (multiSelect: false):
-   - 3 (default)
-   - 1
-   - 5
-
-   **Question 3 — Critic review** (multiSelect: false):
-   - Off (default) — Skip adversarial review
-   - On — Enable adversarial critic review: an independent AI agent reviews the diagnosis/plan for completeness and the fix for defects, edge cases, and regression risks. Adds ~5-10 min per bug.
-
-   **Question 4 — Advanced config?** (multiSelect: false):
-   - No (default) — Use defaults for session timeout and failure behavior
-   - Yes — Configure session timeout, stop-on-failure, and reasoning effort options
-
-   Note: Bug filter defaults to all bugs (by severity order). Default Critic to Off unless bugs have `severity: "critical"` or `severity: "high"` (in which case default to On). If the user selects "Other" on any option, handle their custom input.
-
-   **If user chose "Yes" to Advanced config**, ask a second round of `AskUserQuestion`:
-
-   **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 — 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`)
-
-   **Environment variable mapping** and **advanced environment variables** tables — read `${SKILL_DIR}/references/configuration.md` for the full translation tables (8 config→env mappings + 8 advanced variables).
-
-   ⚠️ STOP HERE and wait for user response before continuing to step 6.
+   The step-5 questions (4 round-1 questions, plus a round 2 if the user picks "Yes" to Advanced config) and their env-var mappings are enumerated in `${SKILL_DIR}/references/configuration.md` under "Interactive Configuration Options". Present round 1 as one `AskUserQuestion` call; run round 2 only if Advanced config = Yes. Then STOP and wait for the user's response before continuing to step 6.
 
 6. **Show final command**: Assemble the complete command from execution mode + confirmed configuration, and present it to the user.
 

package/bundled/skills-windows/bugfix-pipeline-launcher/references/configuration.md

@@ -11,7 +11,7 @@ Translating user responses to env vars:
 | Verbose: Off | `VERBOSE=0` |
 | Verbose: On | `VERBOSE=1` |
 | Max retries: N | `MAX_RETRIES=N` |
-| Critic: On | `ENABLE_CRITIC=true` |
+| Critic: On | `ENABLE_CRITIC=1` |
 | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
 | Stop on failure: On | `STOP_ON_FAILURE=1` |
 | Deploy: Yes | `ENABLE_DEPLOY=1` |
@@ -32,6 +32,51 @@ Not exposed in interactive menu, pass via `--env`:
 | `LOG_RETENTION_DAYS` | `14` | Delete logs older than N days |
 | `LOG_MAX_TOTAL_MB` | `1024` | Keep total logs under N MB via oldest-first cleanup |
 
+## Interactive Configuration Options
+
+Present these via `AskUserQuestion` in step 5. Round 1 is one `AskUserQuestion` call with all 4 questions; round 2 only runs if the user picks "Yes" to Advanced config.
+
+### Round 1 (always asked)
+
+**Question 1 — Verbose logging** (multiSelect: false):
+- On (default) — Detailed AI session logs including tool calls and subagent activity
+- Off — Minimal logging
+
+**Question 2 — Max retries** (multiSelect: false):
+- 3 (default)
+- 1
+- 5
+
+**Question 3 — Critic review** (multiSelect: false):
+- Off (default) — Skip adversarial review (`ENABLE_CRITIC=0`)
+- On — Enable adversarial critic review (`ENABLE_CRITIC=1`): an independent AI agent reviews the diagnosis/plan for completeness and the fix for defects, edge cases, and regression risks. Adds ~5-10 min per bug.
+
+**Question 4 — Advanced config?** (multiSelect: false):
+- No (default) — Use defaults for session timeout and failure behavior
+- Yes — Configure session timeout, stop-on-failure, and reasoning effort options
+
+Note: Bug filter defaults to all bugs (by severity order). Default Critic to Off unless bugs have `severity: "critical"` or `severity: "high"` (in which case default to On). If the user selects "Other" on any option, handle their custom input.
+
+### Round 2 (only if Advanced config = Yes)
+
+**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 — 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`)
+
 ## Error Handling
 
 | Error | Action |