prizmkit 1.1.111 → 1.1.113

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

@@ -1,6 +1,6 @@
 ---
 name: "bug-planner"
-description: "Interactive bug planning that produces .prizmkit/plans/bug-fix-list.json for the Bug Fix Pipeline. Supports multiple input formats: error logs, stack traces, user reports, failed tests, monitoring alerts. Use this skill whenever the user has bugs to report, errors to parse, or test failures to organize. Trigger on: 'plan bug fixes', 'report bugs', 'I have some bugs', 'these tests are failing', 'here is an error log', 'parse these errors', 'generate bug list'."
+description: "Interactive bug planning that produces, validates, appends, and summarizes .prizmkit/plans/bug-fix-list.json for the Bug Fix Pipeline. Supports error logs, stack traces, user reports, failed tests, monitoring alerts, existing bug-list validation, and bug-list summaries. Use whenever the user has bugs to report, errors to parse, test failures to organize, or asks to validate/list bugs. Trigger on: 'plan bug fixes', 'report bugs', 'these tests are failing', 'parse errors', 'generate bug list', 'validate bug list', 'show bug list', 'append bugs'."
 ---
 
 # Bug Planner
@@ -346,7 +346,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 
 Triggers: "parse this error log", "here's a stack trace", "parse these errors".
 
-Batch-parse error logs to generate bug entries without interactive prompts:
+Batch-parse error logs with minimal interaction: parse automatically, then require final user confirmation before generating the final list:
 
 1. Accept log file path or piped content
 2. Parse all unique errors (deduplicate by error message pattern)
@@ -376,7 +376,8 @@ Batch-parse failed test output:
 3. Auto-populate `failed_test_path`, `error_message`
 4. Set verification_type to `automated` (test already exists)
 5. Write draft to `.prizmkit/plans/bug-fix-list.draft.json`
