prizmkit 1.1.79 → 1.1.80

package/bundled/skills/app-planner/references/project-state-detection.md

@@ -0,0 +1,88 @@
+# Project State Detection — Brownfield Behavior
+
+Detailed procedures for detecting and handling existing (brownfield) projects during app planning.
+
+## Detection Signals
+
+| Signal | Greenfield | Brownfield |
+|--------|-----------|------------|
+| `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / `pom.xml` | absent | present |
+| `src/` or `app/` directory with source files | absent | present |
+| `.git` with commit history | absent or initial commit only | present with history |
+| Empty or near-empty directory | yes | no |
+
+## Greenfield Behavior (default)
+
+Proceed with the standard Core Workflow — ask all questions from scratch.
+
+## Brownfield Behavior
+
+When an existing project is detected:
+
+### Step 1: Prerequisite Check (Mandatory)
+
+Before ANY planning work, check if AI-essential project context files exist:
+
+| File | Purpose | Status |
+|------|---------|--------|
+| `.prizmkit/prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
+| `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
+| `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
+
+**If ANY are missing**, show the status table, then use `AskUserQuestion`:
+
+**Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
+- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
+- **Continue without init** — I'll scan the project manually during this session (less thorough)
+- **Skip, I'll set these up later** — proceed with planning using only what's available
+
+- **Run project init first** -> Invoke `prizmkit-init`, then resume app-planner from where it left off
+- **Continue without init** -> Continue with Step 2 below (manual scan)
+- **Skip** -> Continue with Step 3, skip scanning
+
+### Step 2: Proactive Project Scanning
+
+Do NOT ask the user to describe their project — read it yourself first:
+
+1. **Scan project 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'
+   ```
+
+2. **Read existing project metadata** to infer tech stack and purpose:
+   - `package.json` -> name, description, dependencies, scripts
+   - `pyproject.toml` / `requirements.txt` -> Python dependencies
+   - `go.mod` -> Go module info
+   - `README.md` -> project description and goals
+   - `.prizmkit/config.json` -> previously detected tech stack
+   - `.prizmkit/prizm-docs/root.prizm` -> existing architecture context
+
+3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
+
+### Step 3: Present Inferred Summary with Confirmation
+
+Show the summary as text, then use `AskUserQuestion`:
+
+> Based on my analysis of your codebase:
+>
+> **Project**: [name] — [inferred description]
+> **Tech Stack**: [framework] + [language] + [key dependencies]
+> **Key Features Found**: [list 3-5 detected capabilities]
+> **Architecture**: [e.g., monolithic, microservices, serverless]
+
+**Question**: "Does this look correct?"
+- **Yes, looks correct (Recommended)** — proceed with planning
+- **Mostly correct, with changes** — I'll note corrections
+- **This is off** — let me describe the project
+
+### Step 4: Pre-fill and Focus
+
+- Phase 2 tech stack selection -> largely pre-filled from dependencies
+- Vision/problem statement -> inferred from README or package description (user confirms)
+- Existing features -> note them as `[x]` items in project brief
+
+**Focus remaining questions** (as options where possible) on what CANNOT be inferred:
+- Target users and core value proposition
+- Future direction and planned capabilities
+- Non-functional requirements (performance, scale, security)
+- Design direction (for frontend projects)

package/bundled/skills/app-planner/references/rules-configuration.md

@@ -0,0 +1,46 @@
+# Rules Configuration — Detailed Q&A Procedures
+
+Procedural details for configuring per-layer development rules during app planning. SKILL.md retains Steps 1-3 and 5 (flow control); this file contains Step 4's full Q&A workflow.
+
+## Step 4: Configure Each Selected Layer — Full Q&A Workflow
+
+For each selected layer, run the 4-phase rule generation pattern:
+
+### Phase A — Load Layer Resources
+
+- Read `${SKILL_DIR}/references/rules/<layer>/fixed-rules.md` — industry-consensus rules injected without asking
+- Read `${SKILL_DIR}/references/rules/<layer>/question-bank.md` — interactive questions organized in groups (G1->G10): authoritative source for question text, options, "Recommended" markers, and Notes
+- Read `${SKILL_DIR}/references/rules/<layer>/question-manifest.json` — machine-readable structure for this layer. **This is your asking checklist.** It lists, per question: `group`, `required`, `maps_to` (which template placeholders the answer fills), and conditional fields (`required_if`, `auto_derived_when`, `options_vary_by`). Its `groups[]` carries each group's `quick_mode` flag, and `template_placeholders` is the expected-set for the Phase D self-check. Use the manifest to track coverage; use question-bank.md for the actual wording you present to the user. If a question id in one file is absent from the other, trust question-bank.md for content and note the drift.
+
+### Phase B — Interactive Q&A
+
+- Ask questions one group at a time (max 3 questions per message), as defined in question-bank.md
+- Each question shows a "Recommended" option to reduce decision cost
+- **Quick mode**: ask only the groups whose `quick_mode` is `true` in `question-manifest.json`. All other groups adopt recommended defaults silently. (The manifest is the single source of truth for quick-mode membership — do not hardcode group lists here.)
+- **Full mode**: ask all groups in manifest order (`groups[]`).
+- **Conditional questions** (driven by the manifest's per-question fields):
+  - `required_if: "<expr>"` — ask this question only when the expression over prior answers holds (e.g. Q14 `required_if: Q13 != D`). If the condition is false, the question is legitimately skipped — not a coverage gap.
+  - `auto_derived_when: "<expr>"` — when this holds, fill the mapped placeholder(s) from the prior answer without asking (e.g. backend Q6 `auto_derived_when: Q5 in [GraphQL, gRPC]`). Count as satisfied, not skipped.
+  - `options_vary_by: "<Qid>"` — the question is still asked; only its option list depends on that prior answer (e.g. framework/ORM options vary by language). Never affects whether the question is required.
+- Shortcut commands work at any point:
+  - `recommended` / `default` -> adopt all recommended for current group
+  - `all recommended` -> adopt all recommended for all remaining groups
+  - `skip` -> mark current group as "Not required at this stage"
+- Record answers in memory after each group. Track which manifest questions are answered, auto-derived, or conditionally skipped so Phase D can verify coverage.
+
+### Phase C — Auto-derivation
+
+- Read `${SKILL_DIR}/references/rules/<layer>/derivation-rules.md`
+- Match user answers against the trigger map using keyword matching
+- Derive platform-specific rules without asking the user (e.g., choosing Flutter -> auto-inject Flutter widget/persistence/navigation rules)
+
+### Phase D — Render and Write
+
+- Read `${SKILL_DIR}/references/rules/<layer>/template.md`
+- Fill all template placeholders with accumulated content from Phases A+B+C
+- **Post-render self-check** (driven by `question-manifest.json` -> `template_placeholders`):
+  1. **Coverage pass** — for every placeholder in `from_questions`, confirm it traces to an answered question OR an `auto_derived_when` path OR a conditionally-skipped question (`required_if` false). If a `from_questions` placeholder has no source, you skipped a required question — go back and ask it before writing.
+  2. **Residual pass** — scan the rendered document for any residual `{{ ` or ` }}`; count must be 0. Placeholders in `from_fixed_rules` / `auto_generated` / `metadata` are filled from fixed-rules.md, Phase D generation, and project metadata respectively — they are NOT expected to come from Q&A, but they MUST still be rendered (no residual braces).
+- Generate Appendix A (Deny List) and Appendix B (Recommended Tools) per template instructions — these fill the `auto_generated` placeholders
+- Create `.prizmkit/rules/` directory if it doesn't exist
+- Write `.prizmkit/rules/<layer>-rules.md`

package/bundled/skills/bug-fix-workflow/SKILL.md

@@ -95,36 +95,7 @@ For trivial bugs with clear root cause and minimal scope:
 
 #### Step 1.2: Systematic Bug Clarification
 
-Ask questions across these dimensions until every aspect is clear. **Adapt to what the user has already provided** — skip questions that are already answered.
-
-**Reproduction Conditions:**
-- What exact steps trigger the bug? (step-by-step)
-- Which environment/browser/OS/version?
-- Is it reproducible every time, or intermittent?
-- When did it first appear? (after a specific change/deploy?)
-- Does it happen for all users or only specific accounts/roles/data?
-
-**Expected vs Actual Behavior:**
-- What should happen? (the correct behavior)
-- What actually happens? (the buggy behavior)
-- Is there partial functionality (e.g., works for some inputs but not others)?
-
-**Scope and Impact:**
-- Which features/pages/modules are affected?
-- Are there workarounds users are currently using?
-- Is this blocking other work?
-- Are there related symptoms elsewhere?
-
-**Data and State:**
-- What data/state triggers the issue? (specific input values, DB state, user session state)
-- Does the bug involve data corruption or just incorrect display/behavior?
-- If database-related: which tables/records are affected?
-
-**Error Details** (if not already provided):
-- Full error message and stack trace?
-- Browser console errors?
-- Server-side logs?
-- Network request/response details?
+Read `${SKILL_DIR}/references/bug-diagnosis.md` for the full question framework — reproduction conditions, expected vs actual behavior, scope/impact, data/state, and error details. Adapt to what the user has already provided; skip answered questions.
 
 #### Step 1.3: Confirmation Before Triage
 

package/bundled/skills/bug-fix-workflow/references/bug-diagnosis.md

@@ -0,0 +1,66 @@
+# Bug Diagnosis — Question Framework
+
+Procedural details for systematic bug clarification in bug-fix-workflow Phase 1.
+
+## Step 1.2: Systematic Bug Clarification
+
+Ask questions across these dimensions until every aspect is clear. **Adapt to what the user has already provided** — skip questions that are already answered.
+
+### Reproduction Conditions
+- What exact steps trigger the bug? (step-by-step)
+- Which environment/browser/OS/version?
+- Is it reproducible every time, or intermittent?
+- When did it first appear? (after a specific change/deploy?)
+- Does it happen for all users or only specific accounts/roles/data?
+
+### Expected vs Actual Behavior
+- What should happen? (the correct behavior)
+- What actually happens? (the buggy behavior)
+- Is there partial functionality (e.g., works for some inputs but not others)?
+
+### Scope and Impact
+- Which features/pages/modules are affected?
+- Are there workarounds users are currently using?
+- Is this blocking other work?
+- Are there related symptoms elsewhere?
+
+### Data and State
+- What data/state triggers the issue? (specific input values, DB state, user session state)
+- Does the bug involve data corruption or just incorrect display/behavior?
+- If database-related: which tables/records are affected?
+
+### Error Details (if not already provided)
+- Full error message and stack trace?
+- Browser console errors?
+- Server-side logs?
+- Network request/response details?
+
+## Complexity Assessment
+
+### Simple bug → Fast Path candidate (ALL must be true)
+- Root cause is immediately obvious (typo, missing null check, wrong variable name, off-by-one)
+- Fix is ≤10 lines of code in a single file
+- No cross-module impact
+- Existing tests cover the affected path (or bug is in untested utility)
+- No data model or API changes
+
+### Complex bug → Planning Path (ANY is true)
+- Cross-module impact (>2 files affected)
+- Data model or API changes required
+- Root cause is uncertain or multi-layered
+- Fix requires structural changes
+- Multiple interrelated symptoms
+
+## Comparison with Pipeline Bug Fix
+
+| Dimension | bug-fix-workflow | bugfix-pipeline-launcher |
+|-----------|-------------------|----------------------------|
+| Scope | One bug at a time | All bugs in batch |
+| Execution | Interactive, in-session | Foreground or background daemon |
+| Diagnosis | Deep interactive Q&A with user | Automated from bug description |
+| Branch | Creates `fix/<BUG_ID>-*` branch | Pipeline manages branches |
+| Visibility | Full user interaction at each phase | Async, check status periodically |
+| User verification | Yes (Phase 6) | No (automated) |
+| Best for | Complex bugs needing user input | Batch of well-defined bugs |
+| Artifacts | Same (fix-plan.md + fix-report.md) | Same |
+| Commit prefix | `fix(<scope>):` | `fix(<scope>):` |

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

@@ -180,33 +180,8 @@ Detect user intent from their message, then follow the corresponding workflow:
    - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
    - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
 
-   **Environment variable mapping** (for translating user responses → env vars):
-
-   | Config choice | Environment variable |
-   |-----------|---------------------|
-   | Verbose: Off | `VERBOSE=0` |
-   | Verbose: On | `VERBOSE=1` |
-   | Max retries: N | `MAX_RETRIES=N` |
-   | Critic: On | `ENABLE_CRITIC=true` |
-   | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
-   | Stop on failure: On | `STOP_ON_FAILURE=1` |
-   | Deploy: Yes | `ENABLE_DEPLOY=1` |
-   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
-
-   **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 bug fix (`1` to enable) |
-   | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `bugfix/pipeline-{run_id}`) |
-   | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
-   | `HEARTBEAT_STALE_THRESHOLD` | `600` | Max seconds without heartbeat before marking stale |
-   | `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 6.
+   **Environment variable mapping** and **advanced environment variables** tables — read `${SKILL_DIR}/references/configuration.md` for the full translation tables (8 config→env mappings + 8 advanced variables).
+
 
 6. **Show final command**: Assemble the complete command from execution mode + confirmed configuration, and present it to the user.
 
