prizmkit 1.1.1 → 1.1.3

package/bundled/skills/{dev-pipeline-launcher → feature-pipeline-launcher}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "dev-pipeline-launcher"
+name: "feature-pipeline-launcher"
 description: "Launch and manage the dev-pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start building features, run the pipeline, check pipeline progress, retry features, or stop the pipeline. Trigger on: 'run pipeline', 'start pipeline', 'start building', 'pipeline status', 'stop pipeline', 'retry feature', 'launch pipeline', 'start implementing', 'check pipeline status', 'stop the pipeline'. (project)"
 ---
 
@@ -11,8 +11,8 @@ Launch the autonomous development pipeline from within an AI CLI conversation. T
 
 Three execution modes are available. The user chooses one before configuring other options:
 
-1. **Foreground** (recommended) — `dev-pipeline/run.sh run`. Visible output, direct error feedback, no orphaned processes.
-2. **Background daemon** — `dev-pipeline/launch-daemon.sh`. Runs fully detached, survives AI CLI session closure.
+1. **Foreground** (recommended) — `dev-pipeline/run-feature.sh run`. Visible output, direct error feedback, no orphaned processes.
+2. **Background daemon** — `dev-pipeline/launch-feature-daemon.sh`. Runs fully detached, survives AI CLI session closure.
 3. **Manual** — Display the assembled command(s) only. Do not execute anything. User runs them on their own.
 
 ### When to Use
@@ -21,7 +21,7 @@ Three execution modes are available. The user chooses one before configuring oth
 - "run pipeline", "start pipeline", "start building", "launch dev-pipeline"
 - "run the features", "execute feature list", "start implementing"
 - "launch pipeline", "run the pipeline", "start auto-development"
-- After app-planner completes: "build it", "start developing from the feature list"
+- After feature-planner completes: "build it", "start developing from the feature list"
 - "run only F-001 to F-005", "run features F-001,F-003", "only build these features"
 
 **Check status** -- User says:
@@ -40,7 +40,7 @@ Three execution modes are available. The user chooses one before configuring oth
 - "retry F-003", "retry this feature", "retry this node", "re-run this feature"
 
 **Do NOT use this skill when:**
-- User wants to plan features (use `app-planner` instead)
+- User wants to plan features (use `feature-planner` instead)
 - User wants to implement a single feature manually within current session (use `prizmkit-implement`)
 - User wants to define specs/plan (use `prizmkit-plan`)
 
@@ -48,7 +48,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-daemon.sh` is present and executable
+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)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 4. **Python version**: Requires Python 3.8+ for dev-pipeline scripts
@@ -62,7 +62,7 @@ command -v playwright-cli && echo "playwright-cli OK" || echo "playwright-cli no
 ```
 
 If `feature-list.json` is missing, inform user:
-> "No feature-list.json found. Run the `app-planner` skill first to generate one, or provide a path to your feature list."
+> "No feature-list.json found. Run the `feature-planner` skill first to generate one, or provide a path to your feature list."
 
 ### Workflow
 
@@ -79,7 +79,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 2. **Check not already running**:
    ```bash
-   dev-pipeline/launch-daemon.sh status 2>/dev/null
+   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
    ```
    If running, inform user and ask: "Pipeline is already running. Want to restart it, check status, or view logs?"
 
@@ -129,8 +129,8 @@ Detect user intent from their message, then follow the corresponding workflow:
 5. **Ask execution mode** (first user decision):
 
    Present the three modes and ask the user to choose:
-   - **(1) Foreground** (recommended) — pipeline runs in the current session via `run.sh run`. Visible output and direct error feedback.
-   - **(2) Background daemon** — pipeline runs fully detached via `launch-daemon.sh`. Survives AI CLI session closure.
+   - **(1) Foreground** (recommended) — pipeline runs in the current session via `run-feature.sh run`. Visible output and direct error feedback.
+   - **(2) Background daemon** — pipeline runs fully detached via `launch-feature-daemon.sh`. Survives AI CLI session closure.
    - **(3) Manual** — display the final assembled commands only. Do not execute anything. User runs them on their own.
 
 6. **Ask configuration options** ⚠️ MANDATORY INTERACTIVE STEP — applies to ALL execution modes (Foreground, Background, AND Manual). You MUST ask the user to configure options and WAIT for their response BEFORE proceeding to step 7. Do NOT skip this step or merge it with step 7.