-6. After user confirms, call the generate script:
+6. Present parsed failed-test bug entries for confirmation; allow edits, merges, or removals
+7. After user confirms, call the generate script:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-bug-list.py generate --input .prizmkit/plans/bug-fix-list.draft.json --output .prizmkit/plans/bug-fix-list.json
    ```
@@ -425,7 +426,7 @@ When configuring critic settings or browser verification for bugs, read `${SKILL
 Key points:
 - Critic is enabled by default for critical/high severity, disabled for medium/low
 - Users can override critic settings per-bug during Phase 2 or Phase 3
-- Browser verification is feature-pipeline only — bug fixes use `verification_type` field (automated/manual/hybrid)
+- `browser_interaction` is supported for UI-reproducible bugs; `verification_type` still declares whether verification is automated, manual, or hybrid.
 
 ---
 
@@ -451,7 +452,7 @@ Common errors handled inline:
 | Ambiguous severity classification | Present options, ask user to choose |
 | Duplicate bug detected | Warn user, suggest merging or keeping separate |
 | No bugs provided | Prompt with examples of supported input formats |
-| Invalid feature reference | Warn and ask user to correct or remove reference |
+| Invalid dependency reference | Warn and ask user to correct or remove the dependency |
 | Schema validation failure | Show specific errors, offer to fix interactively |
 
 ## Output

package/bundled/skills/bug-planner/references/critic-and-verification.md

@@ -2,7 +2,7 @@
 
 ## Adversarial Critic Review (Testing Defaults)
 
-All bug fixes support optional critic review for additional quality assurance. The critic mechanism is disabled by default but can be enabled per-bug based on severity and complexity.
+All bug fixes support optional critic review for additional quality assurance. The planner enables critic review by default for critical/high severity bugs and leaves it disabled for medium/low bugs; users can override per bug.
 
 ### Default Critic Behavior
 
@@ -21,13 +21,13 @@ All bug fixes support optional critic review for additional quality assurance. T
 
 ## Browser Verification
 
-**Browser verification is a feature-pipeline capability only.** Bug fixes use the `verification_type` field instead:
+Bug fixes can use `browser_interaction` when the bug is reproducible through a UI. The `verification_type` field still declares the overall verification mode:
 
 - `verification_type: automated` — Use unit/integration tests to verify the fix
 - `verification_type: manual` — Describe manual testing steps in acceptance criteria (including any browser verification steps)
 - `verification_type: hybrid` — Combine automated tests with manual browser verification steps
 
-For UI-related bugs that require visual verification (e.g., "Button doesn't show error message"), describe the verification steps in acceptance criteria.
+For UI-related bugs, add `browser_interaction.verify_steps` when concrete browser goals are known. Also keep acceptance criteria measurable so the bugfix session can verify the fix without asking the user.
 
 ### Example
 

package/bundled/skills/bug-planner/references/schema-validation.md

@@ -17,7 +17,8 @@ Use this checklist for manual validation when `validate-bug-list.py` is not avai
 - [ ] `error_source.type`: one of `stack_trace`, `user_report`, `failed_test`, `log_pattern`, `monitoring_alert`
 - [ ] `verification_type`: one of `automated`, `manual`, `hybrid`
 - [ ] `acceptance_criteria`: non-empty array of strings
-- [ ] `status`: must be `pending` for new bugs
+- [ ] `status`: one of `pending`, `in_progress`, `completed`, `failed`, `skipped`, `needs_info`; new bugs should start as `pending`
+- [ ] `dependencies` if present: array of existing `B-NNN` IDs; no self-dependencies
 
 ## Consistency Checks
 

package/bundled/skills/bug-planner/scripts/validate-bug-list.py

@@ -29,11 +29,43 @@ from datetime import datetime, timezone
 VALID_SEVERITIES = {"critical", "high", "medium", "low"}
 VALID_SOURCE_TYPES = {"stack_trace", "user_report", "failed_test", "log_pattern", "monitoring_alert"}
 VALID_VERIFICATION_TYPES = {"automated", "manual", "hybrid"}
-VALID_STATUSES = {"pending", "triaging", "reproducing", "fixing", "verifying", "completed", "failed", "needs_info", "skipped"}
+VALID_STATUSES = {"pending", "in_progress", "completed", "failed", "skipped", "needs_info"}
 BUG_ID_PATTERN = re.compile(r"^B-\d{3}$")
 SCHEMA_VERSION = "dev-pipeline-bug-fix-list-v1"
 
 
+def _find_dependency_cycle(dep_map, item_ids):
+    """Return one dependency cycle as a list of bug IDs, or an empty list."""
+    visiting = set()
+    visited = set()
+    stack = []
+
+    def visit(node):
+        visiting.add(node)
+        stack.append(node)
+        for dep in dep_map.get(node, []):
+            if dep not in item_ids:
+                continue
+            if dep in visiting:
+                start = stack.index(dep)
+                return stack[start:] + [dep]
+            if dep not in visited:
+                cycle = visit(dep)
+                if cycle:
+                    return cycle
+        stack.pop()
+        visiting.remove(node)
+        visited.add(node)
+        return []
+
+    for bug_id in sorted(item_ids):
+        if bug_id not in visited:
+            cycle = visit(bug_id)
+            if cycle:
+                return cycle
+    return []
+
+
 def _err(msg):
     """Print an error message to stderr."""
     print("ERROR: {}".format(msg), file=sys.stderr)
@@ -162,6 +194,43 @@ def validate(data, feature_ids=None):
                 errors.append("{} ({}): invalid priority '{}' — must be one of 'high', 'medium', 'low'".format(
                     prefix, bug_id, priority))
 
+        # dependencies (optional field)
+        deps = bug.get("dependencies", [])
+        if deps is None:
+            deps = []
+        if not isinstance(deps, list):
+            errors.append("{} ({}): dependencies must be an array".format(prefix, bug_id))
+        else:
+            for dep in deps:
+                if not isinstance(dep, str) or not BUG_ID_PATTERN.match(dep):
+                    errors.append("{} ({}): invalid dependency '{}' — must match B-NNN".format(
+                        prefix, bug_id, dep))
+                elif dep == bug_id:
+                    errors.append("{} ({}): bug cannot depend on itself".format(prefix, bug_id))
+
+    known_ids = {
+        bug.get("id")
+        for bug in bugs
+        if BUG_ID_PATTERN.match(str(bug.get("id", "")))
+    }
+    dep_map = {bug_id: [] for bug_id in known_ids}
+    for i, bug in enumerate(bugs):
+        bug_id = bug.get("id", "")
+        deps = bug.get("dependencies", []) or []
+        if not isinstance(deps, list):
+            continue
+        for dep in deps:
+            if isinstance(dep, str) and BUG_ID_PATTERN.match(dep):
+                if dep not in known_ids:
+                    errors.append("bugs[{}] ({}): dependency '{}' does not exist".format(
+                        i, bug_id, dep))
+                elif BUG_ID_PATTERN.match(str(bug_id)):
+                    dep_map.setdefault(bug_id, []).append(dep)
+
+    cycle = _find_dependency_cycle(dep_map, known_ids)
+    if cycle:
+        errors.append("Dependency cycle detected: {}".format(" -> ".join(cycle)))
+
     return {
         "valid": len(errors) == 0,
         "errors": errors,

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

@@ -5,7 +5,7 @@ description: "Launch and manage the bugfix pipeline from within an AI CLI sessio
 
 # Bugfix-Pipeline Launcher
 
-Launch the autonomous bug fix pipeline from within an AI CLI conversation. Supports foreground and background execution modes.
+Launch the autonomous bug fix pipeline from within an AI CLI conversation. Only Background daemon mode is fully detached and survives AI CLI session closure; Foreground runs in the current session, and Manual prints commands without launching.
 
 ### Execution Mode
 
@@ -15,10 +15,7 @@ Three execution modes are available. The user chooses one before configuring oth
 2. **Background daemon** — `python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json`. 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.
 
-**Background mode documentation**: When the user chooses background/daemon mode, record the choice and PID in `.prizmkit/bugfix-pipeline-run.log` (append-only) with timestamp, so the decision is traceable:
-```
-[2026-03-26T10:30:00] MODE=daemon PID=12345 BUG_LIST=.prizmkit/plans/bug-fix-list.json BUGS=3
-```
+**Background mode traceability**: Daemon mode metadata and logs are written by the Python runtime (`daemon bugfix start/status/logs`). Do not create any extra launcher-managed audit file.
 
 ### When to Use
 
@@ -72,7 +69,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 #### Intent A: Start Bugfix Pipeline
 
-> **Execution model**: The pipeline processes bugs **sequentially** (one at a time, in severity/priority order). The `dependencies` field in bug-fix-list.json is reserved for future parallel execution support and does NOT affect current execution order.
+> **Execution model**: The pipeline processes eligible bugs one at a time. The `dependencies` field is active: dependencies must complete before dependents are selected. Among unrelated eligible bugs, stable list order determines selection.
 
 1. **Check prerequisites**:
    ```bash
@@ -93,7 +90,6 @@ Detect user intent from their message, then follow the corresponding workflow:
        data = json.load(f)
    bugs = data.get('bugs', [])
    severity_order = {'critical': 0, 'high': 1, 'medium': 2, 'low': 3}
-   bugs_sorted = sorted(bugs, key=lambda b: (severity_order.get(b.get('severity', 'medium'), 2), b.get('priority', 99)))
    print(f'Total bugs: {len(bugs)}')
    sev_counts = {}
    for b in bugs:
@@ -101,7 +97,7 @@ Detect user intent from their message, then follow the corresponding workflow:
        sev_counts[s] = sev_counts.get(s, 0) + 1
    print(f'By severity: {dict(sorted(sev_counts.items(), key=lambda x: severity_order.get(x[0], 2)))}')
    print()
-   for b in bugs_sorted:
+   for b in bugs:
        print(f\"  {b['id']}: [{b.get('severity','?').upper()}] {b.get('title', 'untitled')}\")
    "
    ```
@@ -125,9 +121,9 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    VERBOSE=1 python3 ./.prizmkit/dev-pipeline/cli.py bugfix run .prizmkit/plans/bug-fix-list.json
    ```
-   With all options:
+   Selected-options example:
    ```bash
-   VERBOSE=1 MAX_RETRIES=5 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
+   VERBOSE=1 ENABLE_CRITIC=1 MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      python3 ./.prizmkit/dev-pipeline/cli.py bugfix run .prizmkit/plans/bug-fix-list.json
    ```
 
@@ -135,10 +131,10 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
    ```
-   With all options:
+   Selected-options example:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json \
-     --env "VERBOSE=1 MAX_RETRIES=5 ENABLE_DEPLOY=1"
+     --env "VERBOSE=1 ENABLE_CRITIC=1 MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 7.
@@ -155,7 +151,10 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 7. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 6):
 
-   Ask: "Ready to launch the bugfix pipeline with the above command?"
+   Use a separate `AskUserQuestion` call: "Ready to launch the bugfix pipeline with the above command?"
+   Options:
+   - Launch now (Recommended)
+   - Cancel
 
    After user confirms, execute the command from step 6.
 
@@ -165,6 +164,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Summarize results: total bugs, fixed, failed, skipped
    - If all fixed: each bug session has already run `prizmkit-retrospective` internally (structural sync by default; full retrospective when the fix changed interfaces, dependencies, or observable behavior). Ask user what's next.
    - If some failed: show failed bug IDs and suggest `python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <B-XXX> --clean --run` for a fresh retry
+   - **Browser verification**: Bug sessions with `browser_interaction` perform their own verification attempts during execution. After completion, use `python3 ./.prizmkit/dev-pipeline/cli.py bugfix status .prizmkit/plans/bug-fix-list.json` and per-bug session logs as the source of truth before summarizing browser verification results.
 
    **If background daemon**:
    1. Verify launch:
@@ -200,7 +200,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix logs --lines 20
    ```
 
-4. **Summarize** to user: total bugs, completed, in-progress, failed, pending, needs-info.
+4. **Summarize** to user: total bugs, completed, in_progress, failed, pending, needs_info.
 
 ---
 
@@ -259,15 +259,15 @@ python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix B-001 --clean --run .prizmk
 
 ### Error Handling
 
-Read `${SKILL_DIR}/references/configuration.md` for the full error handling table (11 entries).
+Read `${SKILL_DIR}/references/configuration.md` for the full error handling table.
 
 ### Integration Notes
 
 - **After bug-planner**: This is the natural next step. When user finishes bug planning and has `.prizmkit/plans/bug-fix-list.json`, suggest launching the bugfix pipeline.
-- **Session independence**: In daemon mode, the bugfix pipeline runs completely detached. User can close the AI CLI, open a new session later, and use this skill to check progress or stop the pipeline.
-- **Single instance**: Only one bugfix pipeline can run at a time. The PID file prevents duplicates.
-- **Feature pipeline coexistence**: Bugfix and feature pipelines use separate state directories (`.prizmkit/state/bugfix/` vs `.prizmkit/state/features/`), so they can run simultaneously without conflict.
+- **Session independence**: Only Background daemon mode runs detached. Foreground runs in the current AI CLI session, and Manual mode prints commands without launching.
+- **Single instance per family**: Only one bugfix pipeline can run at a time. Different pipeline families may coexist because they use separate daemon metadata and state directories.
+- **Pipeline coexistence**: Bugfix, feature, and refactor pipelines use separate state directories (`.prizmkit/state/bugfix/`, `.prizmkit/state/features/`, `.prizmkit/state/refactor/`), so all three can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the bugfix pipeline resumes from where it left off -- completed bugs are not re-fixed.
-- **Bug ordering**: Bugs are processed by severity (critical → high → medium → low), then by priority number within the same severity.
-- **Background mode traceability**: When daemon mode is chosen, the decision is logged to `.prizmkit/bugfix-pipeline-run.log` with timestamp, PID, and bug count for auditability.
-- **HANDOFF**: After pipeline completes all bugs, suggest running `prizmkit-retrospective` to capture lessons learned, or checking the fix reports in `.prizmkit/bugfix/`.
+- **Bug ordering**: Dependencies are active. Runtime selects eligible bugs in stable list order after dependencies are completed; planners should order unrelated bugs by severity/priority before launch.
+- **Background mode traceability**: Daemon mode metadata/logging is runtime-owned; use `daemon bugfix status` and `daemon bugfix logs`.
+- **HANDOFF**: After pipeline completes all bugs, summarize results and ask what the user wants next. Individual sessions already run retrospective according to the bug-fix documentation policy.

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

@@ -51,7 +51,7 @@ Present these via `AskUserQuestion` in step 5. Round 1 is one `AskUserQuestion`
 - No (default) — Use defaults for failure behavior
 - Yes — Configure 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.
+Note: Bug filter defaults to all bugs. Runtime selects eligible bugs in stable list order after dependencies are completed; planners should order unrelated bugs by severity/priority before launch. 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)
 
@@ -82,7 +82,7 @@ Note: Bug filter defaults to all bugs (by severity order). Default Critic to Off
 | Bugfix pipeline already running | Show status, ask if user wants to stop and restart |
 | PID file stale (process dead) | `python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json` auto-cleans, retry start |
 | Launch failed (process died immediately) | Show last 20 lines of log: `python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix logs --lines 20` |
-| All bugs blocked/failed/needs-info | Show status, suggest retrying with `python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <B-XXX> --clean --run .prizmkit/plans/bug-fix-list.json` or providing more info |
+| All bugs blocked/failed/needs_info | Show status, suggest retrying with `python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <B-XXX> --clean --run .prizmkit/plans/bug-fix-list.json` 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 |
 | Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/bugfix/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |

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

@@ -5,7 +5,7 @@ description: "Launch and manage the dev-pipeline from within an AI CLI session.
 
 # Dev-Pipeline Launcher
 
-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.
+Launch the autonomous development pipeline from within an AI CLI conversation. Only Background daemon mode is fully detached and survives AI CLI session closure; Foreground runs in the current session, and Manual prints commands without launching.
 
 Three execution modes are available (Foreground / Background daemon / Manual); they are defined authoritatively in **Intent A, step 5** below.
 
@@ -63,7 +63,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 #### Intent A: Start Pipeline
 
-> **Execution model**: The pipeline processes features **sequentially** (one at a time, in order). The `dependencies` field in feature-list.json is reserved for future parallel execution support and does NOT affect current execution order.
+> **Execution model**: The pipeline processes eligible features one at a time. The `dependencies` field is active: dependencies must complete before dependents are selected, and unrelated eligible items preserve stable list order.
 
 1. **Check prerequisites**:
    ```bash
@@ -97,9 +97,11 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Run the preflight script to auto-detect the database type, verify env vars, test connectivity, and check migration status:
    ```bash
-   python3 ${SKILL_DIR}/scripts/preflight-check.py .prizmkit/plans/feature-list.json
+   python3 <feature-pipeline-launcher-skill-dir>/scripts/preflight-check.py .prizmkit/plans/feature-list.json
    ```
 
+   Replace `<feature-pipeline-launcher-skill-dir>` with the resolved skill directory path before running. Do not execute a literal unresolved `${SKILL_DIR}` shell variable.
+
    The script:
    - Reads `global_context.database` from `.prizmkit/plans/feature-list.json` and `.prizmkit/config.json`
    - Scans `.env.local` / `.env` for connection variables (supports Supabase, PostgreSQL, MySQL, MongoDB, Firebase, and generic `DATABASE_URL`)
@@ -154,7 +156,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **If user chose "Yes" to Advanced config**, ask a second round of `AskUserQuestion` — see the advanced config questions (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).
+   Read `${SKILL_DIR}/references/configuration.md` for the current environment-variable mapping and advanced environment-variable tables.
 
 
 7. **Show final command**: After user confirms configuration in step 6, assemble the complete command from execution mode + user-confirmed configuration, and present it to the user.
@@ -163,9 +165,9 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    VERBOSE=1 python3 ./.prizmkit/dev-pipeline/cli.py feature run .prizmkit/plans/feature-list.json
    ```
-   With all options:
+   Selected-options example:
    ```bash
-   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
+   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      python3 ./.prizmkit/dev-pipeline/cli.py feature run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
@@ -173,10 +175,10 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon feature start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
    ```
-   With all options:
+   Selected-options example:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon feature start .prizmkit/plans/feature-list.json --features F-001:F-005 \
-     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
+     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.
@@ -193,7 +195,10 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 8. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 7):
 
-   Ask: "Ready to launch the pipeline with the above command?"
+   Use a separate `AskUserQuestion` call: "Ready to launch the pipeline with the above command?"
+   Options:
+   - Launch now (Recommended)
+   - Cancel
 
    After user confirms, execute the command from step 7.
 
@@ -304,19 +309,13 @@ Notes:
 
 After pipeline completion, if features have `browser_interaction` fields and the corresponding browser tool (`playwright-cli` or `opencli`) is installed:
 
-1. **Check which features qualify**:
-   ```bash
-   python3 -c "
-   import json
-   with open('.prizmkit/plans/feature-list.json') as f:
-       data = json.load(f)
-   for feat in data.get('features', []):
-       bi = feat.get('browser_interaction')
-       if bi and feat.get('status') == 'completed':
-           tool = bi.get('tool', 'auto') if isinstance(bi, dict) else 'auto'
-           print(f\"  {feat['id']}: {feat.get('title','')} (tool: {tool})\")
-   " 2>/dev/null
-   ```
+If list status may be stale, use the runtime status command as the source of truth for completion state:
+`python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json`.
+
+1. **Check which completed features have browser verification configured**:
+   - Read `browser_interaction` configuration from `.prizmkit/plans/feature-list.json`.
+   - Use the runtime status command output to decide which configured features are actually completed.
+   - Do not rely on list-file `status` alone when runtime state exists, because daemon/foreground bookkeeping may be newer than the plan file.
 
 2. **Ask user**: "N features have browser verification configured. Run browser verification now? (Y/n)"
 
@@ -339,13 +338,13 @@ After pipeline completion, if features have `browser_interaction` fields and the
 
 ### Error Handling
 
-Read `${SKILL_DIR}/references/configuration.md` for the full error handling table (16 entries covering feature-list not found, dependency checks, pipeline state, browser tooling, permission, and deploy failures).
+Read `${SKILL_DIR}/references/configuration.md` for the full error handling table covering feature-list, dependency checks, pipeline state, browser tooling, permission, and deploy failures.
 
 ### Integration Notes
 
 - **After feature-planner**: This is the natural next step. When user finishes planning and has `.prizmkit/plans/feature-list.json`, suggest launching the pipeline.
-- **Session independence**: The pipeline runs completely detached. User can close the AI CLI session, open a new session later, and use this skill to check progress or stop the pipeline.
-- **Single instance**: Only one pipeline can run at a time. The PID file prevents duplicates.
-- **Pipeline coexistence**: Feature and bugfix pipelines use separate state directories (`.prizmkit/state/features/` vs `.prizmkit/state/bugfix/`), so they can run simultaneously without conflict.
+- **Session independence**: Only Background daemon mode runs detached. Foreground runs in the current AI CLI session, and Manual mode prints commands without launching.
+- **Single instance per family**: Only one feature pipeline can run at a time. Different pipeline families may coexist because they use separate daemon metadata and state directories.
+- **Pipeline coexistence**: Feature, bugfix, and refactor pipelines use separate state directories (`.prizmkit/state/features/`, `.prizmkit/state/bugfix/`, `.prizmkit/state/refactor/`), so all three can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the pipeline resumes from where it left off -- completed features are not re-run.
 - **HANDOFF**: After pipeline completes all features, each session has already run `prizmkit-retrospective` internally. Ask user what's next.

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

@@ -1,6 +1,6 @@
 ---
 name: "feature-planner"
-description: "Plan and manage features for an existing project — add new features, reprioritize, split, and generate validated .prizmkit/plans/feature-list.json for dev-pipeline execution. Use this skill for feature scoping, incremental planning, continuing a feature plan, or preparing pipeline input. For planning a new app from scratch, use app-planner instead."
+description: "Plan, validate, and manage features for an existing project — add or append features, reprioritize, split, summarize, and generate validated .prizmkit/plans/feature-list.json for dev-pipeline execution. Use this skill for feature scoping, incremental planning, continuing a feature plan, checking feature-list.json, or preparing pipeline input. For planning a new app from scratch, use app-planner instead."
 ---
 
 # feature planner
@@ -103,7 +103,7 @@ Trigger conditions are covered by the frontmatter `description`. Do NOT use this
    5. **Priority enums**: All priority values are exactly "critical", "high", "medium", or "low" (case-sensitive)
    6. **Status enum**: All status values are one of: pending, in_progress, completed, failed, skipped, split, auto_skipped
    7. **Acceptance criteria**: At least 1 criterion per feature, each is a concrete, measurable statement
-   8. **Browser interaction**: If present, has verify_steps array (optional — AI auto-detects dev server, URL, port at runtime)
+   8. **Browser interaction**: If present, may include `tool` and `verify_steps`; planner should add concrete `verify_steps` when known, but the schema permits an empty object for AI runtime exploration.
    9. **Complexity enum**: If present, is one of: low, medium, high, critical
    10. **Model field**: If present, is a non-empty string
    11. **Critic field**: If present, is boolean; if true, critic_count should be 1 or 3
@@ -206,8 +206,8 @@ Anti-pattern rule: do not assign every generated item `Priority: high` and `Comp
 
 Classify user intent first:
 
-### Route A: New Feature Set (No Existing Plan)
-Use when the project exists but has no `.prizmkit/plans/feature-list.json` yet.
+### Route A: Initial Feature Set for Existing/App-Planned Project
+Use when source code or app-level context already exists but no `.prizmkit/plans/feature-list.json` exists yet. If the user is still defining vision, stack, or product brief from scratch, switch to `app-planner` only after confirmation.
 
 Actions:
 1. Understand the existing codebase and what's already implemented
@@ -307,13 +307,11 @@ For simple incremental planning, skip detailed Phase 2-3 analysis:
          description: "Skip detailed Phase 2-3 analysis, draft features directly and add to feature-list.json"
        - label: "Full workflow"
          description: "Use the complete planning workflow with detailed analysis"
-       - label: "Implement directly"
-         description: "Skip the task list entirely and implement the feature(s) right now using /prizmkit-plan + /prizmkit-implement"
    ```
 
    - **Fast-path** → Continue with fast-path workflow below
    - **Full workflow** → Exit fast path, use full workflow from Phase 2
-   - **Implement directly** → Invoke `/prizmkit-plan` directly to create spec + plan, then `/prizmkit-implement` to execute. Do NOT add to `.prizmkit/plans/feature-list.json`
+   - If the user wants direct implementation instead of planning, exit the planner flow after explicit confirmation and recommend `/prizmkit-plan`; do not invoke implementation from inside `feature-planner`.
    
    **NEVER proceed without explicit user selection via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 3. Generate next sequential feature IDs
@@ -440,10 +438,10 @@ Activate when ALL true:
 ### Gate Behavior
 When the session appears to be ending:
 1. **Remind**: "You set out to produce `.prizmkit/plans/feature-list.json` but we haven't completed it yet."
-2. **Offer 3 options**:
-   - **(a) Continue to completion**
-   - **(b) Save draft & exit** — write current progress as `feature-list.draft.json` to `.prizmkit/plans/`
-   - **(c) Abandon** — exit without saving
+2. Use `AskUserQuestion` with one question:
+   - **Continue to completion (Recommended)** — resume from current phase
+   - **Save draft & exit** — write current progress as `.prizmkit/plans/feature-list.draft.json`
+   - **Abandon** — exit without saving
 
 ## Handoff Message Template
 

package/bundled/skills/feature-planner/assets/planning-guide.md

@@ -2,7 +2,7 @@
 
 This guide provides structured templates and patterns for writing high-quality feature descriptions, acceptance criteria, complexity estimates, dependency graphs, and session granularity decisions. Use during feature-planner sessions.
 
-For app-level design references (vision templates, tech stack matrix), see `app-planner/assets/app-design-guide.md`. For feature decomposition patterns (CRUD, SaaS, Social, E-commerce), see `${SKILL_DIR}/references/decomposition-patterns.md`.
+For app-level design references (vision templates, tech stack matrix), see `app-planner/references/app-design-guide.md`. For feature decomposition patterns (CRUD, SaaS, Social, E-commerce), see `${SKILL_DIR}/references/decomposition-patterns.md`.
 
 ---
 

package/bundled/skills/feature-planner/references/decomposition-patterns.md

@@ -2,7 +2,7 @@
 
 Use these patterns as starting points when breaking an app into features. Adapt them to the specific project.
 
-For app-level design references (vision templates, tech stack decision matrix), see `app-planner/assets/app-design-guide.md`.
+For app-level design references (vision templates, tech stack decision matrix), see `app-planner/references/app-design-guide.md`.
 
 ## Pattern A: CRUD-Based App
 

package/bundled/skills/feature-planner/references/error-recovery.md

@@ -25,7 +25,8 @@ Group errors by type and apply targeted fixes:
 | **Feature ID issues** | Invalid format (not `F-NNN`), duplicate IDs, undefined refs | "Suggest corrected IDs, show duplicates" | Yes |
 | **Dependency errors** | Circular dependency, undefined target features | "Show cycle chain (e.g., `F-003 → F-005 → F-003`), suggest break point" | No |
 | **Missing fields** | Feature missing required keys (title, description, AC) | "List each feature + missing keys, guide patch" | Partial |
-| **Insufficient AC** | Feature has <2 acceptance criteria | "Show feature, suggest AC examples" | No |
+| **Insufficient AC** | Feature has 0 acceptance criteria | "Show feature, require at least one measurable criterion" | No |
+| **Thin AC quality** | Feature has 1-2 acceptance criteria | "Warn that planner quality is weak; suggest additional criteria" | No |
 | **Invalid values** | complexity not in [low/medium/high/critical], status not pending | "Show field, valid values" | Yes |
 
 ### Execution

package/bundled/skills/feature-planner/references/incremental-feature-planning.md

@@ -81,9 +81,9 @@ Allow priority updates for both old and new features if user requests reprioriti
 Keep dependency correctness as first constraint.
 
 ### Step 5: Validate
-Run:
+Write a draft and generate the final list:
 ```bash
-python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input feature-list.json
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
 ```
 
 Fix and re-run until pass.