prizmkit 1.1.111 → 1.1.112

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

@@ -1,370 +1,241 @@
 ---
 name: "feature-workflow"
-description: "Triage-based feature workflow. Clarifies requirements, then lets the user choose Fast Path for simple current-session/current-workspace implementation or Pipeline Path for complex/batch features via feature-planner → feature-pipeline-launcher. Use when the user wants to develop features from idea to running code with the right execution path for the task difficulty. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete'."
+description: "Thin L3 feature workflow router. Clarifies enough to choose Fast Path, Pipeline Path, existing-list launch, or greenfield app planning; hands deep feature planning to feature-planner, app-level planning to app-planner, and execution configuration to feature-pipeline-launcher. Use when the user wants to develop features from idea to code, add features to an existing project, batch implement features, run an existing feature list, or build a new app that should first go through app-planner. Trigger on: 'develop features', 'implement features', 'add feature', 'batch implement', 'one-stop development', 'build an app', 'build a new application', 'create a project', 'run feature list'."
 ---
 
 # Feature Workflow
 
-Triage-based entry point for feature development. The workflow clarifies requirements, assesses task difficulty, asks the user to choose an approach, then follows one of two paths:
+Thin L3 entry point for feature development. This skill routes the user to the right execution path, prepares a concise handoff brief, and avoids duplicating planner or launcher internals.
 
-- **Fast Path** — simple feature work is implemented directly in the **current session** and **current workspace** with the normal PrizmKit lifecycle commands.
-- **Pipeline Path** — complex or batch features are planned with `feature-planner`, launched with `feature-pipeline-launcher`, then monitored.
+## Responsibility Boundary
 
-This skill keeps Fast Path and Pipeline Path separate. Pipeline monitoring only happens after the user selects Pipeline Path and the launcher starts execution.
+This workflow owns:
+- Scenario recognition: Fast Path, Pipeline Path, greenfield app planning, or existing-list launch.
+- Lightweight triage: enough context to recommend a path, not full feature planning.
+- User path selection through `AskUserQuestion`.
+- Prompt brief handoff to `app-planner`, `feature-planner`, `feature-pipeline-launcher`, or Fast Path L1 skills.
+- Continuation after `feature-planner` when the user entered through this workflow.
 