@@ -351,19 +326,7 @@ When user says "retry B-001":
 
 ### Error Handling
 
-| Error | Action |
-|-------|--------|
-| `.prizmkit/plans/bug-fix-list.json` not found | Tell user to run `bug-planner` skill first |
-| `jq` not installed | Suggest: `brew install jq` |
-| `cbc`/`claude` not in PATH | Check AI CLI installation |
-| Bugfix pipeline already running | Show status, ask if user wants to stop and restart |
-| PID file stale (process dead) | `launch-bugfix-daemon.sh` auto-cleans, retry start |
-| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 .prizmkit/state/bugfix/pipeline-daemon.log` |
-| All bugs blocked/failed/needs-info | Show status, suggest retrying 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`. |
-| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-bugfix-daemon.sh .prizmkit/dev-pipeline/run-bugfix.sh` |
+Read `${SKILL_DIR}/references/configuration.md` for the full error handling table (11 entries).
 
 ### Integration Notes
 

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

@@ -0,0 +1,49 @@
+# Configuration Reference — Bugfix Pipeline Launcher
+
+Environment variable mappings for the bugfix launcher.
+
+## Environment Variable Mapping
+
+Translating user responses to env vars:
+
+| Config choice | Environment variable |
+|-----------|---------------------|
+| Verbose: Off | `VERBOSE=0` |
+| Verbose: On | `VERBOSE=1` |
+| Max retries: N | `MAX_RETRIES=N` |
+| Critic: On | `ENABLE_CRITIC=true` |
+| Timeout: value | `SESSION_TIMEOUT=<seconds>` |
+| Stop on failure: On | `STOP_ON_FAILURE=1` |
+| Deploy: Yes | `ENABLE_DEPLOY=1` |
+| Effort: value | `PRIZMKIT_EFFORT=<value>` |
+
+## 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 bug fix (`1` to enable) |
+| `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `bugfix/pipeline-{run_id}`) |
+| `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
+| `HEARTBEAT_STALE_THRESHOLD` | `600` | Max seconds without heartbeat before marking stale |
+| `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 |
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| `.prizmkit/plans/bug-fix-list.json` not found | Tell user to run `bug-planner` skill first |
+| `jq` not installed | Suggest: `brew install jq` |
+| `cbc`/`claude` not in PATH | Check AI CLI installation |
+| Bugfix pipeline already running | Show status, ask if user wants to stop and restart |
+| PID file stale (process dead) | `launch-bugfix-daemon.sh` auto-cleans, retry start |
+| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 .prizmkit/state/bugfix/pipeline-daemon.log` |
+| All bugs blocked/failed/needs-info | Show status, suggest retrying 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`. |
+| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-bugfix-daemon.sh .prizmkit/dev-pipeline/run-bugfix.sh` |

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

@@ -197,34 +197,8 @@ Detect user intent from their message, then follow the corresponding workflow:
    - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
    - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
 
-   **Environment variable mapping** (for translating user responses → env vars):
-
-   | Config choice | Environment variable |
-   |-----------|---------------------|
-   | Critic: On | `ENABLE_CRITIC=true` |
-   | Verbose: Off | `VERBOSE=0` |
-   | Verbose: On | `VERBOSE=1` |
-   | Max retries: N | `MAX_RETRIES=N` |
-   | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
-   | Stop on failure: On | `STOP_ON_FAILURE=1` |
-   | Deploy: Yes | `ENABLE_DEPLOY=1` |
-   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
-
-   **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.
+   **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).
+
 
 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.
 
@@ -411,24 +385,7 @@ After pipeline completion, if features have `browser_interaction` fields and the
 
 ### Error Handling
 
-| Error | Action |
-|-------|--------|
-| `.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 .prizmkit/state/features/pipeline-daemon.log` |
-| Feature stuck/blocked | Use `reset-feature.sh <F-XXX> --clean --run` for a fresh retry |
-| All features blocked/failed | Show status, suggest daemon-safe recovery: `.prizmkit/dev-pipeline/reset-feature.sh <F-XXX> --clean --run .prizmkit/plans/feature-list.json` |
-| `playwright-cli` not installed | Browser verification skipped for playwright features (non-blocking). Suggest: `npm install -g @playwright/cli@latest && playwright-cli install --skills` |
-| `opencli` not installed | Browser verification skipped for opencli features (non-blocking). Install opencli for Chrome session-based browser verification |
-| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-feature-daemon.sh .prizmkit/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` |
-| Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/features/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
-| `.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 |
+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).
 
 ### Integration Notes
 

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

@@ -0,0 +1,55 @@
+# Configuration Reference — Feature Pipeline Launcher
+
+Environment variable mappings for the feature launcher.
+
+## Environment Variable Mapping
+
+Translating user responses to env vars:
+
+| Config choice | Environment variable |
+|-----------|---------------------|
+| Critic: On | `ENABLE_CRITIC=true` |
+| Verbose: Off | `VERBOSE=0` |
+| Verbose: On | `VERBOSE=1` |
+| Max retries: N | `MAX_RETRIES=N` |
+| Timeout: value | `SESSION_TIMEOUT=<seconds>` |
+| Stop on failure: On | `STOP_ON_FAILURE=1` |
+| Deploy: Yes | `ENABLE_DEPLOY=1` |
+| Effort: value | `PRIZMKIT_EFFORT=<value>` |
+
+## 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 |
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| `.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 .prizmkit/state/features/pipeline-daemon.log` |
+| Feature stuck/blocked | Use `reset-feature.sh <F-XXX> --clean --run` for a fresh retry |
+| All features blocked/failed | Show status, suggest daemon-safe recovery: `.prizmkit/dev-pipeline/reset-feature.sh <F-XXX> --clean --run .prizmkit/plans/feature-list.json` |
+| `playwright-cli` not installed | Browser verification skipped for playwright features (non-blocking). Suggest: `npm install -g @playwright/cli@latest && playwright-cli install --skills` |
+| `opencli` not installed | Browser verification skipped for opencli features (non-blocking). Install opencli for Chrome session-based browser verification |
+| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-feature-daemon.sh .prizmkit/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` |
+| Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/features/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
+| `.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 |

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

@@ -131,71 +131,11 @@ Record everything the user provides — these become inputs for Step 1.3.
 
 ### Step 1.3: Parallel Deep Reading
 
-**Goal**: Build comprehensive understanding of the project context before discussing detailed requirements. Spawn multiple agents in parallel to read all relevant materials simultaneously.
-
-**Parallel reading tasks** (launch concurrently):
-
-| Agent | What to read | Purpose |
-|-------|-------------|---------|
-| Agent A | User-provided code paths — read existing source files | Understand current architecture, patterns, conventions |
-| Agent B | User-provided documents — design docs, specs, PRDs | Understand intended requirements and constraints |
-| Agent C | `.prizmkit/prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
-| Agent D | Database/schema files + `.prizmkit/config.json` | Understand data model and tech stack preferences |
-
-**Also gather** (can be included in any agent's task):
-- Directory structure of the project
-- Existing test patterns and conventions
-- Dependency relationships between existing modules
-
-**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.3 for the parallel agent dispatch procedure — spawn 4 agents (A: code paths, B: documents, C: prizm-docs, D: database/config) to build comprehensive project context before discussion. Synthesize findings before proceeding.
 
 ### Step 1.4: Discuss Requirements
 
-**Now** — with deep knowledge of the actual codebase and documents — discuss the requirements with the user. This discussion is grounded in real context, not abstract questions.
-
-Present what you learned from the parallel reading:
-- Current project structure and patterns (with specific references)
-- Existing data model and schema conventions
-- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
-- Integration points with existing modules
-
-Then ask targeted questions based on what you read. **Adapt question depth to the feature complexity** — a simple CRUD feature needs fewer questions than a real-time collaboration system.
-
-**Functional Requirements:**
-- What are the core user actions/workflows?
-- What inputs does the system accept? What outputs does it produce?
-- What are the key business rules and validation logic?
-- Are there different user roles with different permissions?
-
-**Data Model & Database** (if applicable):
-- What entities/data need to be stored?
-- What are the relationships between entities?
-- Are there existing database tables this feature must integrate with?
-- What fields are required vs optional? What data types?
-- Any unique constraints, indexes, or special query patterns needed?
-- **RULE**: If the project has existing database tables, ALL new table designs must reference and conform to the existing schema style (naming conventions, ID strategy, timestamp patterns, constraint patterns). Ask the user to confirm the data model before proceeding.
-
-**User Experience:**
-- What does the user see and interact with?
-- What is the expected flow/sequence of actions?
-- How should errors be displayed to the user?
-- Are there any specific UI/UX requirements?
-
-**Integration & Architecture:**
-- "Based on the existing code, this feature would integrate with [modules]. Does that match your expectations?"
-- Any external APIs or services involved?
-- What authentication/authorization model applies?
-- Any real-time requirements (WebSocket, SSE, polling)?
-
-**Edge Cases & Error Handling:**
-- What happens when things go wrong? (network failure, invalid input, concurrent access)
-- What are the boundary conditions? (empty states, max limits, permissions denied)
-- Any rate limiting, quotas, or resource constraints?
-
-**Non-Functional Requirements:**
-- Performance expectations? (response time, throughput)
-- Scalability considerations?
-- Security requirements? (encryption, audit logs, compliance)
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.4 for the full requirements discussion framework — functional requirements, data model, user experience, integration/architecture, edge cases, and non-functional requirements. Ask targeted questions based on what was learned from parallel reading. **Adapt question depth to the feature complexity.**
 
 ### Step 1.5: Confirm and Supplement
 
@@ -206,57 +146,11 @@ After the discussion:
 3. **Identify gaps** — if any areas are still unclear, list them explicitly and ask follow-up questions
 4. **Repeat** until the user confirms: "That covers everything" or "Let's proceed"
 
-**Signs that brainstorming is complete:**
-- All functional requirements have concrete acceptance criteria
-- Data model entities and relationships are defined
-- Edge cases and error handling are addressed
-- Integration points are identified
-- The user has confirmed the summary is accurate
-
-**Signs that more questions are needed:**
-- User's answers contain vague terms ("handle it appropriately", "make it user-friendly", "standard behavior")
-- Core business rules are undefined ("depends on the situation")
-- Data relationships are unclear ("somehow connected")
-- User says "I'm not sure" — help them think through it with concrete options
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Completion Signs for the full checklist of when brainstorming is complete vs when more questions are needed.
 
 ### Step 1.6: Requirements Summary
 
-Once brainstorming is complete, produce a structured requirements summary:
-
-```markdown
-## Requirements Summary
-
-### Project/Feature: [Name]
-
-### Core Functionality
-- [Bullet list of what the system does]
-
-### User Roles
-- [Role]: [What they can do]
-
-### Data Model Overview
-- [Entity]: [Key fields, relationships]
-
-### Key Business Rules
-- [Rule 1]
-- [Rule 2]
-
-### Integration Points
-- [External system/API/module]
-
-### Edge Cases & Error Handling
-- [Case]: [Expected behavior]
-
-### Non-Functional Requirements
-- [Requirement]
-
-### Reference Materials Reviewed
-- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
-
-### Confirmed by user: ✓
-```
-
-Present this summary to the user and get explicit confirmation before proceeding.
+Once brainstorming is complete, produce a structured requirements summary. Read `${SKILL_DIR}/references/brainstorm-guide.md` §Requirements Summary Template for the structured output format. Present the summary to the user and get explicit confirmation before proceeding.
 
 **CHECKPOINT CP-FW-0**: Requirements fully clarified and confirmed by user.
 
@@ -483,17 +377,7 @@ While the pipeline runs, the user can continue the conversation:
 
 ## Comparison with Alternative Workflows
 
-| Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
-|-----------|-----------------|------------------|-------------------|
-| **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring (batch) |
-| **Brainstorming** | Yes — collect materials, parallel read, discuss | No (bug report is input) | Yes — clarify type, collect materials, parallel read, discuss |
-| **Planning Skill** | `feature-planner` | None (triage built-in) | `refactor-planner` |
-| **Branch** | Pipeline manages per-feature | `fix/<BUG_ID>-*` | Pipeline manages per-refactor |
-| **Execution** | Foreground or background daemon | In-session, interactive | Foreground or background daemon |
-| **Input** | Rough idea or requirements | Bug report / stack trace | Rough refactoring idea or target |
-| **Output** | Multiple `feat()` commits | Single `fix()` commit | Multiple `refactor()` commits |
-| **Behavior Change** | Expected (new functionality) | Fix behavior | Forbidden (structure only) |
-| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | (this is the batch flow) |
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Comparison for the full comparison table (feature-workflow vs bug-fix-workflow vs refactor-workflow across 9 dimensions).
 
 ---