prizmkit 1.1.80 → 1.1.82

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.80",
-  "bundledAt": "2026-06-29T16:26:24.901Z",
-  "bundledFrom": "9cb872e"
+  "frameworkVersion": "1.1.82",
+  "bundledAt": "2026-06-30T03:07:55.258Z",
+  "bundledFrom": "c12c40b"
 }

package/bundled/dev-pipeline/lib/heartbeat.sh

@@ -185,7 +185,7 @@ PY
             # growing with repeated failed reads or wasted calls.
             if [[ "$error_loop_detected" == "true" ]]; then
                 stale_seconds=$effective_stale_kill_threshold
-            elif [[ $growth -eq 0 && $child_growth -eq 0 ]]; then
+            elif [[ $growth -le 0 && $child_growth -eq 0 ]]; then
                 stale_seconds=$((stale_seconds + heartbeat_interval))
             else
                 stale_seconds=0

package/bundled/dev-pipeline/run-feature.sh

@@ -990,7 +990,7 @@ else:
 
     # Commit feature status update on the original branch (after guaranteed return)
     if ! git -C "$_proj_root" diff --quiet "$feature_list" 2>/dev/null; then
-        git -C "$_proj_root" add "$feature_list"
+        git -C "$_proj_root" add "$feature_list" 2>/dev/null || true
         git -C "$_proj_root" commit --no-verify -m "chore($feature_id): update feature status" 2>/dev/null || true
     fi
 
@@ -1424,7 +1424,7 @@ DEPLOY_PROMPT_EOF
 
         # Commit feature status update on the original branch (after guaranteed return)
         if ! git -C "$_proj_root" diff --quiet "$feature_list" 2>/dev/null; then
-            git -C "$_proj_root" add "$feature_list"
+            git -C "$_proj_root" add "$feature_list" 2>/dev/null || true
             git -C "$_proj_root" commit --no-verify -m "chore($feature_id): update feature status" 2>/dev/null || true
         fi
 
@@ -1636,7 +1636,7 @@ case "${1:-run}" in
 
         # Commit the status change
         if ! git diff --quiet "$_unskip_feature_list" 2>/dev/null; then
-            git add "$_unskip_feature_list"
+            git add "$_unskip_feature_list" 2>/dev/null || true
             git commit -m "chore: unskip auto-skipped features" 2>/dev/null || true
         fi
         ;;

package/bundled/dev-pipeline/templates/bootstrap-tier1.md

@@ -418,11 +418,6 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
 
 2. This file is intentionally lightweight — write it BEFORE context runs out.
 
-**Lifecycle**: failure-log.md is a temporary cross-session artifact. Do NOT commit it to git. After a successful session (all phases complete + commit done), delete it:
-```bash
-rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
-```
-
 ## Reminders
 
 - Tier 1: you handle everything directly — no subagents needed
@@ -432,3 +427,5 @@ rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
 - Do NOT run `git add`/`git commit` during Phase 1-3 — all changes are committed once in Phase 4
 - If any files remain after the commit, amend the existing commit — do NOT create a follow-up commit
 - When staging files, always use explicit file names — NEVER use `git add -A` or `git add .`
+- **NEVER delete, modify, or touch any file under `.prizmkit/state/`** — those are pipeline runtime files managed by the runner
+- NEVER run `rm -rf`, `git clean`, or any destructive filesystem operations

package/bundled/dev-pipeline/templates/bootstrap-tier2.md

@@ -534,11 +534,6 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
 
 2. This file is intentionally lightweight — write it BEFORE context runs out.
 
-**Lifecycle**: failure-log.md is a temporary cross-session artifact. Do NOT commit it to git. After a successful session (all phases complete + commit done), delete it:
-```bash
-rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
-```
-
 ## Reminders
 
 - Tier 2: orchestrator builds context+plan, Analyzer checks consistency, Dev implements, Reviewer reviews+tests — use direct Agent spawn for agents
@@ -546,6 +541,8 @@ rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
 - context-snapshot.md is append-only: orchestrator writes Sections 1-4, Dev appends Implementation Log, Reviewer appends Review Notes
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding
 - Do NOT use `run_in_background=true` when spawning subagents