-## When to Use
-
-User says:
-- "Build a new application", "Build XXX system", "Create a project"
-- "Implement this feature now", "Add this simple feature", "Build one small workflow"
-- "One-click complete these features", "Batch implement these requirements"
-- "Help me implement user login, registration, and avatar upload features"
-- After receiving either one scoped feature request or a batch of related feature requests
-
-**Do NOT use this skill when:**
-- User only wants to plan features without execution → use `feature-planner` directly
-- User only wants to launch an existing `.prizmkit/plans/feature-list.json` → use `feature-pipeline-launcher`
-- User wants to fix bugs → use `bug-fix-workflow` or `bug-planner` + `bugfix-pipeline-launcher`
-- User wants to refactor code → use `refactor-workflow`
-
----
-
-## Overview
-
-The shared contract is:
-
-1. **Brainstorm** — collect reference materials, deep read relevant code/docs, and clarify requirements.
-2. **Assess difficulty** — decide whether the request is simple enough for Fast Path or should use Pipeline Path.
-3. **AskUserQuestion approach selection** — present selectable options; never silently choose the path.
-4. **Execute selected path**:
-   - **Fast Path**: `/prizmkit-plan` → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-retrospective` → `/prizmkit-committer` in the current workspace.
-   - **Pipeline Path**: `feature-planner` → `feature-pipeline-launcher` → monitoring.
-
-### Terminology
-
-| Term | Meaning |
-|------|---------|
-| **Fast Path** | Current-session/current-workspace feature implementation for simple, scoped work. It does not create or consume `.prizmkit/plans/feature-list.json` and does not start the dev-pipeline. |
-| **Pipeline Path** | Complex or batch feature execution. Planner handoff goes to `feature-planner`; launcher handoff goes to `feature-pipeline-launcher`; monitoring follows only after launch. |
-| **Current session** | The interactive AI CLI session that is already talking with the user. |
-| **Current workspace** | The current git checkout and working tree, not a background pipeline worktree/session. |
-| **Monitoring** | Status/log follow-up for a launched pipeline; it is not part of the Fast Path. |
-
-### Workspace and Branch Model
-
-- **Fast Path**: work happens in the current workspace and current interactive session. Use the current branch unless the project policy or user explicitly asks to create a branch.
-- **Pipeline Path**: `feature-pipeline-launcher` and the dev-pipeline manage per-feature branches/worktrees. This workflow does not create a top-level branch before handing off to the launcher.
-
----
-
-## Input Modes
-
-**Mode A: Natural language requirements** (default)
-
-Natural language description of the project or feature(s). Can be:
-- A single simple feature: "Add CSV export to the reports page"
-- A project vision: "Build a task management App with user login, task CRUD, and task categories"
-- A batch of features: "Implement user registration, login, and password recovery"
-- An incremental request: "Add user avatar upload and nickname modification to the existing system"
-
-Flow: brainstorm → complexity assessment → AskUserQuestion → Fast Path or Pipeline Path.
-
-**Mode B: Existing `.prizmkit/plans/feature-list.json`**
-
-When the user says "run pipeline from existing file" or `.prizmkit/plans/feature-list.json` already exists and should be executed:
-- Skip brainstorm and `feature-planner`
-- Invoke `feature-pipeline-launcher` directly
-- Monitor and report progress
-
-**Mode C: Incremental feature request**
-
-When user says "add features to existing project" or the project already has features:
-- Brainstorm only the new feature requirements
-- Assess whether the new scope is simple enough for Fast Path
-- For simple work: use Fast Path in the current workspace
-- For complex or batch work: invoke `feature-planner` in incremental mode, then `feature-pipeline-launcher`
-
----
-
-## Phase 1: Brainstorm — Deep Requirement Clarification
-
-**Goal**: Through interactive Q&A and deep context reading, transform the user's rough idea into fully clarified, implementation-ready requirements. This phase is the foundation for high-quality code generation — vague requirements produce vague code.
-
-Critical rule: the number of questions is unlimited. Do NOT rush through this phase. Ask as many rounds as needed until every aspect is clear. The framework strives for high-quality code generation, which requires strong requirement understanding.
-
-### Step 1.1: Understand the User's Vision
-
-Ask the user to describe what they want to build. Listen for:
-- What the system/feature does (core functionality)
-- Who uses it (user roles, personas)
-- Why it's needed (business value, problem being solved)
-
-### Step 1.2: Collect Reference Materials
-
-**Upfront Material Detection (Hard Rule)**: If the user has already provided materials (file paths, URLs, rules, specifications, code snippets) in the same message that invoked this skill:
-1. Acknowledge what was received: "I received the following materials: [list]"
-2. Read/fetch all provided materials immediately
-3. You MUST still ask: "Are there any additional materials you'd like to provide?"
-4. NEVER skip this collection step just because the user already provided some materials
-
-**If the user has NOT provided any materials upfront**, ask the user explicitly what resources they have. Do NOT skip this step — user-provided materials are far more valuable than blind directory scanning.
-
-Ask:
-1. **Existing code** — "Is there existing code I should look at? Which files or directories are relevant?"
-2. **Design documents** — "Do you have any design docs, wireframes, API specs, or PRDs I should read?"
-3. **Knowledge docs** — "Are there related `.prizmkit/prizm-docs/`, README files, or internal wiki pages?"
-4. **Reference projects** — "Any reference implementations or similar projects I should look at for inspiration?"
+This workflow does not own:
+- Deep feature clarification, decomposition, dependency/DAG decisions, priority/complexity calibration, schema validation, or plan review gates — those belong to `feature-planner`.
+- Execution mode, runtime configuration, preflight, command assembly, status/log/stop/retry details — those belong to `feature-pipeline-launcher`.
+- App-level vision, tech stack, conventions, architecture decisions, or project brief — those belong to `app-planner`.
 
-Record everything the user provides — these become inputs for Step 1.3.
-
-### Step 1.3: Parallel Deep Reading
+## When to Use
 
-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.
+Use this workflow when the user wants a guided feature-development entry point:
+- Build, add, or implement features.
+- Decide whether a feature should be implemented now or planned for pipeline execution.
+- Batch implement multiple feature requests.
+- Continue from an existing `.prizmkit/plans/feature-list.json`.
+- Start from a greenfield app idea, where this workflow will route to `app-planner` first.
 
-### Step 1.4: Discuss Requirements
+Do not use this workflow when the user only wants:
+- App-level planning without feature execution intent -> use `app-planner`.
+- Feature list generation only -> use `feature-planner`.
+- Launch/status/logs/retry for an existing feature list -> use `feature-pipeline-launcher`.
+- Bug fixing -> use `bug-fix-workflow` or the bug pipeline skills.
+- Behavior-preserving restructuring -> use `refactor-workflow`.
 
-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.**
+## Route Overview
 
-### Step 1.5: Confirm and Supplement
+| User situation | Route |
+|---|---|
+| Greenfield app, new application, create project | `app-planner` first; then optionally `feature-planner` |
+| Existing project, simple scoped feature | Fast Path in current workspace |
+| Existing project, complex or batch features | `feature-planner` -> return here -> `feature-pipeline-launcher` |
+| User explicitly says to run an existing feature list | `feature-pipeline-launcher` |
+| Feature list exists but the user did not explicitly ask to run it | Ask launch / inspect / update |
 
-After the discussion:
+## Route Selection
 
-1. **Summarize** the requirements — present it back to the user
-2. **Ask explicitly**: "Is there anything else you'd like to discuss or supplement before we proceed to formal planning?"
-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"
+### Step 1: Detect the entry mode
 
-Read `${SKILL_DIR}/references/brainstorm-guide.md` §Completion Signs for the full checklist of when brainstorming is complete vs when more questions are needed.
+Classify the user's request before asking detailed feature questions:
 
-### Step 1.6: Requirements Summary
+- **Greenfield app**: the user says “build a new app”, “create a project”, “start from scratch”, or asks for app-level architecture/tech stack/conventions.
+- **Existing list launch**: the user explicitly asks to run, start, resume, check, retry, or stop `.prizmkit/plans/feature-list.json`.
+- **Existing project feature work**: the user asks to add or implement features in a project that already has source code or project context.
+- **Unclear**: the user mixes app design, feature planning, and implementation intent.
 
-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.
+If the request is unclear, ask one concise clarification question before route selection.
 
-**CHECKPOINT CP-FW-0**: Requirements fully clarified and confirmed by user.
+### Step 2: Lightweight triage for existing-project feature work
 
----
+Use lightweight criteria only. Do not perform full feature decomposition here.
 
-### Step 1.7: Complexity Assessment & Approach Selection
+Fast Path candidate when all are true:
+- One scoped feature or a very small set of tightly related changes.
+- Expected work is localized and follows existing patterns.
+- No app-level architecture, new infrastructure, or broad dependency ordering is needed.
+- Acceptance intent is clear enough for `/prizmkit-plan` to create a spec and plan.
 
-After confirming requirements, assess whether this feature needs the Pipeline Path or can be done directly in the current session/current workspace.
+Pipeline Path candidate when any are true:
+- Multiple independent features or a batch implementation request.
+- Cross-module or multi-layer impact.
+- New data model, API design, infrastructure, external service, or dependency ordering is likely.
+- The user wants autonomous/background execution.
+- The request needs `feature-planner` to clarify, split, validate, and review feature entries.
 
-**Simple feature work → Fast Path candidate** (ALL must be true):
-- Single module, no cross-module architectural impact
-- ≤2 new files to create
-- No new external dependencies or infrastructure changes
-- Straightforward implementation (CRUD endpoint, utility, simple UI component, small workflow)
-- Clear acceptance criteria with existing patterns to follow
-- No dependency on other unbuilt features
+### Step 3: Ask for path selection
 
-**Complex or batch features → Pipeline Path candidate** (ANY is true):
-- Multiple features or batch implementation request
-- Cross-module impact (>2 modules affected)
-- New infrastructure, dependencies, or architectural patterns required
-- Multiple interrelated features with dependency ordering
-- Data model or API design decisions needed
-- Requires integration with external services
+Use `AskUserQuestion`; do not render path options as plain text.
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options. Adjust the question framing to the assessment: for a simple feature, "This feature appears straightforward and can use the current-session Fast Path." For a complex or batch request, "This feature set is complex or batch-oriented and should use the Pipeline Path."
+For existing-project feature work:
 
+```text
+Question: How would you like to proceed?
+Header: Approach
+Options:
+- Implement now (Fast Path) — current session/current workspace via /prizmkit-plan -> /prizmkit-implement -> review/retro/commit
+- Use Pipeline Path — feature-planner creates/reviews feature-list.json, then feature-pipeline-launcher configures execution
+- Continue clarifying — ask a few more route-level questions before choosing
 ```
-AskUserQuestion:
-  question: "How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Implement now (Fast Path — current session/current workspace)"
-      description: "Run /prizmkit-plan → /prizmkit-implement → /prizmkit-code-review → /prizmkit-retrospective → /prizmkit-committer directly in this workspace"
-    - label: "Use Pipeline Path (feature-planner → feature-pipeline-launcher)"
-      description: "Generate .prizmkit/plans/feature-list.json with feature-planner, then launch autonomous execution with feature-pipeline-launcher"
-```
-
-- **Implement now (Fast Path)**:
-  1. Invoke `/prizmkit-plan` with the requirements summary → generates `spec.md` + `plan.md`
-  2. Invoke `/prizmkit-implement` to execute the plan in the current workspace
-  3. Run `/prizmkit-code-review` for quality check
-  4. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
-  5. Commit via `/prizmkit-committer` with `feat(<scope>):` prefix
-  6. End workflow — do not call `feature-planner`, do not call `feature-pipeline-launcher`, and do not enter monitoring
-- **Use Pipeline Path** → Continue to Phase 2 (Planner handoff)
-
-Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.
-
-**CHECKPOINT CP-FW-0.5**: Approach selected by user (Fast Path or Pipeline Path).
-
----
 
