prizmkit 1.1.7 → 1.1.9

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

@@ -49,7 +49,7 @@ Three execution modes are available. The user chooses one before configuring oth
 Before any action, validate:
 
 1. **dev-pipeline exists**: Confirm `dev-pipeline/launch-feature-daemon.sh` is present and executable
-2. **For start**: `feature-list.json` must exist in project root (or user-specified path)
+2. **For start**: `.prizmkit/plans/feature-list.json` must exist in `.prizmkit/plans/` (or user-specified path)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 4. **Python version**: Requires Python 3.8+ for dev-pipeline scripts
 5. **playwright-cli** (optional): If any feature has `browser_interaction` field, check `playwright-cli` is available
@@ -61,8 +61,8 @@ command -v jq && command -v python3 && (command -v cbc || command -v claude) &&
 command -v playwright-cli && echo "playwright-cli OK" || echo "playwright-cli not found (browser verification will be skipped)"
 ```
 
-If `feature-list.json` is missing, inform user:
-> "No feature-list.json found. Run the `feature-planner` skill first to generate one, or provide a path to your feature list."
+If `.prizmkit/plans/feature-list.json` is missing, inform user:
+> "No .prizmkit/plans/feature-list.json found. Run the `feature-planner` skill first to generate one, or provide a path to your feature list."
 
 ### Workflow
 
@@ -74,7 +74,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check prerequisites**:
    ```bash
-   ls feature-list.json 2>/dev/null && echo "Found" || echo "Missing"
+   ls .prizmkit/plans/feature-list.json 2>/dev/null && echo "Found" || echo "Missing"
    ```
 
 2. **Check not already running**:
@@ -87,7 +87,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    python3 -c "
    import json
-   with open('feature-list.json') as f:
+   with open('.prizmkit/plans/feature-list.json') as f:
        data = json.load(f)
    features = data.get('features', [])
    print(f'Total features: {len(features)}')
@@ -98,8 +98,8 @@ Detect user intent from their message, then follow the corresponding workflow:
    If pipeline state already exists, use the status command instead:
    ```bash
    python3 dev-pipeline/scripts/update-feature-status.py \
-     --feature-list feature-list.json \
-     --state-dir dev-pipeline/state \
+     --feature-list .prizmkit/plans/feature-list.json \
+     --state-dir .prizmkit/state/features \
      --action status 2>/dev/null
    ```
 
@@ -107,11 +107,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 feature-list.json
+   python3 ${SKILL_DIR}/scripts/preflight-check.py .prizmkit/plans/feature-list.json
    ```
 
    The script:
-   - Reads `global_context.database` from `feature-list.json` and `.prizmkit/config.json`
+   - 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`)
    - Tests connectivity using the appropriate method per database type
    - Checks migration status (Prisma, Drizzle, Supabase raw SQL, or generic migration directories)
@@ -170,40 +170,54 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Max retries: N | `MAX_RETRIES=N` |
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
 
+   **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
+
+   | Variable | Default | Purpose |
+   |----------|---------|---------|
+   | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
+   | `AUTO_PUSH` | `0` | Auto-push to remote after successful feature (`1` to enable) |
+   | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `dev/{feature_id}-YYYYMMDDHHmm`) |
+   | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
+   | `HEARTBEAT_STALE_THRESHOLD` | `600` | Max seconds without heartbeat before marking stale |
+   | `PIPELINE_MODE` | (none) | Override mode for all features: `lite`\|`standard`\|`full` |
+   | `LOG_CLEANUP_ENABLED` | `1` | Run periodic log cleanup (`0` to disable) |
+   | `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 |
+
    ⚠️ STOP HERE and wait for user response before continuing to step 7.
 
 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.
 
    **Foreground command:**
    ```bash
-   VERBOSE=1 dev-pipeline/run-feature.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
    ```
    With all options:
    ```bash
    VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 \
-     dev-pipeline/run-feature.sh run feature-list.json --features F-001:F-005
+     dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
    **Background daemon command:**
    ```bash
