prizmkit 1.1.80 → 1.1.81

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.80",
-  "bundledAt": "2026-06-29T16:26:24.901Z",
-  "bundledFrom": "9cb872e"
+  "frameworkVersion": "1.1.81",
+  "bundledAt": "2026-06-29T17:31:12.809Z",
+  "bundledFrom": "65df08d"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.80",
+  "version": "1.1.81",
   "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 |

package/bundled/skills/feature-pipeline-launcher/SKILL.md

@@ -7,37 +7,27 @@ description: "Launch and manage the dev-pipeline from within an AI CLI session.
 
 Launch the autonomous development pipeline from within an AI CLI conversation. The pipeline runs as a fully detached background process -- closing the AI CLI session does NOT stop the pipeline.
 
-### Execution Mode
-
-Three execution modes are available. The user chooses one before configuring other options:
-
-1. **Foreground** (recommended) — `.prizmkit/dev-pipeline/run-feature.sh run`. Visible output, direct error feedback, no orphaned processes.
-2. **Background daemon** — `.prizmkit/dev-pipeline/launch-feature-daemon.sh`. Runs fully detached, survives AI CLI session closure.
-3. **Manual** — Display the assembled command(s) only. Do not execute anything. User runs them on their own.
+Three execution modes are available (Foreground / Background daemon / Manual); they are defined authoritatively in **Intent A, step 5** below.
 
 ### When to Use
 
 **Start pipeline** -- User says:
-- "run pipeline", "start pipeline", "start building", "launch dev-pipeline"
-- "run the features", "execute feature list", "start implementing"
-- "launch pipeline", "run the pipeline", "start auto-development"
-- After feature-planner completes: "build it", "start developing from the feature list"
-- "run only F-001 to F-005", "run features F-001,F-003", "only build these features"
+- "run feature pipeline", "run pipeline", "start building features", "launch feature pipeline"
+- "start implementing", "execute feature list", "build all features"
+- After feature-planner completes: "build them", "start building from the list"
+- Supports running a feature subset (e.g. "run only F-001 to F-005", "run features F-001,F-003").
 
 **Check status** -- User says:
-- "pipeline status", "check pipeline", "how's it going", "progress"
-- "check progress", "what's the current situation"
+- "pipeline status", "feature progress", "check the pipeline", "how's the build going"
 
 **Stop pipeline** -- User says:
-- "stop pipeline", "kill pipeline", "halt", "pause"
-- "stop the pipeline", "pause the pipeline"
+- "stop pipeline", "stop the pipeline", "halt pipeline", "pause the build"
 
 **Show logs** -- User says:
-- "show logs", "pipeline logs", "tail logs", "what's happening"
-- "view logs", "check the logs"
+- "pipeline logs", "show pipeline logs", "what's building"
 
-**Retry single feature node** -- User says:
-- "retry F-003", "retry this feature", "retry this node", "re-run this feature"
+**Retry single feature** -- User says:
+- "retry F-001", "re-run F-001", "retry this feature"
 
 **Do NOT use this skill when:**
 - User wants to plan features (use `feature-planner` instead)
@@ -129,9 +119,9 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    If `global_context.database` is absent and no features mention database keywords, the script skips DB checks automatically.
 
-5. **Ask execution mode** (first user decision — SEPARATE `AskUserQuestion` call):
+5. **Ask execution mode** (first user decision):
 
-   ⛔ **This MUST be its own standalone `AskUserQuestion` call.** Do NOT combine execution mode with step 6 config questions. The execution mode question is asked ALONE, user responds, THEN you proceed to step 6.
+   **RULE: Ask step 5 and step 6 in separate `AskUserQuestion` calls.** Combining them makes the model merge the questions and skip the mode selection. Ask execution mode ALONE here, wait for the response, THEN proceed to step 6.
 
    Use `AskUserQuestion` with exactly 1 question:
 
@@ -140,19 +130,11 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Background daemon — pipeline runs fully detached via `launch-feature-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 6.
-
-6. **Ask configuration options** ⚠️ MANDATORY INTERACTIVE STEP — applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 5. You MUST ask the user to configure options and WAIT for their response BEFORE proceeding to step 7.
+   STOP HERE and wait for user response before continuing 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 5 and step 6 into one `AskUserQuestion` call (this is the most common violation — execution mode MUST be asked separately in step 5)
-   - Skip this step and jump to step 7
-   - Merge step 6 and step 7 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.
+6. **Ask configuration options** — MANDATORY INTERACTIVE STEP, applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 5 (see the RULE above). You MUST call `AskUserQuestion` with the 4 questions below and WAIT for the user's response before proceeding to step 7. Do NOT assume defaults, do NOT show the command as text and ask "ready?", and do NOT merge step 6 and step 7. 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):
+   Use `AskUserQuestion` to present ALL 4 configuration choices:
 
    **Question 1 — Critic review** (multiSelect: false):
    - Off (default) — Skip adversarial review
@@ -173,29 +155,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Default Critic to Off unless features have `estimated_complexity: "high"` or above (in which case default to On).
 
-   **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 features complete successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any feature did not complete successfully (status not 'completed' or manually 'skipped').
-
-   **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`)
+   **If user chose "Yes" to Advanced config**, ask a second round of `AskUserQuestion` — see the advanced config questions (session timeout, stop-on-failure, deploy-after-completion, reasoning effort) in `${SKILL_DIR}/references/configuration.md`.
 
    **Environment variable mapping** and **advanced environment variables** tables — read `${SKILL_DIR}/references/configuration.md` for the full translation tables (8 config→env mappings + 9 advanced variables).