-## Phase 2: Plan — Pipeline Path Only
+For greenfield app work:
 
-**Goal**: Generate structured `.prizmkit/plans/feature-list.json` from the clarified requirements.
-
-Run this phase only when the user selected Pipeline Path or provided a batch/complex request that they chose to send through the pipeline.
+```text
+Question: This looks like app-level planning before feature decomposition. How would you like to proceed?
+Header: App plan
+Options:
+- Start app-planner (Recommended) — capture vision, tech stack, conventions, architecture decisions, and project brief first
+- Feature-plan anyway — continue only if the user confirms they already have app-level context
+- Continue clarifying — resolve whether this is app planning or feature planning
+```
 
-**STEPS**:
+For an auto-discovered existing feature list:
 
-1. **Planner handoff — invoke `feature-planner`** with the full requirements summary from Phase 1:
-   - Pass the structured requirements summary as input — NOT the raw user conversation
-   - For new projects: standard planning mode
-   - For existing projects with `--incremental`: incremental planning mode
-   - **Input**: Markdown requirements summary (feature descriptions, goals, constraints)
-   - **Output**: `.prizmkit/plans/feature-list.json` (schema: `dev-pipeline-feature-list-v1`) containing `project_name`, `features[]` with id (F-NNN), title, description, priority, dependencies, acceptance_criteria, status
+```text
+Question: Existing feature-list.json found. What should we do with it?
+Header: Feature list
+Options:
+- Launch existing list — hand off to feature-pipeline-launcher
+- Inspect summary first — show feature count/status, then ask again
+- Update/re-plan — hand off to feature-planner in incremental mode
+- Ignore and start fresh — continue route selection from the new request
+```
 
