prizmkit 1.1.79 → 1.1.81

package/bundled/skills-windows/app-planner/references/project-state-detection.md

@@ -0,0 +1,90 @@
+# Project State Detection — Brownfield Behavior
+
+Detailed procedures for detecting and handling existing (brownfield) projects during app planning.
+
+## Detection Signals
+
+| Signal | Greenfield | Brownfield |
+|--------|-----------|------------|
+| `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / `pom.xml` | absent | present |
+| `src/` or `app/` directory with source files | absent | present |
+| `.git` with commit history | absent or initial commit only | present with history |
+| Empty or near-empty directory | yes | no |
+
+## Greenfield Behavior (default)
+
+Proceed with the standard Core Workflow — ask all questions from scratch.
+
+## Brownfield Behavior
+
+When an existing project is detected:
+
+### Step 1: Prerequisite Check (Mandatory)
+
+Before ANY planning work, check if AI-essential project context files exist:
+
+| File | Purpose | Status |
+|------|---------|--------|
+| `.prizmkit/prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
+| `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
+| `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
+
+**If ANY are missing**, show the status table, then use `AskUserQuestion`:
+
+**Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
+- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
+- **Continue without init** — I'll scan the project manually during this session (less thorough)
+- **Skip, I'll set these up later** — proceed with planning using only what's available
+
+- **Run project init first** -> Invoke `prizmkit-init`, then resume app-planner from where it left off
+- **Continue without init** -> Continue with Step 2 below (manual scan)
+- **Skip** -> Continue with Step 3, skip scanning
+
+### Step 2: Proactive Project Scanning
+
+Do NOT ask the user to describe their project — read it yourself first:
+
+1. **Scan project structure** to understand the codebase layout:
+   ```powershell
+   Get-ChildItem -Path . -Directory -Recurse -Depth 2 |
+     Where-Object { $_.FullName -notmatch '\\(node_modules|\.git|dist|build|__pycache__|vendor)(\\|$)' } |
+     ForEach-Object { $_.FullName -replace '[^\\]*\\', '|____' -replace '____\|', ' |' }
+   ```
+
+2. **Read existing project metadata** to infer tech stack and purpose:
+   - `package.json` -> name, description, dependencies, scripts
+   - `pyproject.toml` / `requirements.txt` -> Python dependencies
+   - `go.mod` -> Go module info
+   - `README.md` -> project description and goals
+   - `.prizmkit/config.json` -> previously detected tech stack
+   - `.prizmkit/prizm-docs/root.prizm` -> existing architecture context
+
+3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
+
+### Step 3: Present Inferred Summary with Confirmation
+
+Show the summary as text, then use `AskUserQuestion`:
+
+> Based on my analysis of your codebase:
+>
+> **Project**: [name] — [inferred description]
+> **Tech Stack**: [framework] + [language] + [key dependencies]
+> **Key Features Found**: [list 3-5 detected capabilities]
+> **Architecture**: [e.g., monolithic, microservices, serverless]
+
+**Question**: "Does this look correct?"
+- **Yes, looks correct (Recommended)** — proceed with planning
+- **Mostly correct, with changes** — I'll note corrections
+- **This is off** — let me describe the project
+
+### Step 4: Pre-fill and Focus
+
+- Phase 2 tech stack selection -> largely pre-filled from dependencies
+- Vision/problem statement -> inferred from README or package description (user confirms)
+- Existing features -> note them as `[x]` items in project brief
+
+**Focus remaining questions** (as options where possible) on what CANNOT be inferred:
+- Target users and core value proposition
+- Future direction and planned capabilities
+- Non-functional requirements (performance, scale, security)
+- Design direction (for frontend projects)

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/app-planner/references/rules-configuration.md