+- **NEVER delete, modify, or touch any file under `.prizmkit/state/`** — those are pipeline runtime files managed by the runner
+- NEVER run `rm -rf`, `git clean`, or any destructive filesystem operations
 - `/prizmkit-committer` is mandatory, and must not be replaced with manual git commit commands
 - Do NOT run `git add`/`git commit` during Phase 1-5 — all changes are committed once in Phase 6
 - If any files remain after the commit, amend the existing commit — do NOT create a follow-up commit

package/bundled/dev-pipeline/templates/bootstrap-tier3.md

@@ -612,11 +612,6 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
 
 2. This file is intentionally lightweight — write it BEFORE context runs out.
 
-**Lifecycle**: failure-log.md is a temporary cross-session artifact. Do NOT commit it to git. After a successful session (all phases complete + commit done), delete it:
-```bash
-rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
-```
-
 ## Reminders
 
 - Tier 3: full team — Dev (implementation) → Reviewer (review + test) — spawn agents directly via Agent tool
@@ -624,6 +619,8 @@ rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding
 - Do NOT use `run_in_background=true` when spawning agents
 - Commit phase must use `/prizmkit-committer`; do NOT replace with manual git commit commands
+- **NEVER delete, modify, or touch any file under `.prizmkit/state/`** — those are pipeline runtime files managed by the runner
+- NEVER run `rm -rf`, `git clean`, or any destructive filesystem operations
 - Do NOT run `git add`/`git commit` during Phase 1-5 — all changes are committed once in Phase 6
 - If any files remain after the commit, amend the existing commit — do NOT create a follow-up commit
 - When staging files, always use explicit file names — NEVER use `git add -A` or `git add .`

package/bundled/dev-pipeline/templates/sections/failure-capture.md

@@ -14,8 +14,3 @@ If you encounter an unrecoverable error, context overflow, or are about to exit
    ```
 
 2. This file is intentionally lightweight — write it BEFORE context runs out.
-
-**Lifecycle**: failure-log.md is a temporary cross-session artifact. Do NOT commit it to git. After a successful session (all phases complete + commit done), delete it:
-```bash
-rm -f .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
-```

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.80",
+  "version": "1.1.82",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/bundled/skills/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/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/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/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/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/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/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/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:
 
@@ -317,28 +311,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
 
@@ -351,7 +345,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
@@ -378,6 +372,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/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/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** |
 
 ## Scenario Routing
 
@@ -99,6 +97,8 @@ Actions:
 
 ## Operation: Interactive Planning
 
+Triggers: "plan bug fixes", "report bugs".
+
 Launch the interactive bug planning process through 5 phases.
 
 ### Phase 1: Project Context
@@ -262,6 +262,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
@@ -282,6 +284,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.)
@@ -296,6 +300,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
@@ -309,6 +315,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/bugfix-pipeline-launcher/SKILL.md

@@ -112,77 +112,15 @@ Detect user intent from their message, then follow the corresponding workflow:
      --action status 2>/dev/null
    ```
 
-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:
-
-   **Question 1 — Execution mode** (multiSelect: false):
-   - Foreground (Recommended) — pipeline runs in the current session via `run-bugfix.sh run`. Visible output and direct error feedback.
-   - Background daemon — pipeline runs fully detached via `launch-bugfix-daemon.sh`. Survives AI CLI session closure.
-   - Manual — display the final assembled commands only. Do not execute anything. User runs them on their own.
-
-   ⚠️ 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 — Deploy after completion?** (multiSelect: false):
-   - No (default) — Skip deployment after pipeline completes
-   - Yes — Run /prizmkit-deploy automatically after all bugs fixed successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any bug was not fixed (status not 'completed', 'skipped', or 'needs_info').
-
-   **Question 4 — 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).
+5. **Ask configuration options** — applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 4.
 
+   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.
 
+   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.
 
    **Foreground command:**

package/bundled/skills/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,55 @@ 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, deploy, 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 — Deploy after completion?** (multiSelect: false):
+- No (default) — Skip deployment after pipeline completes
+- Yes — Run /prizmkit-deploy automatically after all bugs fixed successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any bug was not fixed (status not 'completed', 'skipped', or 'needs_info').
+
+**Question 4 — 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 |