-2. **Interactive planning** (if `feature-planner` requires clarification):
-   - Because Phase 1 was thorough, `feature-planner` should need minimal clarification
-   - If questions arise, answer from the Phase 1 context or pass through to user
+If the user explicitly asked to run an existing list, that explicit request counts as path selection; hand off directly to `feature-pipeline-launcher`.
 
-3. **Validate output**:
-   - Confirm `.prizmkit/plans/feature-list.json` exists
-   - Show summary: total features, complexity distribution, dependencies
+## Workflow Handoff Brief
 
-**CHECKPOINT CP-FW-1**: `.prizmkit/plans/feature-list.json` generated and validated.
+When handing off, include this prompt brief in the next skill invocation. Do not write the brief to disk.
 
-**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely and go to Phase 3.
+```markdown
+## Workflow Handoff Brief
 
----
+### Source
+- workflow: feature-workflow
+- selected_path: fast_path | pipeline_path | existing_list_launch | app_planning_first
 
-## Phase 3: Launch — Pipeline Path Only
+### User Goal
+- original_request: <preserve the user's wording>
+- normalized_goal: <lightly normalized feature/app goal>
 
-**Goal**: Start the development pipeline after planner handoff has produced a validated feature list.
+### Scope
+- included: <explicitly in scope>
+- excluded: <explicitly out of scope or unknown>
 
-**STEPS**:
+### Materials
+- provided_paths: <paths/directories supplied by the user>
+- provided_docs_or_urls: <docs, links, screenshots, or specs supplied by the user>
+- notes: <rules, constraints, or emphasis from the user>
 
-1. **Show feature summary** before launching:
-   ```
-   Ready to launch Pipeline Path with N features:
-     F-001: User authentication (high complexity)
-     F-002: Task CRUD (medium complexity)
-     F-003: Task categories (low complexity)
+### Decision
+- route_reason: <why this path was selected>
+- user_confirmed: yes
 
