prizmkit 1.1.130 → 1.1.134

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

@@ -5,7 +5,7 @@ description: "Plan, validate, and manage features for an existing project — ad
 
 # feature planner
 
-Plan deliverable features for dev-pipeline on existing projects:
+Plan deliverable features for autonomous dev-pipeline execution on existing projects. This skill creates or updates planning artifacts only:
 - **New Feature Set**: create an initial .prizmkit/plans/feature-list.json for a project that has code but no plan yet
 - **Incremental Feature Planning**: append, adjust, or reprioritize features in an existing plan
 
@@ -31,7 +31,7 @@ The user chose this skill intentionally. Respect that choice.
 
 ## Scope Boundary (Hard Rule)
 
-**This skill is PLANNING ONLY.** You must NEVER:
+**This skill is PLANNING ONLY.** It may create, append, reprioritize, validate, and review feature planning artifacts, but it must never implement source code or start execution. 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.)
@@ -45,7 +45,8 @@ The user chose this skill intentionally. Respect that choice.
 1. Present the summary and recommended next step (invoking `feature-pipeline-launcher` )
 2. **Ask the user explicitly** whether they want to proceed to execution
 3. If the user wants to adjust → continue refining `.prizmkit/plans/feature-list.json`
-4. **NEVER auto-execute** the pipeline, launcher, or any implementation step
+4. **NEVER auto-execute** the pipeline, launcher, composite workflow, or any implementation step
+5. Return the validated list to the caller; only `feature-pipeline-launcher` prepares the runtime command
 
 ## User-Provided Content Priority (Hard Rule)
 
@@ -223,6 +224,26 @@ Actions:
 3. Append features with next sequential `F-NNN` IDs
 4. Preserve style/language/detail consistency with existing plan
 
+### Route C: Validate Existing Plan
+Use when the user asks to check or validate an existing plan without adding or changing features.
+
+Run:
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input .prizmkit/plans/feature-list.json
+```
+
+Report the script result. Do not enter generation, implementation, or launcher flows unless the user separately requests a plan change or command construction.
+
+### Route D: Summarize Existing Plan
+Use when the user asks to list or summarize the existing feature plan without changing it.
+
+Run:
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py summary --input .prizmkit/plans/feature-list.json
+```
+
+Return the generated summary and stop.
+
 ## Core Workflow
 
 Execute the planning workflow in conversation mode with mandatory checkpoints:
@@ -359,10 +380,7 @@ Key requirements:
 - English feature titles for stable slug generation
 - `browser_interaction` auto-generated for qualifying frontend features (with `tool` selection: `auto`/`playwright-cli`/`opencli`)
 - descriptions: minimum 15 words (error), recommended minimum 30/50/80/100+ for low/medium/high/critical (warning). No upper limit — more detail prevents AI guessing
-- `estimated_complexity` determines pipeline execution tier:
-  - `low` / `medium` → **lite** (single agent, no subagents)
-  - `high` → **standard** (Main-Agent review guardrails, 3-agent compatibility metadata)
-  - `critical` → **full** (strongest Main-Agent review guardrails). Use for: architectural changes touching 10+ files, cross-module refactoring with API surface changes, or safety/security/data-loss risk
+- `estimated_complexity` records implementation scope and verification risk for planning summaries, ordering, and downstream context. It does not select a fixed agent count or named review topology; every normal feature session receives the runtime's full guidance.
 
 **IMPORTANT: Do NOT hand-write the final JSON file.** Instead:
 1. Write a draft JSON to a temporary path (e.g., `.prizmkit/plans/feature-list.draft.json`)
@@ -374,22 +392,9 @@ The script fills in defaults (`$schema`, `created_at`, `created_by`), validates
 
 ## Local Generated-Plan Review Gate
 
