prizmkit 1.1.111 → 1.1.112

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,7 +29,7 @@ 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"
 
@@ -162,6 +162,35 @@ 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", "")))
+    }
+    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) and dep not in known_ids:
+                errors.append("bugs[{}] ({}): dependency '{}' does not exist".format(
+                    i, bug_id, dep))
+
     return {
         "valid": len(errors) == 0,
         "errors": errors,

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

@@ -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 append a separate skill-managed audit log.
 
 ### 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
@@ -125,9 +122,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 +132,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 +152,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.
 
@@ -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.
+- **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.
 - **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.
 - **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,6 +309,9 @@ Notes:
 
 After pipeline completion, if features have `browser_interaction` fields and the corresponding browser tool (`playwright-cli` or `opencli`) is installed:
 
+If list status may be stale, prefer the runtime status command before deciding which completed features qualify:
+`python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json`.
+
 1. **Check which features qualify**:
    ```bash
    python3 -c "
@@ -339,13 +347,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.
+- **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 and bugfix pipelines use separate state directories (`.prizmkit/state/features/` vs `.prizmkit/state/bugfix/`), so they 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.

package/bundled/skills/feature-planner/references/new-project-planning.md

@@ -1,31 +1,29 @@
-# New App Planning Reference
+# Initial Feature Set Planning Reference
 
-Use this reference when the user is planning a product from scratch.
+Use this reference when an existing or already app-planned project needs its first `.prizmkit/plans/feature-list.json`.
+
+Do not use this reference to define app vision, tech stack, or architecture from scratch. That belongs to `app-planner`.
 
 ## Phase Guide
 
-### Phase 1: Vision
-Capture:
-- problem statement
-- target users
-- core value proposition
-- non-goals (what to exclude from MVP)
+### Phase 1: Existing Context
+
+Capture or infer:
+- project brief and current product goals
+- already implemented capabilities
+- target users and primary workflows from existing docs or code
+- explicit non-goals already documented for the project
 
-### Phase 2: Stack Defaults
-If user has no preference, propose defaults aligned with project conventions:
-- Frontend: Next.js + TypeScript
-- Backend: Express/Nest (choose one and stay consistent)
-- DB: PostgreSQL
-- ORM: Prisma
-- Test: unit + e2e baseline
+### Phase 2: Existing Stack and Architecture
 
-If `.prizmkit/config.json` exists, prioritize its settings.
+Read `.prizmkit/config.json`, `.prizmkit/plans/project-brief.md`, `.prizmkit/prizm-docs/root.prizm`, and platform instruction files when present. If app-level context is missing and the user is asking for product/stack decisions, recommend `app-planner`.
 
 ### Phase 3: MVP Features
+
 Rules:
-- Include foundational setup feature first
-- Aim 5-12 features for MVP
-- Keep each feature implementable in one pipeline unit unless clearly too large
+- Include foundational setup feature first only when the existing project still needs setup work.
+- Aim 5-12 features for an initial executable plan unless the user explicitly scopes smaller.
+- Keep each feature implementable in one pipeline unit unless clearly too large.
 
 For each feature define:
 - `id`
@@ -36,9 +34,10 @@ For each feature define:
 - `dependencies`
 - `acceptance_criteria`
 - `status: "pending"`
-- `browser_interaction` (optional — for UI features, see §Browser Interaction Planning in SKILL.md)
+- `browser_interaction` when UI verification is useful (see §Browser Interaction Planning in SKILL.md)
 
 ### Phase 4: Dependency & Priority
+
 Check:
 - no cycles
 - all dependency targets exist
@@ -46,39 +45,36 @@ Check:
 - priorities align with delivery value and risk
 
 ### Phase 5: Granularity
+
 Split into `sub_features` when:
 - scope crosses too many modules
 - acceptance criteria are excessive
 - complexity is high and uncertainty is high
 
 ### Phase 6: Generate + Validate
-1. Write `feature-list.json`.
-2. Run:
+
+1. Write `.prizmkit/plans/feature-list.draft.json`.
+2. Generate the final file:
    ```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
    ```
-3. Fix all errors, then re-run.
+3. Fix draft errors, then re-run generate.
 
 ## Quality Rules
 
-- Keep titles concise and English
-- Make descriptions implementation-oriented (clear boundaries, interfaces, behavior)
-- **Description depth by complexity:**
-  - **Low complexity**: ≥30 words — what to build, key behavior, which files/modules are affected
-  - **Medium complexity**: ≥50 words — add integration points, data model overview, error handling approach
-  - **High complexity**: ≥80 words — add architecture decisions, performance considerations, security implications, migration strategy if applicable
-- **Description must cover** (adapt per feature):
-  1. **What**: concrete deliverable (API endpoints, UI components, data models)
-  2. **How it integrates**: which existing modules/services it connects to
-  3. **Key behaviors**: business rules, validation rules, state transitions
-  4. **Data model**: entities, relationships, key fields (when applicable)
-  5. **Error/edge cases**: what happens on failure, empty states, limits
-- Write testable acceptance criteria (at least 3; prefer 5+ for medium/high)
-- Keep dependency graph simple and explicit
+- Keep titles concise and English.
+- Make descriptions implementation-oriented: clear boundaries, interfaces, behavior.
+- Description depth by complexity:
+  - Low complexity: ≥30 words — what to build, key behavior, which files/modules are affected
+  - Medium complexity: ≥50 words — add integration points, data model overview, error handling approach
+  - High complexity: ≥80 words — add architecture decisions, performance considerations, security implications, migration strategy if applicable
+- Description must cover what, integration points, key behaviors, data model when applicable, and error/edge cases.
+- Write at least 1 testable acceptance criterion to satisfy schema validation. Fewer than 3 criteria is a planner quality warning; medium/high features should usually target 5+.
+- Keep dependency graph simple and explicit.
 
 ## Final Delivery Checklist
 
-- [ ] User confirmed MVP scope
+- [ ] User confirmed initial feature scope
 - [ ] IDs are sequential
 - [ ] `status` initialized to `pending`
 - [ ] Validation passes

package/bundled/skills/feature-planner/scripts/validate-and-generate.py

@@ -268,7 +268,7 @@ def validate_feature_list(data, is_new_plan=True):
         if isinstance(priority, str) and priority in VALID_PRIORITIES:
             priorities.append(priority)
         else:
-            errors.append("{}: priority must be one of 'high', 'medium', 'low', got {}".format(
+            errors.append("{}: priority must be one of 'critical', 'high', 'medium', 'low', got {}".format(
                 label, repr(priority)
             ))