-   Proceed? (Y/n)
-   ```
+### Next Skill Instruction
+- For planner: Use this brief as input; perform your own required clarification, validation, generation, and review gate.
+- For Fast Path: Use this brief to create spec.md/plan.md and implement only this scope.
+```
 
-2. **Launcher handoff — invoke `feature-pipeline-launcher`**:
-   - **Input**: Path to validated `.prizmkit/plans/feature-list.json`
-   - The launcher handles all prerequisite checks
-   - The launcher presents execution mode choices to the user (foreground/background/manual)
-   - The launcher asks whether to enable Critic Agent (adversarial review) — passes `--critic` flag if chosen
-   - Do NOT duplicate execution mode or critic selection here — let the launcher handle it
-   - **Output**: PID/status, log file path, execution mode selected
+## Selected Path Execution
 
-3. **Verify launch success**:
-   - Confirm pipeline is running
-   - Record PID and log path for Phase 4
+### Greenfield app path
 
-**CHECKPOINT CP-FW-2**: Pipeline launched successfully.
+1. Invoke `app-planner` with the handoff brief.
+2. Let `app-planner` capture app-level context and produce its planning artifacts.
+3. After `app-planner` completes, ask whether the user wants to decompose the app into executable features.
+4. If yes, invoke `feature-planner` with the app-planner output and the original brief.
+5. When `feature-planner` finishes and the user entered through this workflow, continue to the Pipeline Launch handoff.
 
----
+Do not generate `feature-list.json` inside this workflow; `feature-planner` owns that output.
 
-## Phase 4: Monitor — Pipeline Path Only
+### Fast Path
 
-**Goal**: Track pipeline progress and report to user. Monitoring applies only after `feature-pipeline-launcher` has started a pipeline.
+Use Fast Path only after explicit user selection.
 
-**STEPS**:
+1. Invoke `/prizmkit-plan` with the handoff brief.
+2. Invoke `/prizmkit-implement` after the plan is ready.
+3. Run `/prizmkit-code-review` as the quality gate.
+4. Run `/prizmkit-retrospective` for feature changes before commit.
+5. Run `/prizmkit-committer` with a `feat(<scope>):` message.
+6. End the workflow after commit; do not call `feature-planner`, `feature-pipeline-launcher`, or monitoring.
 