-User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-review`
-
-Run this gate **after** `.prizmkit/plans/feature-list.json` passes the validation/generate script and **before** the final handoff summary recommends `feature-pipeline-launcher`. This gate applies to full workflow and fast-path incremental planning when the current session generated, appended, or rewrote final feature planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
+Run this gate after `.prizmkit/plans/feature-list.json` passes generation and validation, and before the final handoff. It applies whenever this session added or changed final feature entries. For validate-only, summary-only, or draft-save flows with no final content change, report that the gate is not applicable.
 
-1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
-2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/feature-list.json`, `.prizmkit/plans/feature-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
-3. **Identify review scope**: compare by stable feature IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed feature entries; preserve unchanged historical entries except when needed to verify dependency references.
-4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG soundness, description completeness, headless execution readiness, acceptance criteria measurability, user-provided wording preservation, task-scoped `user_context` isolation, priority/complexity calibration, and browser interaction fields when applicable.
-5. **Keep the review planning-only**: do NOT start `feature-pipeline-launcher`, do NOT run the dev-pipeline, do NOT run tests/builds/installs, and do NOT implement source-code changes.
-6. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/feature-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
-   ```bash
-   python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
-   ```
-   Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
-7. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
-8. **Report the gate outcome** in the final summary: include local generated-plan review verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result.
+Read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the single source of truth. Review the actual draft and final artifacts directly because `.prizmkit` files may be gitignored. Keep the review planning-only, apply accepted findings to the draft/source representation, regenerate the final JSON, and require validation to pass again before reporting the review result.
 
 ## Testing Defaults (Phase 8)
 

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

@@ -120,10 +120,10 @@ Complexity is an execution-scope estimate, not a priority or importance signal.
 
 | Complexity | Concrete Indicators | Typical Scope | Pipeline Tier |
 |------------|---------------------|---------------|---------------|
-| low | 1 module/layer, 1-3 files, no public API/schema change, shallow dependencies, <=5 acceptance criteria, clear existing tests | 1-2 API endpoints, 1-2 pages, focused config or copy behavior | lite (1 agent) |
-| medium | 2-3 modules/layers, 3-6 files, bounded API/interface changes, moderate dependency depth, 4-8 acceptance criteria, standard test updates | 3-5 API endpoints, 2-4 pages, normal integration work | lite (1 agent) |
-| high | 3+ modules/layers plus public API/interface or schema impact, deep dependencies, weak test coverage, complex state, third-party integration risk, or 8+ acceptance criteria | 5+ API endpoints, complex interactions, cross-cutting behavior | standard (3 agents) |
-| critical | System-wide architecture, new infrastructure, 10+ files with multi-module API surface changes, safety/security/data-loss risk requiring strongest review and test gates | System-wide refactoring, new infrastructure + app logic | full (5 agents + critic) |
+| low | 1 module/layer, 1-3 files, no public API/schema change, shallow dependencies, <=5 acceptance criteria, clear existing tests | 1-2 API endpoints, 1-2 pages, focused config or copy behavior | Full runtime guidance with a small expected change surface |
+| medium | 2-3 modules/layers, 3-6 files, bounded API/interface changes, moderate dependency depth, 4-8 acceptance criteria, standard test updates | 3-5 API endpoints, 2-4 pages, normal integration work | Full runtime guidance with bounded cross-file verification |
+| high | 3+ modules/layers plus public API/interface or schema impact, deep dependencies, weak test coverage, complex state, third-party integration risk, or 8+ acceptance criteria | 5+ API endpoints, complex interactions, cross-cutting behavior | Full runtime guidance with stronger risk context |
+| critical | System-wide architecture, new infrastructure, 10+ files with multi-module API surface changes, safety/security/data-loss risk requiring strongest review and test gates | System-wide refactoring, new infrastructure + app logic | Full runtime guidance with safety-critical context and acceptance gates |
 
 ### Complexity Indicator Checklist
 

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

@@ -1,40 +1,57 @@
 ---
 name: "feature-workflow"
-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'."
+description: "Thin feature scenario router. Clarifies enough to choose direct single-requirement guidance, feature planning, existing-list command construction, or greenfield app planning; hands deep feature planning to feature-planner, app-level planning to app-planner, and runtime command construction to feature-pipeline-launcher. It never starts coding or owns the requirement lifecycle."
 ---
 
 # Feature Workflow
 
-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.
+Classify a feature request, prepare a concise handoff brief, and route planned work without duplicating planner or launcher responsibilities.
 
 ## Responsibility Boundary
 
 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.
+- Scenario recognition: direct single-requirement guidance, Pipeline Path, greenfield app planning, or existing-list command construction.
+- Lightweight triage: enough context to recommend a route, 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.
+- Prompt brief handoff to `app-planner`, `feature-planner`, or `feature-pipeline-launcher`.
 - Continuation after `feature-planner` when the user entered through this workflow.
 
 This workflow does not own:
+- Source-code implementation, build/test execution, code review, documentation sync, or commit execution.
 - 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`.
+- Runtime option selection, command construction, prerequisite checks, or status/log/stop/retry syntax — those belong to `feature-pipeline-launcher`.
 - App-level vision, tech stack, conventions, architecture decisions, or project brief — those belong to `app-planner`.
+- The independent direct requirement lifecycle.
+
+## Execution Topology
+
+The two entry paths are independent:
+
+```text
+Direct single requirement:
+User → prizmkit-workflow → atomic lifecycle skills
+
+Planned feature execution:
+User → feature-workflow → feature-planner → feature-pipeline-launcher → returned CLI command → runtime → atomic lifecycle skills
+```
+
+If the user chooses the direct path, explain the independent entry and end this router. Do not invoke or monitor the direct workflow on the user's behalf.
 
 ## When to Use
 
 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.