@@ -0,0 +1,46 @@
+# Rules Configuration — Detailed Q&A Procedures
+
+Procedural details for configuring per-layer development rules during app planning. SKILL.md retains Steps 1-3 and 5 (flow control); this file contains Step 4's full Q&A workflow.
+
+## Step 4: Configure Each Selected Layer — Full Q&A Workflow
+
+For each selected layer, run the 4-phase rule generation pattern:
+
+### Phase A — Load Layer Resources
+
+- Read `${SKILL_DIR}/references/rules/<layer>/fixed-rules.md` — industry-consensus rules injected without asking
+- Read `${SKILL_DIR}/references/rules/<layer>/question-bank.md` — interactive questions organized in groups (G1->G10): authoritative source for question text, options, "Recommended" markers, and Notes
+- Read `${SKILL_DIR}/references/rules/<layer>/question-manifest.json` — machine-readable structure for this layer. **This is your asking checklist.** It lists, per question: `group`, `required`, `maps_to` (which template placeholders the answer fills), and conditional fields (`required_if`, `auto_derived_when`, `options_vary_by`). Its `groups[]` carries each group's `quick_mode` flag, and `template_placeholders` is the expected-set for the Phase D self-check. Use the manifest to track coverage; use question-bank.md for the actual wording you present to the user. If a question id in one file is absent from the other, trust question-bank.md for content and note the drift.
+
+### Phase B — Interactive Q&A
+
+- Ask questions one group at a time (max 3 questions per message), as defined in question-bank.md
+- Each question shows a "Recommended" option to reduce decision cost
+- **Quick mode**: ask only the groups whose `quick_mode` is `true` in `question-manifest.json`. All other groups adopt recommended defaults silently. (The manifest is the single source of truth for quick-mode membership — do not hardcode group lists here.)
+- **Full mode**: ask all groups in manifest order (`groups[]`).
+- **Conditional questions** (driven by the manifest's per-question fields):
+  - `required_if: "<expr>"` — ask this question only when the expression over prior answers holds (e.g. Q14 `required_if: Q13 != D`). If the condition is false, the question is legitimately skipped — not a coverage gap.
+  - `auto_derived_when: "<expr>"` — when this holds, fill the mapped placeholder(s) from the prior answer without asking (e.g. backend Q6 `auto_derived_when: Q5 in [GraphQL, gRPC]`). Count as satisfied, not skipped.
+  - `options_vary_by: "<Qid>"` — the question is still asked; only its option list depends on that prior answer (e.g. framework/ORM options vary by language). Never affects whether the question is required.
+- Shortcut commands work at any point:
+  - `recommended` / `default` -> adopt all recommended for current group
+  - `all recommended` -> adopt all recommended for all remaining groups
+  - `skip` -> mark current group as "Not required at this stage"
+- Record answers in memory after each group. Track which manifest questions are answered, auto-derived, or conditionally skipped so Phase D can verify coverage.
+
+### Phase C — Auto-derivation
+
+- Read `${SKILL_DIR}/references/rules/<layer>/derivation-rules.md`
+- Match user answers against the trigger map using keyword matching
+- Derive platform-specific rules without asking the user (e.g., choosing Flutter -> auto-inject Flutter widget/persistence/navigation rules)
+
+### Phase D — Render and Write
+
+- Read `${SKILL_DIR}/references/rules/<layer>/template.md`
+- Fill all template placeholders with accumulated content from Phases A+B+C
+- **Post-render self-check** (driven by `question-manifest.json` -> `template_placeholders`):
+  1. **Coverage pass** — for every placeholder in `from_questions`, confirm it traces to an answered question OR an `auto_derived_when` path OR a conditionally-skipped question (`required_if` false). If a `from_questions` placeholder has no source, you skipped a required question — go back and ask it before writing.
+  2. **Residual pass** — scan the rendered document for any residual `{{ ` or ` }}`; count must be 0. Placeholders in `from_fixed_rules` / `auto_generated` / `metadata` are filled from fixed-rules.md, Phase D generation, and project metadata respectively — they are NOT expected to come from Q&A, but they MUST still be rendered (no residual braces).
+- Generate Appendix A (Deny List) and Appendix B (Recommended Tools) per template instructions — these fill the `auto_generated` placeholders
+- Create `.prizmkit/rules/` directory if it doesn't exist
+- Write `.prizmkit/rules/<layer>-rules.md`

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
 
@@ -95,36 +94,7 @@ For trivial bugs with clear root cause and minimal scope:
 
 #### Step 1.2: Systematic Bug Clarification
 
-Ask questions across these dimensions until every aspect is clear. **Adapt to what the user has already provided** — skip questions that are already answered.
-
-**Reproduction Conditions:**
-- What exact steps trigger the bug? (step-by-step)
-- Which environment/browser/OS/version?
-- Is it reproducible every time, or intermittent?
-- When did it first appear? (after a specific change/deploy?)
-- Does it happen for all users or only specific accounts/roles/data?
-
-**Expected vs Actual Behavior:**
-- What should happen? (the correct behavior)
-- What actually happens? (the buggy behavior)
-- Is there partial functionality (e.g., works for some inputs but not others)?
-
-**Scope and Impact:**
-- Which features/pages/modules are affected?
-- Are there workarounds users are currently using?
-- Is this blocking other work?
-- Are there related symptoms elsewhere?
-
-**Data and State:**
-- What data/state triggers the issue? (specific input values, DB state, user session state)
-- Does the bug involve data corruption or just incorrect display/behavior?
-- If database-related: which tables/records are affected?
-
-**Error Details** (if not already provided):
-- Full error message and stack trace?
-- Browser console errors?
-- Server-side logs?
-- Network request/response details?
+Read `${SKILL_DIR}/references/bug-diagnosis.md` for the full question framework — reproduction conditions, expected vs actual behavior, scope/impact, data/state, and error details. Adapt to what the user has already provided; skip answered questions.
 
 #### Step 1.3: Confirmation Before Triage
 
@@ -150,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:
 
@@ -349,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
 
@@ -383,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
@@ -410,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

@@ -0,0 +1,41 @@
+# Bug Diagnosis — Question Framework
+
+Procedural details for systematic bug clarification in bug-fix-workflow Phase 1.
+
+## Step 1.2: Systematic Bug Clarification
+
+Ask questions across these dimensions until every aspect is clear. **Adapt to what the user has already provided** — skip questions that are already answered.
+
+### Reproduction Conditions
+- What exact steps trigger the bug? (step-by-step)
+- Which environment/browser/OS/version?
+- Is it reproducible every time, or intermittent?
+- When did it first appear? (after a specific change/deploy?)
+- Does it happen for all users or only specific accounts/roles/data?
+
+### Expected vs Actual Behavior
+- What should happen? (the correct behavior)
+- What actually happens? (the buggy behavior)
+- Is there partial functionality (e.g., works for some inputs but not others)?
+
+### Scope and Impact
+- Which features/pages/modules are affected?
+- Are there workarounds users are currently using?
+- Is this blocking other work?
+- Are there related symptoms elsewhere?
+
+### Data and State
+- What data/state triggers the issue? (specific input values, DB state, user session state)
+- Does the bug involve data corruption or just incorrect display/behavior?
+- If database-related: which tables/records are affected?
+
+### Error Details (if not already provided)
+- Full error message and stack trace?
+- Browser console errors?
+- Server-side logs?
+- Network request/response details?
+
+> 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,89 +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** (for translating user responses → env vars):
-
-   | Config choice | Environment variable |
-   |-----------|---------------------|
-   | Verbose: Off | `VERBOSE=0` |
-   | Verbose: On | `VERBOSE=1` |
-   | Max retries: N | `MAX_RETRIES=N` |
-   | Critic: On | `ENABLE_CRITIC=true` |
-   | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
-   | Stop on failure: On | `STOP_ON_FAILURE=1` |
-   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
-
-   **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
-
-   | Variable | Default | Purpose |
-   |----------|---------|---------|
-   | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
-
-   ⚠️ 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.
 
@@ -364,18 +290,7 @@ When user says "retry B-001":
 
 ### Error Handling
 
-| Error | Action |
-|-------|--------|
-| `.prizmkit/plans/bug-fix-list.json` not found | Tell user to run `bug-planner` skill first |
-| JSON parsing failed | Use the bundled Python validation/status scripts instead of external JSON tools |
-| AI CLI not in PATH | Check Codex (`codex`), Claude (`claude`), or CodeBuddy (`cbc`) installation |
-| Bugfix pipeline already running | Show status, ask if user wants to stop and restart |
-| PID file stale (process dead) | `launch-bugfix-daemon.ps1` auto-cleans, retry start |
-| Launch failed (process died immediately) | Show last 20 lines of log: `Get-Content -Tail 20 .prizmkit/state/daemon/bugfix-daemon.log` |
-| All bugs blocked/failed/needs-info | Show status, suggest retrying or providing more info |
-| `playwright-cli` not installed | Browser verification skipped for playwright bugs (non-blocking). Suggest: `npm install -g @playwright/cli@latest; playwright-cli install --skills` |
-| `opencli` not installed | Browser verification skipped for opencli bugs (non-blocking). Install opencli for Chrome session-based browser verification |
-| PowerShell execution policy blocks script | Run `Set-ExecutionPolicy -Scope Process Bypass` for the current terminal |
+Read `${SKILL_DIR}/references/configuration.md` for the full error handling table (11 entries).
 
 ### Integration Notes