-1. **Initial status check**:
-   ```bash
-   python3 ./.prizmkit/dev-pipeline/cli.py daemon feature status
-   ```
+If implementation scope grows beyond the Fast Path criteria, pause and ask whether to switch to Pipeline Path.
 
-2. **Offer monitoring options**:
-   - "I'll check progress periodically. Say 'status' anytime for an update."
-   - "Say 'logs' to see recent activity."
-   - "Say 'stop' to pause the pipeline."
+### Planner handoff — Pipeline Path
 
-3. **Periodic progress reports** (when user asks):
-   ```bash
-   python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json
-   ```
+1. Invoke `feature-planner` with the handoff brief.
+2. `feature-planner` performs deep clarification, decomposition, validation, and plan review.
+3. After `feature-planner` reports a validated `.prizmkit/plans/feature-list.json`, show a concise summary: item count, major dependencies, and review/validation outcome.
+4. Ask whether to proceed to launch.
+5. **Launcher handoff**: if yes, invoke `feature-pipeline-launcher`.
 
-4. **Completion report** (when pipeline finishes all features):
-   ```
-   Pipeline completed: 3/3 features
+Do not duplicate launcher execution-mode or configuration questions in this workflow; the launcher owns them.
 
-   Summary:
-   - F-001: User authentication → COMMITTED (feat: user auth)
-   - F-002: Task CRUD → COMMITTED (feat: task crud)
-   - F-003: Task categories → COMMITTED (feat: categories)
+### Existing list launch
 
-   Next steps:
-   - Review changes: git log --oneline -5
-   - Run tests: npm test
-   - Push when ready: git push
-   ```
+If the user explicitly requested launch/status/logs/retry/stop for an existing feature list, invoke `feature-pipeline-launcher` with the user's intent and list path.
 
-**CHECKPOINT CP-FW-3**: All features completed or user stopped pipeline.
+If this workflow discovered the list on its own, use the `Existing feature-list.json found` question in §Route Selection before invoking the launcher.
 
----
+## Resume Guidance
 
-## Resume — Interruption Recovery
+| State found | Action |
+|---|---|
+| Fast Path `spec.md` / `plan.md` exists | Ask whether to continue current-workspace implementation or re-plan |
+| Valid `.prizmkit/plans/feature-list.json` exists and user wants execution | Invoke `feature-pipeline-launcher` |
+| Valid feature list exists but intent is unclear | Ask launch / inspect / update |
+| No plan/list artifacts | Start route selection |
 
-The workflow supports resuming by detecting existing state:
+For interrupted autonomous pipeline sessions, prefer `feature-pipeline-launcher` status/retry operations or `recovery-workflow` when the user explicitly asks to recover a broken AI session.
 
-| State Found | Resume From |
-|-------------|-------------|
-| Fast Path `spec.md` + `plan.md` exist, code not committed | Resume `/prizmkit-implement` / review / retrospective / commit based on current state |
-| No `.prizmkit/plans/feature-list.json` and no Fast Path artifacts | Phase 1: Brainstorm |
-| `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch |
-| `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
-| All features completed | Report completion, suggest next steps |
+## Runtime Status Reference
 