+- Build, add, or plan features.
+- Decide whether one focused requirement should use the independent direct path or planned runtime 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.
+- Start from a greenfield app idea, where this workflow routes to `app-planner` first.
 
 Do not use this workflow when the user only wants:
+- A direct single formal requirement lifecycle -> enter it independently.
 - 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.
+- Runtime command construction for an existing feature list -> use `feature-pipeline-launcher`.
+- Bug fixing -> use `bug-fix-workflow` or the bug planning skills.
 - Behavior-preserving restructuring -> use `refactor-workflow`.
 
 ## Route Overview
@@ -42,91 +59,67 @@ Do not use this workflow when the user only wants:
 | 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, one confirmed formal requirement | Explain the independent Direct Path and end this router |
 | 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 |
+| User explicitly asks for a command for an existing feature list | `feature-pipeline-launcher` |
+| Feature list exists but execution intent is unclear | Ask construct command / inspect / update |
 
 ## Route Selection
 
 ### Step 1: Detect the entry mode
 
 Classify the user's request before asking detailed feature questions:
+- **Greenfield app**: asks to build a new app, create a project, start from scratch, or choose app-level architecture/stack/conventions.
+- **Existing list command**: explicitly asks to run, start, resume, check, retry, or stop `.prizmkit/plans/feature-list.json`.
+- **Existing project feature work**: asks to add or plan features in a project with source code or project context.
+- **Unclear**: mixes app design, feature planning, and direct execution intent.
 
-- **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.
-
-If the request is unclear, ask one concise clarification question before route selection.
+If unclear, ask one concise clarification question before route selection.
 
-### Step 2: Lightweight triage for existing-project feature work
+### Step 2: Lightweight triage
 
-Use lightweight criteria only. Do not perform full feature decomposition here.
+A Direct Path candidate is one confirmed, localized formal requirement with no batch decomposition or dependency ordering. This classification only identifies that the user should leave this router and use the independent direct entry.
 
-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.
-
-Pipeline Path candidate when any are true:
-- Multiple independent features or a batch implementation request.
+A Pipeline Path candidate has one or more of these signals:
+- Multiple independent features or a batch 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.
+- New data model, API design, infrastructure, external service, or dependency ordering.
+- Autonomous/background execution intent.
+- A need for `feature-planner` to clarify, split, validate, and review feature entries.
+
+Do not perform full decomposition here.
 
 ### Step 3: Ask for path selection
 
 Use `AskUserQuestion`; do not render path options as plain text.
 
-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 simplified /prizmkit-plan -> /prizmkit-implement -> conditional test/review/retro -> /prizmkit-committer
-- Use Pipeline Path — feature-planner creates/reviews feature-list.json, then feature-pipeline-launcher configures execution
+- Use Direct Path — leave this router and invoke the direct single-requirement workflow independently
+- Use Pipeline Path — feature-planner creates/reviews feature-list.json, then feature-pipeline-launcher constructs the runtime command
 - Continue clarifying — ask a few more route-level questions before choosing
 ```
 
-For greenfield app work:
+For greenfield work, offer `Start app-planner (Recommended)`, `Feature-plan anyway`, or `Continue clarifying`.
 
-```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
-```
+For an auto-discovered list, offer:
+- Construct command for 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 plan the new request.
 
-For an auto-discovered existing feature list:
-
-```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
-```
-
-If the user explicitly asked to run an existing list, that explicit request counts as path selection; hand off directly to `feature-pipeline-launcher`.
+An explicit request for an existing-list command counts as path selection; hand off directly to `feature-pipeline-launcher`.
 
 ## Workflow Handoff Brief
 
-When handing off, include this prompt brief in the next skill invocation. Do not write the brief to disk.
+When handing off to a planner or launcher, include this prompt brief in the invocation. Do not write it to disk.
 
 ```markdown
-## Workflow Handoff Brief
-
 ### Source
 - workflow: feature-workflow
-- selected_path: fast_path | pipeline_path | existing_list_launch | app_planning_first
+- selected_path: pipeline_path | existing_list_command | app_planning_first
 
 ### User Goal
 - original_request: <preserve the user's wording>
@@ -146,97 +139,77 @@ When handing off, include this prompt brief in the next skill invocation. Do not
 - user_confirmed: yes
 
 ### 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.