-   dev-pipeline/launch-feature-daemon.sh start feature-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
    ```
    With all options:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh start feature-list.json --features F-001:F-005 \
+   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --features F-001:F-005 \
      --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.
    ```
    # To run in foreground:
-   VERBOSE=1 dev-pipeline/run-feature.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-feature-daemon.sh start feature-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
 
    # To check status:
-   dev-pipeline/run-feature.sh status feature-list.json
+   dev-pipeline/run-feature.sh status .prizmkit/plans/feature-list.json
    ```
 
 8. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 7):
@@ -227,7 +241,7 @@ Detect user intent from their message, then follow the corresponding workflow:
       ```
    2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
       ```bash
-      tail -f dev-pipeline/state/pipeline-daemon.log
+      tail -f .prizmkit/state/features/pipeline-daemon.log
       ```
    3. Report to user:
       - Pipeline PID
@@ -247,14 +261,14 @@ Detect user intent from their message, then follow the corresponding workflow:
 2. **Show feature-level progress**:
    ```bash
    python3 dev-pipeline/scripts/update-feature-status.py \
-     --feature-list feature-list.json \
-     --state-dir dev-pipeline/state \
+     --feature-list .prizmkit/plans/feature-list.json \
+     --state-dir .prizmkit/state/features \
      --action status
    ```
 
 3. **Show recent log activity** (last 20 lines):
    ```bash
-   tail -20 dev-pipeline/state/pipeline-daemon.log
+   tail -20 .prizmkit/state/features/pipeline-daemon.log
    ```
 
 4. **Summarize** to user: total features, completed, in-progress, failed, pending.
@@ -286,20 +300,20 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
    ```bash
-   tail -f dev-pipeline/state/pipeline-daemon.log
+   tail -f .prizmkit/state/features/pipeline-daemon.log
    ```
 
 3. **If not running** -- Show last 50 lines:
    ```bash
-   tail -50 dev-pipeline/state/pipeline-daemon.log
+   tail -50 .prizmkit/state/features/pipeline-daemon.log
    ```
 
 4. **For per-feature session logs** (when user asks about a specific feature):
    ```bash
    # Check feature status for last session ID
-   cat dev-pipeline/state/features/<FEATURE_ID>/status.json 2>/dev/null
+   cat .prizmkit/state/features/features/<FEATURE_ID>/status.json 2>/dev/null
    # Then tail that feature's session log
-   tail -100 dev-pipeline/state/features/<FEATURE_ID>/sessions/<SESSION_ID>/logs/session.log
+   tail -100 .prizmkit/state/features/features/<FEATURE_ID>/sessions/<SESSION_ID>/logs/session.log
    ```
 
 ---
@@ -309,24 +323,23 @@ Detect user intent from their message, then follow the corresponding workflow:
 When user says "retry F-003":
 
 ```bash
-dev-pipeline/retry-feature.sh F-003 feature-list.json
+dev-pipeline/retry-feature.sh F-003 .prizmkit/plans/feature-list.json
 ```
 
 When user says "clean retry F-003" or "retry F-003 from scratch":
 
 ```bash
-dev-pipeline/reset-feature.sh F-003 --clean --run feature-list.json
+dev-pipeline/reset-feature.sh F-003 --clean --run .prizmkit/plans/feature-list.json
 ```
 
 Environment variables (optional):
 ```bash
-SESSION_TIMEOUT=3600 dev-pipeline/retry-feature.sh F-003 feature-list.json
+SESSION_TIMEOUT=3600 dev-pipeline/retry-feature.sh F-003 .prizmkit/plans/feature-list.json
 ```
 
 Notes:
-- `retry-feature.sh` runs exactly one feature session and exits. **It always performs a full clean** (deletes session history and `.prizmkit/specs/` artifacts) before retrying, ensuring a fresh start. This is destructive — prior session logs and spec artifacts for this feature will be deleted.
-- `reset-feature.sh --clean --run` is equivalent to a manual clean + retry (same behavior as `retry-feature.sh`, but can also operate on ranges and filtered sets).
-- For a lighter retry that preserves prior session artifacts, use `run-feature.sh run <F-XXX> --no-reset` instead.
+- `retry-feature.sh` runs exactly one feature session and exits. It **preserves prior session artifacts and checkpoint state** — reads `retry_count` and `resume_from_phase` from `status.json` so the AI session can resume from where it left off rather than starting from scratch.
+- `reset-feature.sh --clean --run` performs a full clean (deletes session history and artifacts) before retrying — use this for a fresh start when checkpoint recovery is not desired.
 - Keep pipeline daemon mode for main run management (`launch-feature-daemon.sh`).
 
 ---
@@ -339,7 +352,7 @@ After pipeline completion, if features have `browser_interaction` fields and `pl
    ```bash
    python3 -c "
    import json
-   with open('feature-list.json') as f:
+   with open('.prizmkit/plans/feature-list.json') as f:
        data = json.load(f)
    for feat in data.get('features', []):
        bi = feat.get('browser_interaction')
@@ -368,14 +381,14 @@ After pipeline completion, if features have `browser_interaction` fields and `pl
 
 | Error | Action |
 |-------|--------|
-| `feature-list.json` not found | Tell user to run `feature-planner` skill first |
+| `.prizmkit/plans/feature-list.json` not found | Tell user to run `feature-planner` skill first |
 | `jq` not installed | Suggest: `brew install jq` |
 | `cbc`/`claude` not in PATH | Check AI CLI installation |
 | Pipeline already running | Show status, ask if user wants to stop and restart |
 | PID file stale (process dead) | `launch-feature-daemon.sh` auto-cleans, retry start |
-| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 dev-pipeline/state/pipeline-daemon.log` |
+| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 .prizmkit/state/features/pipeline-daemon.log` |
 | Feature stuck/blocked | Use `retry-feature.sh <F-XXX>` to retry; use `reset-feature.sh <F-XXX> --clean --run` for fresh start |
-| All features blocked/failed | Show status, suggest daemon-safe recovery: `dev-pipeline/reset-feature.sh <F-XXX> --clean --run feature-list.json` |
+| All features blocked/failed | Show status, suggest daemon-safe recovery: `dev-pipeline/reset-feature.sh <F-XXX> --clean --run .prizmkit/plans/feature-list.json` |
 | `playwright-cli` not installed | Browser verification skipped (non-blocking). Suggest: `npm install -g @playwright/cli@latest && playwright-cli install --skills` |
 | Permission denied on script | Run `chmod +x dev-pipeline/launch-feature-daemon.sh dev-pipeline/run-feature.sh` |
 | Pipeline stop failed (process won't die) | Process may be stuck in I/O wait. Try `kill -9 <PID>` manually. Check for orphaned child processes with `ps aux \| grep claude` |
@@ -385,9 +398,9 @@ After pipeline completion, if features have `browser_interaction` fields and `pl
 
 ### Integration Notes
 
-- **After feature-planner**: This is the natural next step. When user finishes planning and has `feature-list.json`, suggest launching the pipeline.
+- **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 (`state/` vs `bugfix-state/`), so they can run simultaneously without conflict.
+- **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-pipeline-launcher/scripts/preflight-check.py