-**Resume**: If `.prizmkit/plans/feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume Pipeline Path or re-plan?" If Fast Path artifacts exist, ask whether to continue the current-workspace implementation or discard/re-plan.
+This workflow does not assemble runtime commands, but it may show lightweight status before handoff or recovery. Use the canonical Python runtime forms:
 
----
-
-## Interaction During Pipeline
-
-While the pipeline runs, the user can continue the conversation:
-
-| User says | Action |
-|-----------|--------|
-| "status" / "progress" | Show current progress |
-| "logs" | Show recent log activity |
-| "stop" | Stop the pipeline (state preserved) |
-| "show F-002 logs" | Show specific feature's session log |
+```bash
+python3 ./.prizmkit/dev-pipeline/cli.py daemon feature status
+python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json
+```
 
----
+For start/stop/logs/retry execution, hand off to `feature-pipeline-launcher`; do not duplicate launcher configuration here.
 
 ## Error Handling
 
-| Error | Action |
-|-------|--------|
-| User's idea is too vague to brainstorm | Ask for more context: "Can you describe the main problem this solves?" |
-| Brainstorming stalls | Offer concrete options: "Would you prefer A or B?" |
-| Fast Path starts looking complex | Pause and ask whether to switch to Pipeline Path (`feature-planner` → `feature-pipeline-launcher`) |
-| `feature-planner` cannot parse requirements | Refine the requirements summary and retry |
-| `.prizmkit/plans/feature-list.json` generation failed | Show error, retry with refined input |
-| Pipeline launch failed | Show daemon log, suggest manual start with `python3 ./.prizmkit/dev-pipeline/cli.py feature run .prizmkit/plans/feature-list.json` or `python3 ./.prizmkit/dev-pipeline/cli.py daemon feature start .prizmkit/plans/feature-list.json` |
-| All features blocked/failed | Show status, suggest retrying specific features |
-| User wants to cancel mid-brainstorming | Save conversation context, offer to resume later |
-
----
+| Situation | Action |
+|---|---|
+| Request is app-level, not feature-level | Route to `app-planner` |
+| User wants planning only | Route to `feature-planner` and stop after planner summary |
+| User wants execution only | Route to `feature-pipeline-launcher` |
+| Fast Path becomes complex | Pause and ask whether to switch to Pipeline Path |
+| Planner cannot proceed without more detail | Let `feature-planner` ask its own clarification questions |
+| Launcher finds preflight/config issues | Let `feature-pipeline-launcher` handle config and confirmation |
 
-## HANDOFF
+## Handoff Map
 
 | From | To | Condition |
-|------|----|-----------|
-| **this skill** | `/prizmkit-plan` | User selects Fast Path for simple feature work in the current workspace |
-| **this skill** | `/prizmkit-implement` | Fast Path plan is ready for current-session implementation |
-| **this skill** | `/prizmkit-code-review` | Fast Path implementation is complete and needs quality review |
-| **this skill** | `/prizmkit-retrospective` | Fast Path feature changes need `.prizmkit/prizm-docs/` sync before commit |
-| **this skill** | `/prizmkit-committer` | Fast Path feature changes are reviewed and docs are synced |
-| **this skill** | `feature-planner` | User selects Pipeline Path for complex or batch features |
-| `feature-planner` | `feature-pipeline-launcher` | Planner handoff produced validated `.prizmkit/plans/feature-list.json` |
-| `feature-pipeline-launcher` | **this skill** | Launcher handoff completed and monitoring/status follow-up is needed |
-
----
-
-## Comparison with Alternative Workflows
-
-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).
-
----
-
-## Path References
-
-All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+|---|---|---|
+| `feature-workflow` | `app-planner` | Greenfield or app-level planning is required |
+| `feature-workflow` | `/prizmkit-plan` | User selects Fast Path |
+| `feature-workflow` | `feature-planner` | User selects Pipeline Path |
+| `feature-planner` | `feature-workflow` | Planner completed from workflow-origin Pipeline Path |
+| `feature-workflow` | `feature-pipeline-launcher` | User confirms launch after planner completion or explicitly requests existing-list execution |
 
 ## Output
 
-Output depends on the selected path:
-
-- **Fast Path**: `spec.md` + `plan.md`, current-workspace code changes, `/prizmkit-code-review` result, updated `.prizmkit/prizm-docs/`, and one `feat(<scope>):` commit from `/prizmkit-committer`.
-- **Pipeline Path**: structured requirements summary, `.prizmkit/plans/feature-list.json`, pipeline execution via `feature-pipeline-launcher`, monitoring updates, and per-feature commits managed by the dev-pipeline.
+- Fast Path: `spec.md`, `plan.md`, code changes, review result, Prizm docs sync, and one feature commit.
+- Pipeline Path: handoff brief, validated `.prizmkit/plans/feature-list.json` from `feature-planner`, and pipeline launch/status handled by `feature-pipeline-launcher`.
+- Greenfield path: app-level planning artifacts from `app-planner`, optionally followed by feature planning and launch.