+- Planner: perform required clarification, validation, generation, and planner-local review; return the validated artifact without starting execution.
+- Launcher: own runtime configuration and command construction; do not re-plan the list or execute the command.
 ```
 
+The direct path has no planner/launcher handoff brief. Preserve the original user request in the exit guidance so the user can enter the direct workflow without losing intent.
+
 ## Selected Path Execution
 
-### Greenfield app path
+### Greenfield app planning
 
 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.
-
-### Fast Path
+2. Let it produce application-planning artifacts only.
+3. After completion, ask whether to decompose the app into features.
+4. If yes, invoke `feature-planner`.
+5. After a validated feature list returns, ask whether to construct the runtime command.
 
-Use Fast Path only after explicit user selection.
+### Direct Path guidance
 
-1. Invoke `/prizmkit-plan` with the handoff brief; use simplified planning for this scoped feature.
-2. Invoke `/prizmkit-implement` after the plan is ready.
-3. Run `/prizmkit-test` only when risk triggers match: behavior, public interface, data model, security/permission/payment, deployment readiness, or explicit user verification request.
-4. Run `/prizmkit-code-review` when the user requested review, implementation uncertainty is high, or Full-path-level risk appears during implementation.
-5. Run `/prizmkit-retrospective` only when structure, interfaces, dependencies, behavior, or durable project knowledge changed.
-6. Run `/prizmkit-committer` with a `feat(<scope>):` message.
-7. End the workflow after commit; do not call `feature-planner`, `feature-pipeline-launcher`, or monitoring.
+1. Confirm that the request is one formal requirement.
+2. Explain the independent direct topology in §Execution Topology.
+3. Preserve the original request in one concise next-entry instruction.
+4. End `feature-workflow`. Do not start coding, invoke lifecycle skills, monitor the direct workflow, or reclaim control after it begins.
 
-If implementation scope grows beyond the Fast Path criteria, pause and ask whether to switch to Pipeline Path.
+If the request grows beyond one requirement, remain in this router and ask whether to use Pipeline Path.
 
 ### Planner handoff — Pipeline Path
 
 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`.
+2. The planner owns deep clarification, decomposition, validation, and plan review.
+3. After it returns a validated `.prizmkit/plans/feature-list.json`, show item count, major dependencies, and review/validation outcome.
+4. Ask whether to construct the runtime command.
+5. If yes, invoke `feature-pipeline-launcher`.
 
-Do not duplicate launcher execution-mode or configuration questions in this workflow; the launcher owns them.
+Do not duplicate launcher configuration questions in this workflow.
 
-### Existing list launch
+### Existing list command
 
-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.
-
-If this workflow discovered the list on its own, use the `Existing feature-list.json found` question in §Route Selection before invoking the launcher.
+Route explicit run/status/logs/retry/stop command requests to `feature-pipeline-launcher`. For an auto-discovered list, first ask construct command / inspect / update.
 
 ## Resume Guidance
 
 | 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 |
-
-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.
-
-## Runtime Status Reference
-
-This workflow does not assemble runtime commands, but it may show lightweight status before handoff or recovery. Use the canonical Python runtime forms:
-
-```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.
+| Direct workflow state exists | Exit this router and tell the user to resume its recorded requirement workflow |
+| Valid `.prizmkit/plans/feature-list.json` exists and a runtime command is requested | Invoke `feature-pipeline-launcher` |
+| Valid feature list exists but intent is unclear | Ask construct command / inspect / update |
+| Interrupted feature task branch exists | Route to `recovery-workflow` for the exact continuation command |
+| No planning artifacts | Start route selection |
 
 ## Error Handling
 
 | 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 |
+| Request is app-level | Route to `app-planner` |
+| User wants planning only | Route to `feature-planner` and stop after its summary |
+| User wants an existing-list command | Route to `feature-pipeline-launcher` |
+| Direct candidate becomes a batch | Keep control here and offer Pipeline Path |
+| Planner needs more detail | Let `feature-planner` ask its own questions |
+| Launcher finds configuration issues | Let `feature-pipeline-launcher` own remediation and command reconstruction |
 
 ## Handoff Map
 
 | From | To | Condition |
 |---|---|---|
 | `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 |
+| `feature-planner` | `feature-workflow` | Planning completed from this workflow's Pipeline Path |
+| `feature-workflow` | `feature-pipeline-launcher` | User requests command construction or an existing-list operation |
 
 ## Output
 
-- Fast Path: concise `spec.md`, simplified `plan.md`, code changes, conditional test/review evidence when triggered, Prizm docs sync only when durable knowledge changed, 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.
+- Direct guidance: independent direct-entry topology and preserved requirement text; no implementation result.
+- Pipeline Path: handoff brief, validated `.prizmkit/plans/feature-list.json`, and a command returned by `feature-pipeline-launcher`.
+- Greenfield path: application-level planning artifacts, optionally followed by feature planning and command construction.