@@ -169,8 +169,6 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Verbose: On | `VERBOSE=1` |
    | Max retries: N | `MAX_RETRIES=N` |
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
-   | "skip browser verify" | `BROWSER_VERIFY=false` |
-   | "enable browser verify" | `BROWSER_VERIFY=true` |
 
    ⚠️ STOP HERE and wait for user response before continuing to step 7.
 
@@ -178,34 +176,34 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Foreground command:**
    ```bash
-   VERBOSE=1 dev-pipeline/run.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run-feature.sh run feature-list.json
    ```
    With all options:
    ```bash
    VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 \
-     dev-pipeline/run.sh run feature-list.json --features F-001:F-005
+     dev-pipeline/run-feature.sh run feature-list.json --features F-001:F-005
    ```
 
    **Background daemon command:**
    ```bash
-   dev-pipeline/launch-daemon.sh start feature-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-feature-daemon.sh start feature-list.json --env "VERBOSE=1"
    ```
    With all options:
    ```bash
-   dev-pipeline/launch-daemon.sh start feature-list.json --features F-001:F-005 \
+   dev-pipeline/launch-feature-daemon.sh start 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.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run-feature.sh run feature-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-daemon.sh start feature-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-feature-daemon.sh start feature-list.json --env "VERBOSE=1"
 
    # To check status:
-   dev-pipeline/run.sh status feature-list.json
+   dev-pipeline/run-feature.sh status feature-list.json
    ```
 
 8. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 7):
@@ -225,7 +223,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    **If background daemon**:
    1. Verify launch:
       ```bash
-      dev-pipeline/launch-daemon.sh status
+      dev-pipeline/launch-feature-daemon.sh status
       ```
    2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
       ```bash
@@ -243,7 +241,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check daemon status**:
    ```bash
-   dev-pipeline/launch-daemon.sh status
+   dev-pipeline/launch-feature-daemon.sh status
    ```
 
 2. **Show feature-level progress**:
@@ -267,12 +265,12 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Stop the daemon**:
    ```bash
-   dev-pipeline/launch-daemon.sh stop
+   dev-pipeline/launch-feature-daemon.sh stop
    ```
 
 2. **Verify stopped**:
    ```bash
-   dev-pipeline/launch-daemon.sh status 2>/dev/null || true
+   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null || true
    ```
 
 3. **Inform user**: "Pipeline stopped. State is preserved -- you can resume later with 'start pipeline' and it will pick up where it left off."
@@ -283,7 +281,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check if running**:
    ```bash
-   dev-pipeline/launch-daemon.sh status 2>/dev/null
+   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
    ```
 
 2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
@@ -326,9 +324,10 @@ SESSION_TIMEOUT=3600 dev-pipeline/retry-feature.sh F-003 feature-list.json
 ```
 
 Notes:
-- `retry-feature.sh` runs exactly one feature session and exits.
-- `reset-feature.sh --clean --run` clears the feature state before retrying (fresh start).
-- Keep pipeline daemon mode for main run management (`launch-daemon.sh`).
+- `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.
+- Keep pipeline daemon mode for main run management (`launch-feature-daemon.sh`).
 
 ---
 
@@ -353,7 +352,7 @@ After pipeline completion, if features have `browser_interaction` fields and `pl
 
 3. **If yes**, for each qualifying feature:
    - Start dev server if `setup_command` is specified
-   - Use `playwright-cli` to open the URL, execute `verify_steps`, and take a screenshot
+   - Use `playwright-cli snapshot` to discover element refs, then verify each goal in `verify_steps` using appropriate actions, and take a screenshot
    - Close browser and stop dev server
 
 4. **Report results**:
@@ -369,23 +368,24 @@ After pipeline completion, if features have `browser_interaction` fields and `pl
 
 | Error | Action |
 |-------|--------|
-| `feature-list.json` not found | Tell user to run `app-planner` skill first |
+| `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-daemon.sh` auto-cleans, retry start |
+| 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` |
 | 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` |
 | `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-daemon.sh dev-pipeline/run.sh` |
+| 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` |
 | `.env.local` missing or incomplete | Warn: database connection variables not found. Suggest creating env file with required connection variables for the project's database |
 | Database unreachable | Warn: database features will produce mock-only tests. Suggest checking database service status and connection credentials |
 | Migrations not applied | Warn: tables or schema referenced in migration files not found in database. Suggest applying pending migrations |
 
 ### Integration Notes
 