@@ -2,11 +2,11 @@
 """
 dev-pipeline environment preflight checker.
 
-Detects database type from feature-list.json / .prizmkit/config.json,
+Detects database type from .prizmkit/plans/feature-list.json / .prizmkit/config.json,
 verifies env vars, tests connectivity, and checks migration status.
 
 Usage:
-    python3 preflight-check.py [feature-list.json]
+    python3 preflight-check.py [.prizmkit/plans/feature-list.json]
 
 Output: PREFLIGHT lines to stdout (✓ / ⚠ / ℹ), JSON summary to stderr.
 Exit code: 0 = all clear, 1 = warnings found, 2 = error.
@@ -402,7 +402,7 @@ def check_dev_server(feature_list_path):
 # ── Main ────────────────────────────────────────────────────────
 
 def main():
-    feature_list = sys.argv[1] if len(sys.argv) > 1 else "feature-list.json"
+    feature_list = sys.argv[1] if len(sys.argv) > 1 else ".prizmkit/plans/feature-list.json"
 
     if not os.path.isfile(feature_list):
         print(f"PREFLIGHT ⚠ Feature list not found: {feature_list}")

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

@@ -1,15 +1,15 @@
 ---
 name: "feature-planner"
-description: "Plan and manage features for an existing project — add new features, reprioritize, split, and generate validated 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 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."
 ---
 
 # feature planner
 
 Plan deliverable features for dev-pipeline on existing projects:
-- **New Feature Set**: create an initial feature-list.json for a project that has code but no plan yet
+- **New Feature Set**: create an initial .prizmkit/plans/feature-list.json for a project that has code but no plan yet
 - **Incremental Feature Planning**: append, adjust, or reprioritize features in an existing plan
 
-Always produce a validated `feature-list.json` that conforms to `dev-pipeline-feature-list`.
+Always produce a validated `.prizmkit/plans/feature-list.json` that conforms to `dev-pipeline-feature-list`.
 
 For planning a **new application from scratch** (vision, tech stack, decomposition), use `app-planner` instead.
 
@@ -22,7 +22,7 @@ For planning a **new application from scratch** (vision, tech stack, decompositi
 
 If the user's request is about planning a new app from scratch (vision, tech stack selection, app architecture), recommend `app-planner` instead and ask the user to confirm before switching.
 
-If you believe the task is better suited for a different workflow (e.g., fast path via `/prizmkit-plan`), you MUST:
+If you believe the task is better suited for a different workflow, you MUST:
 1. **Explain why** you think a different path is more appropriate
 2. **Ask the user explicitly** whether they want to switch or continue with feature-planner
 3. **Only switch if the user confirms** — otherwise proceed with feature-planner as invoked
@@ -35,24 +35,23 @@ The user chose this skill intentionally. Respect that choice.
 - Create, modify, or delete source code files (*.js, *.ts, *.py, *.go, *.html, *.css, etc.)
 - Create project scaffolding, directories, or boilerplate
 - Run build/install/test commands (npm init, pip install, etc.)
-- Execute any implementation action beyond writing `feature-list.json`
+- Execute any implementation action beyond writing `.prizmkit/plans/feature-list.json`
 
 **Your ONLY writable outputs are:**
-1. `feature-list.json` (project root)
-2. Draft backups in `.prizmkit/planning/`
+1. `.prizmkit/plans/feature-list.json` (`.prizmkit/plans/`)
+2. Draft backups in `.prizmkit/plans/` (e.g., `feature-list.draft.json`)
 
 **After planning is complete**, you MUST:
-1. Present the summary and recommended next step
+1. Present the summary and recommended next step (invoking `feature-pipeline-launcher` )
 2. **Ask the user explicitly** whether they want to proceed to execution
-3. If the user agrees → recommend invoking `feature-pipeline-launcher` or running `run-feature.sh` (do NOT execute it yourself)
-4. If the user wants to adjust → continue refining `feature-list.json`
-5. **NEVER auto-execute** the pipeline, launcher, or any implementation step
+3. If the user wants to adjust → continue refining `.prizmkit/plans/feature-list.json`
+4. **NEVER auto-execute** the pipeline, launcher, or any implementation step
 
 ## When to Use
 
 Trigger this skill for requests like:
 - "Add features to existing system", "Continue planning"
-- "Prepare feature-list.json", "Prepare dev-pipeline input"
+- "Prepare .prizmkit/plans/feature-list.json", "Prepare dev-pipeline input"
 - "Reprioritize features", "Split features"
 - "Plan features for my project" (when the project already exists)
 
@@ -74,18 +73,16 @@ Do NOT use this skill when:
    - Browser interaction fields needed → read `${SKILL_DIR}/references/browser-interaction.md`
    - New feature set for a project (Route A) → read `${SKILL_DIR}/references/new-project-planning.md` for phase guide, quality rules, and delivery checklist
    - Feature decomposition from scratch → read `${SKILL_DIR}/references/decomposition-patterns.md` for common app patterns (CRUD, SaaS, Social, E-commerce)
+   - Phase 6 completeness review → read `${SKILL_DIR}/references/completeness-review.md`
 
-4. **Always validate output via script**:
-   ```bash
-   python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
-   ```
+4. **Always validate output via script** — see §Output Rules for the validation command.
    
    If the script is not available, perform these manual validation checks:
    1. **ID sequence**: All feature IDs are sequential (F-001, F-002, F-003, ...)
    2. **No circular dependencies**: No feature depends (directly or transitively) on itself
    3. **Description length**: Minimum 15 words per description (error), 30/50/80 recommended
    4. **Dependency references**: All referenced features in dependencies exist in features array
-   5. **Priority enums**: All priority values are exactly "high", "medium", or "low" (case-sensitive)
+   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 url, verify_steps array, and optional setup_command
@@ -101,22 +98,22 @@ Do NOT use this skill when:
 Before questions, check optional context files (never block if absent):
 - `.prizm-docs/root.prizm` (architecture/project context — typically created by app-planner with captured decisions)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
-- `project-brief.md` (project context from app-planner, if available)
-- existing `feature-list.json` (required for incremental mode)
-- `.prizmkit/project-conventions.json` (project conventions from app-planner, if available)
+- `.prizmkit/plans/project-brief.md` (project context from app-planner, if available)
+- existing `.prizmkit/plans/feature-list.json` (required for incremental mode)
+- `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions` section (project conventions from app-planner, if available)
 - If `.prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
   ```bash
   find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
   ```
 
 **Tech stack from config.json:**
-- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill `global_context` fields in the generated `feature-list.json`.
+- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill `global_context` fields in the generated `.prizmkit/plans/feature-list.json`.
 - Map config fields to global_context: `language`, `runtime`, `frontend_framework`, `frontend_styling`, `backend_framework`, `database`, `orm`, `testing` → `testing_strategy`, `bundler`, `project_type`.
 - Do NOT re-ask the user for tech stack info already present in config.json. Show detected stack and confirm.
 
 ## Global Context Population
 
-The `global_context` object in `feature-list.json` provides technology stack information to the pipeline for intelligent code generation.
+The `global_context` object in `.prizmkit/plans/feature-list.json` provides technology stack information. Populate it from `.prizmkit/config.json` if available, or ask the user during Phase 1.
 
 ### Recommended Fields by Project Type
 
@@ -136,37 +133,8 @@ The `global_context` object in `feature-list.json` provides technology stack inf
 - `language`, `frontend_framework`, `backend_framework`, `database`, `testing_strategy` (all recommended)
 - Additional: `frontend_styling`, `orm`, `bundler`, `runtime`
 
-### Auto-Population from app-planner
+All `global_context` fields are optional — including recommended fields improves downstream code generation quality. See `dev-pipeline/templates/feature-list-schema.json` for the full schema definition.
 
-If the project was planned with `app-planner`, `feature-planner` will automatically read:
-- `.prizmkit/config.json` (tech stack detected by app-planner)
-- `project-brief.md` (tech choices made during planning)
-- `.prizm-docs/root.prizm` (architecture decisions)
-
-**Recommendation**: Always run `app-planner` before `feature-planner` to ensure `global_context` is pre-populated correctly. This reduces planning time and improves code generation consistency.
-
-### Manual Population (if no app-planner context)
-
-If planning features directly without app-planner:
-1. During Phase 1 (Scope Clarification), identify the project's tech stack
-2. Ask user or read from existing `package.json` / `pyproject.toml` / `go.mod`
-3. Populate `global_context` in `feature-list.json` with detected values
-4. Confirm with user: "Using tech stack: [language] + [frameworks]. Correct?"
-
-### Pipeline Behavior with Missing Fields
-
-| Missing Field | Pipeline Behavior |
-|---------------|-------------------|
-| `language` | Uses generic pseudocode patterns; code generation may be generic |
-| `frontend_framework` | Frontend features generate generic HTML/JavaScript; no framework-specific patterns |
-| `backend_framework` | Backend features generate generic API patterns; no framework-specific scaffolding |
-| `database` | Assumes no persistent storage; generates unit tests only with mocks |
-| `testing_strategy` | Defaults to Jest (if JavaScript/TypeScript); pytest (if Python) |
-| All fields empty | Pipeline still works but code quality/consistency may suffer; recommend re-running with app-planner |
-
-### Note
-
-**global_context fields are all optional** — pipeline can execute without them. However, including the recommended fields dramatically improves code generation quality and framework-specific best practices.
 
 ---
 
@@ -175,19 +143,19 @@ If planning features directly without app-planner:
 Classify user intent first:
 
 ### Route A: New Feature Set (No Existing Plan)
-Use when the project exists but has no `feature-list.json` yet.
+Use when the project exists but has no `.prizmkit/plans/feature-list.json` yet.
 
 Actions:
 1. Understand the existing codebase and what's already implemented
 2. Run interactive planning phases to identify needed features
-3. Generate initial `feature-list.json`
+3. Generate initial `.prizmkit/plans/feature-list.json`
 
 ### Route B: Incremental Feature Planning
-Use when user already has a `feature-list.json` and wants to add or adjust features.
+Use when user already has a `.prizmkit/plans/feature-list.json` and wants to add or adjust features.
 
 Actions:
 1. Load `${SKILL_DIR}/references/incremental-feature-planning.md`
-2. Read existing `feature-list.json` first (if missing, ask whether to start new plan)
+2. Read existing `.prizmkit/plans/feature-list.json` first (if missing, ask whether to start new plan)
 3. Append features with next sequential `F-NNN` IDs
 4. Preserve style/language/detail consistency with existing plan
 
@@ -205,7 +173,7 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
    4.2 **Browser interaction** (mandatory for fullstack/frontend projects) — see §Browser Interaction Planning below. Qualifying features get `browser_interaction` by default. Only confirm with the user as a batch summary; do NOT ask per-feature.
 5. Verify DAG/order/priorities
 6. Pre-generation completeness review (see §Pre-Generation Completeness Review below)
-7. Build or append `feature-list.json`
+7. Build or append `.prizmkit/plans/feature-list.json`
 8. Apply default testing strategy (see §Testing Defaults below)
 9. Validate and fix until pass
 10. Summarize final feature table
@@ -222,53 +190,18 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-FP-3.1** | Browser Interaction Applied | Qualifying features have `browser_interaction` field; user confirmed or opted out | 4 |
 | **CP-FP-3.2** | Testing Defaults Applied | All features have appropriate `critic`, `critic_count`, and testing expectations | 7 |
 | **CP-FP-3.3** | Completeness Review Passed | All features reviewed for description adequacy and cross-feature gaps | 6 |
-| **CP-FP-4** | `feature-list.json` Generated | Schema validates, all required keys present | 7-8 |
+| **CP-FP-4** | `.prizmkit/plans/feature-list.json` Generated | Schema validates, all required keys present | 7-8 |
 | **CP-FP-5** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 9 |
 
 **Resume Detection**: If existing artifacts are found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
 ## Pre-Generation Completeness Review (Phase 6)
 
-Before generating `feature-list.json`, review the full feature set holistically. Individual features may look fine in isolation but have gaps when viewed together.
-
-### Step 1: Description Adequacy Scan
+Before generating `.prizmkit/plans/feature-list.json`, review the full feature set holistically.
 
-For each feature, evaluate against the word-count thresholds in `planning-guide.md` §4:
-- Does the description cover: what to build, key behaviors, integration points, data model (if applicable), error/edge cases?
-- Is the description specific enough for an AI coding session to implement without guessing?
-- Flag any feature below the recommended word count for its complexity level (30/50/80 words for low/medium/high).
-
-### Step 2: Cross-Feature Completeness Check
-
-Look at the feature set as a whole:
-- **Implied functionality gaps**: Does feature A's acceptance criteria assume a capability that no other feature provides?
-- **Missing integration seams**: If two features share data or interact at runtime, is the interface specified?
-- **Scope leaks**: Does any feature's description reference functionality outside the agreed scope?
-
-### Step 3: Present Review to User
-
-Show a structured summary table:
-
-```
-Feature    | Description | Cross-Feature        | Recommendation
-           | Adequacy    | Issues               |
-F-001      | ✓ (65 words)| —                    | Ready
-F-002      | ⚠ (28 words)| —                    | Expand: add API endpoints, error handling
-F-003      | ✓ (52 words)| Assumes email from   | Clarify: who sends the notification?
-           |             | F-006 (not yet defined)|
-```
+→ Read `${SKILL_DIR}/references/completeness-review.md` for the full review process (description adequacy scan, cross-feature completeness check, user presentation, and interactive supplementation).
 
-Then ask if any features need further discussion.
-
-### Step 4: Interactive Supplementation
-
-For each feature the user wants to discuss:
-1. Ask targeted questions about the unclear aspects
-2. Propose concrete description supplements
-3. Update the feature description with agreed details
-4. Re-check: does the supplement resolve the gap?
-
-Continue until the user confirms all features are implementation-ready. This gate exists because fixing thin descriptions here costs minutes; fixing misimplemented features downstream costs hours.
+This gate ensures all features are implementation-ready before output generation. Thin descriptions here cost minutes to fix; misimplemented features downstream cost hours.
 
 ## Fast Path (Simple Incremental)
 
@@ -283,7 +216,7 @@ For simple incremental planning, skip detailed Phase 2-3 analysis:
 - **No architectural changes** to existing tech stack
 
 ### Fast Path Workflow
-1. Read existing `feature-list.json` and confirm scope
+1. Read existing `.prizmkit/plans/feature-list.json` and confirm scope
 2. **User confirmation (mandatory)** — Tell the user: "This qualifies for fast-path (simple incremental addition). Skip detailed Phase 2-3 analysis and draft directly? Or use full workflow?" Only proceed with fast path if user confirms.
 3. Generate next sequential feature IDs
 4. Draft features (title + description + acceptance_criteria + dependencies)
@@ -314,39 +247,27 @@ A feature is **exempt** when ANY true:
 
 ## Output Rules
 
-`feature-list.json` must satisfy:
-- `$schema` = `dev-pipeline-feature-list-v1`
-- non-empty `features`
+`.prizmkit/plans/feature-list.json` must conform to `dev-pipeline/templates/feature-list-schema.json` (`$schema` = `dev-pipeline-feature-list-v1`).
+
+Key requirements:
+- non-empty `features` array
 - sequential feature IDs (`F-001`, `F-002`, ...)
-- valid dependency DAG
-- `priority` must be a string: `"high"`, `"medium"`, or `"low"` (NOT numeric)
+- valid dependency DAG (no cycles, all referenced IDs exist)
+- `priority`: `"critical"`, `"high"`, `"medium"`, or `"low"` (string, NOT numeric)
 - new items default `status: "pending"`
 - English feature titles for stable slug generation
-- `model` field is optional
-- `critic` field defaults based on priority: `true` for high/medium, `false` for low
-- `critic_count` field defaults: `3` for high priority, `1` for medium
-- `browser_interaction` field auto-generated for qualifying frontend features
-- descriptions must be implementation-ready — minimum 15 words (error), recommended 30/50/80 words for low/medium/high complexity (warning). See `planning-guide.md` §4.
-
-## Testing Defaults (Phase 8)
-
-All three testing mechanisms are enabled by default. The user can opt out.
+- `critic` / `critic_count` defaults per Testing Defaults section
+- `browser_interaction` auto-generated for qualifying frontend features
+- descriptions: minimum 15 words (error), recommended 30/50/80 for low/medium/high complexity (warning)
 
-### 1. Test File Generation (TDD)
-
-Every feature includes tests. In the feature description, state testing expectations:
-
-| Complexity | Default Testing Expectation |
-|------------|----------------------------|
-| low | Unit tests for core logic |
-| medium | Unit tests + integration tests for key flows |
-| high | Unit tests + integration tests + edge case coverage |
-
-### 2. Browser Verification (Playwright)
+Run the validation script after generation:
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
+```
 
-Default ON for all qualifying frontend features.
+## Testing Defaults (Phase 8)
 
-### 3. Adversarial Critic Review
+Set default testing-related fields for each feature. The user can opt out.
 
 | Priority | `critic` | `critic_count` | Rationale |
 |----------|----------|----------------|-----------|
@@ -354,23 +275,13 @@ Default ON for all qualifying frontend features.
 | medium | `true` | `1` | Single critic review |
 | low | `false` | (omitted) | Skip critic |
 
+For frontend features with `browser_interaction`, Playwright verification is enabled by default.
+
 Present a consolidated testing summary table at Phase 8, then ask for confirmation.
 
 ## Next-Step Execution Policy (after planning)
 
-Recommend these three options in this strict order:
-
-1. **Preferred**: invoke `feature-pipeline-launcher` skill
-2. **Fallback A**: run daemon wrapper
-   ```bash
-   ./dev-pipeline/launch-feature-daemon.sh start feature-list.json
-   ./dev-pipeline/launch-feature-daemon.sh status
-   ```
-3. **Fallback B**: run direct foreground script
-   ```bash
-   ./dev-pipeline/run-feature.sh run
-   ./dev-pipeline/run-feature.sh status
-   ```
+Recommend invoking `feature-pipeline-launcher` to configure and launch the dev-pipeline. Do NOT recommend running shell scripts directly — that is the launcher's responsibility.
 
 ## Error Recovery & Resume
 
@@ -380,7 +291,7 @@ Key behaviors:
 - Warnings only → proceed with user approval
 - Critical errors → group by type, auto-fix where possible, max 3 total attempts
 - Interrupted session → detect checkpoint from existing artifacts, offer resume or restart
-- `feature-list.json` MUST be written to project root (same level as `package.json` / `.git`)
+- `.prizmkit/plans/feature-list.json` MUST be written to `.prizmkit/plans/` (project root level: `./{root}/.prizmkit/plans/feature-list.json`)
 
 ## Session Exit Gate
 
@@ -388,16 +299,16 @@ Prevent accidental session exit without deliverable completion.
 
 ### Trigger Conditions
 Activate when ALL true:
-- User expressed intent to produce feature-list.json
+- User expressed intent to produce .prizmkit/plans/feature-list.json
 - Current phase < Phase 7
-- No valid `feature-list.json` written in this session
+- No valid `.prizmkit/plans/feature-list.json` written in this session
 
 ### Gate Behavior
 When the session appears to be ending:
-1. **Remind**: "You set out to produce `feature-list.json` but we haven't completed it yet."
+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 draft
+   - **(b) Save draft & exit** — write current progress as `feature-list.draft.json` to `.prizmkit/plans/`
    - **(c) Abandon** — exit without saving
 
 ## Handoff Message Template

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

@@ -12,7 +12,7 @@ Requires npm setup:
 
 ```bash
 npm run skill:review -- \
-  --workspace /.codebuddy/skill-evals/feature-planner-workspace \
+  --workspace .prizmkit/skill-evals/feature-planner-workspace \
   --iteration iteration-N \
   --skill-name feature-planner \
   --skill-path ${SKILL_DIR} \