-- **After app-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 `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.

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

@@ -0,0 +1,337 @@
+---
+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."
+---
+
+# 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
+- **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`.
+
+For planning a **new application from scratch** (vision, tech stack, decomposition), use `app-planner` instead.
+
+## Invocation Commitment (Hard Rule)
+
+**When the user invokes `/feature-planner`, you MUST execute the feature-planner workflow.** You must NEVER:
+- Decide on the user's behalf that the task "doesn't need feature-planner"
+- Skip feature-planner to jump directly to spec/plan/implement or any other skill
+- Bypass the interactive phases because you judge the task to be "simple" or "obvious"
+
+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:
+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
+
+The user chose this skill intentionally. Respect that choice.
+
+## Scope Boundary (Hard Rule)
+
+**This skill is PLANNING ONLY.** You must NEVER:
+- 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`
+
+**Your ONLY writable outputs are:**
+1. `feature-list.json` (project root)
+2. Draft backups in `.prizmkit/planning/`
+
+**After planning is complete**, you MUST:
+1. Present the summary and recommended next step
+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
+
+## When to Use
+
+Trigger this skill for requests like:
+- "Add features to existing system", "Continue planning"
+- "Prepare feature-list.json", "Prepare dev-pipeline input"
+- "Reprioritize features", "Split features"
+- "Plan features for my project" (when the project already exists)
+
+Do NOT use this skill when:
+- The user wants to plan a new app from scratch → use `app-planner`
+- The user only wants to run the pipeline → use `feature-pipeline-launcher`
+- The user is debugging/refactoring or wants to write source code directly
+
+## Resource Loading Rules (Mandatory)
+
+1. **Planning reference** — load before writing feature descriptions:
+   - Read `${SKILL_DIR}/assets/planning-guide.md` for description writing standards, acceptance criteria patterns, complexity estimation, dependency rules, and session granularity
+
+2. **Incremental planning reference** — load for incremental mode:
+   - Read `${SKILL_DIR}/references/incremental-feature-planning.md`
+
+3. **Load on-demand references when triggered**:
+   - Validation errors or interrupted session → read `${SKILL_DIR}/references/error-recovery.md`
+   - 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)
+
+4. **Always validate output via script**:
+   ```bash
+   python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
+   ```
+
+5. **Use script output as source of truth** — if validation fails, fix and re-run until pass
+
+## Prerequisites
+
+Before questions, check optional context files (never block if absent):
+- `.prizm-docs/root.prizm` (architecture/project context)
+- `.prizmkit/config.json` (existing stack preferences and detected tech stack)
+- existing `feature-list.json` (required for incremental mode)
+- 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`.
+- 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.
+
+## Scenario Routing
+
+Classify user intent first:
+
+### Route A: New Feature Set (No Existing Plan)
+Use when the project exists but has no `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`
+
+### Route B: Incremental Feature Planning
+Use when user already has a `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)
+3. Append features with next sequential `F-NNN` IDs
+4. Preserve style/language/detail consistency with existing plan
+
+## Core Workflow
+
+Execute the planning workflow in conversation mode with mandatory checkpoints:
+
+### Interactive Phases
+1. Clarify scope and goals
+   1.1 **Requirement clarification** — for ANY unclear aspect of the user's goals or scope, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand. No limit on rounds. Do not proceed to Phase 2 with unresolved ambiguities.
+2. Confirm constraints and existing architecture
+3. Propose feature set with dependencies
+4. Refine descriptions and acceptance criteria
+   4.1 **Per-feature clarification** — for each feature, if the description, acceptance criteria, or scope is vague or could be interpreted multiple ways, ask the user to clarify before finalizing.
+   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`
+8. Apply default testing strategy (see §Testing Defaults below)
+9. Validate and fix until pass
+10. Summarize final feature table
+
+### Checkpoints (Mandatory Gates)
+
+Checkpoints catch cascading errors early — skipping one means the next phase builds on unvalidated assumptions, which compounds into much harder debugging later.
+
+| Checkpoint | Artifact/State | Criteria | Phase |
+|-----------|----------------|----------|-------|
+| **CP-FP-1** | Scope Confirmed | User confirmed what features to plan and context understood | 1 |
+| **CP-FP-2** | Feature Proposals | Feature set with titles+deps identified (pre-validation) | 3-5 |
+| **CP-FP-3** | DAG Validity | No cycles, dependencies resolved (validation dry-run) | 5 |
+| **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-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
+
+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)|
+```
+
+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.
+
+## Fast Path (Simple Incremental)
+
+For simple incremental planning, skip detailed Phase 2-3 analysis:
+
+### Eligibility Criteria (ALL must apply)
+- **Incremental mode only** — not new feature set
+- **Adding 1-2 features max** to existing plan
+- **Each feature**: ≤5 acceptance criteria, <100 words description
+- **Dependencies**: depends on ≤2 existing features (no chains)
+- **Complexity**: "low" or "medium" only
+- **No architectural changes** to existing tech stack
+
+### Fast Path Workflow
+1. Read existing `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)
+5. Run validation script immediately
+6. If valid → summarize and recommend next step
+7. If invalid → apply fixes, re-validate (max 2 attempts, then escalate to full workflow)
+
+## Browser Interaction Planning
+
+For fullstack/frontend projects, qualifying features get `browser_interaction` **by default**.
+
+### Auto-Detection Rule
+
+A feature **qualifies** when ALL true:
+1. `global_context.frontend_framework` exists
+2. The feature's `acceptance_criteria` contain UI-related keywords: click, button, modal, page, form, display, navigate, tab, input, opens, shows, renders, visible, redirect, download, upload, preview, select, toggle, dropdown, popup, toast, menu
+
+A feature is **exempt** when ANY true:
+- Backend-only (API endpoints, database migrations, no UI criteria)
+- Config/setup/infrastructure
+- `status: "completed"` (already implemented)
+
+### Default Behavior (Phase 4.2)
+
+1. **Auto-generate** `browser_interaction` for ALL qualifying features. Read `${SKILL_DIR}/references/browser-interaction.md` for the object format and field rules.
+2. **Present a summary** to the user showing which features received `browser_interaction`.
+3. **User can opt-OUT** specific features.
+
+## Output Rules
+
+`feature-list.json` must satisfy:
+- `$schema` = `dev-pipeline-feature-list-v1`
+- non-empty `features`
+- sequential feature IDs (`F-001`, `F-002`, ...)
+- valid dependency DAG
+- `priority` must be a string: `"high"`, `"medium"`, or `"low"` (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.
+
+### 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)
+
+Default ON for all qualifying frontend features.
+
+### 3. Adversarial Critic Review
+
+| Priority | `critic` | `critic_count` | Rationale |
+|----------|----------|----------------|-----------|
+| high | `true` | `3` | Multi-critic voting |
+| medium | `true` | `1` | Single critic review |
+| low | `false` | (omitted) | Skip critic |
+
+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
+   ```
+
+## Error Recovery & Resume
+
+If validation fails or a session is interrupted → read `${SKILL_DIR}/references/error-recovery.md` for the full error type table, decision tree, retry logic, and checkpoint-based resume support.
+
+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`)
+
+## Session Exit Gate
+
+Prevent accidental session exit without deliverable completion.
+
+### Trigger Conditions
+Activate when ALL true:
+- User expressed intent to produce feature-list.json
+- Current phase < Phase 7
+- No valid `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."
+2. **Offer 3 options**:
+   - **(a) Continue to completion**
+   - **(b) Save draft & exit** — write current progress as draft
+   - **(c) Abandon** — exit without saving
+
+## Handoff Message Template
+
+After successful validation, report:
+1. Output file path
+2. Total features + newly added features
+3. Dependency and priority highlights
+4. Recommended next action: `feature-pipeline-launcher`

package/bundled/skills/{app-planner → feature-planner}/assets/evaluation-guide.md

@@ -1,6 +1,6 @@
-# App Planner Evaluation Guide
+# feature planner Evaluation Guide
 
-This guide is for maintainers who evaluate and iterate on the `app-planner` skill quality.
+This guide is for maintainers who evaluate and iterate on the `feature-planner` skill quality.
 
 ## Evaluation & Quality Gates (Optional but Recommended)
 
@@ -12,9 +12,9 @@ Requires npm setup:
 
 ```bash
 npm run skill:review -- \
-  --workspace /.codebuddy/skill-evals/app-planner-workspace \
+  --workspace /.codebuddy/skill-evals/feature-planner-workspace \
   --iteration iteration-N \
-  --skill-name app-planner \
+  --skill-name feature-planner \
   --skill-path ${SKILL_DIR} \
   --runs 3 \
   --grader-cmd "python3 ${SKILL_DIR}/scripts/validate-and-generate.py grade --workspace {workspace} --iteration {iteration}"