diff --git a/.coderabbit.yaml b/.coderabbit.yaml
index b5ec2673..5a3b2bb4 100644
--- a/.coderabbit.yaml
+++ b/.coderabbit.yaml
@@ -61,8 +61,9 @@ reviews:
     - label: "workflow-structure"
       instructions: >-
         Apply when the PR changes SKILL.md, guidelines.md, controller.md,
-        or adds/removes/renames files in skills/ or commands/ directories.
-        Structural changes affect how AI agents discover and execute workflows.
+        dispatch.md, completion.md, or adds/removes/renames files in skills/
+        or commands/ directories. Structural changes affect how AI agents
+        discover and execute workflows.
 
     - label: "new-workflow"
       instructions: >-
@@ -153,15 +154,21 @@ reviews:
           step-by-step instructions or decision logic
         - Must include $ARGUMENTS placeholder to pass user context
         - Path references must be relative to the command file's location:
-          use ../skills/controller.md or ../SKILL.md, not absolute paths
-          and not skills/controller.md (missing ../ prefix)
-        - Every command must have a corresponding skill file it routes to
+          use ../skills/controller.md, ../skills/dispatch.md, ../SKILL.md,
+          or a direct phase-skill path; do not use absolute paths or omit
+          the required ../ prefix
+        - Every command must route to its corresponding phase, either through
+          a direct file reference or an explicit phase parameter passed to a
+          dispatcher (for example, PHASE=assess)
         - No IDE-specific syntax
 
-    # ── Phase skill files ───────────────────────────────────────
+    # ── Workflow skill files ────────────────────────────────────
     - path: "*/skills/*.md"
       instructions: |
-        Phase skill review (ai-workflows conventions):
+        Workflow skill review (ai-workflows conventions):
+        - First classify the file as a phase implementation, controller,
+          dispatcher, completion guide, or other support file. Apply
+          phase-specific rules only to phase implementations.
         - Maximum 10 steps per skill invocation — flag if exceeded
           (cognitive load / context window risk for AI agents)
         - Main steps must be numbered sequentially: no gaps, no
@@ -174,8 +181,17 @@ reviews:
         - Synthesis tasks (summarization, assessment, verdict) must NOT
           be buried after heavy per-item processing — they degrade in
           long contexts
-        - controller.md must reference sibling skills as phase-name.md
-          (not skills/phase-name.md) — relative to its own directory
+        - controller.md, dispatch.md, and completion.md must reference sibling
+          skill files as file-name.md (not skills/file-name.md) — relative to
+          their own directory
+        - A controller may centrally dispatch phases and own transitions, or
+          limit itself to discovery and ambiguous-input routing when explicit
+          commands use a lightweight dispatcher
+        - A dispatcher must remain a thin router: resolve the requested phase,
+          preserve override behavior and context, and delegate transition
+          decisions rather than implementing phase logic
+        - A completion guide may centralize next-step recommendations so phase
+          files do not duplicate the workflow transition model
         - Skills referencing _shared/ resources must use the correct
           relative path depth (e.g., ../../_shared/recipes/self-review-gate.md
           from skills/)
@@ -699,20 +715,28 @@ reviews:
           that exist. Flag references to files that don't exist (dangling
           references). Also flag skill or command files that exist but
           are never referenced from SKILL.md, controller.md, or any
-          command file (orphaned files). For skills/* simple skills, require
+          command file (orphaned files). Treat an explicit dispatcher parameter
+          such as PHASE=assess as a reference to skills/assess.md when the
+          dispatcher documents that mapping. Treat files referenced by a
+          reachable dispatcher or completion guide as reachable. For skills/*
+          simple skills, require
           only that supporting resources are reachable from SKILL.md or another
           reachable reference; do not require workflow-specific files.
         mode: "warning"
 
       - name: "no-content-duplication"
         instructions: |
-          When any of SKILL.md, guidelines.md, or controller.md in a
-          workflow is changed, compare it against whichever of the other
-          two files are present and check for verbatim duplication of
+          When any of SKILL.md, guidelines.md, controller.md, dispatch.md, or
+          completion.md in a workflow is changed, compare it against the other
+          architectural files that are present and check for duplication of
           multi-line instruction blocks or paragraphs. Each has a distinct
           role: SKILL.md is
           the thin entry point, guidelines.md holds principles/limits/
-          safety/quality/escalation, controller.md manages phase dispatch.
+          safety/quality/escalation. A controller may own centralized phase
+          routing and transitions; in a demand-loaded design it handles
+          discovery and ambiguous routing, dispatch.md handles explicit phase
+          routing, and completion.md may hold the authoritative transition
+          model.
           Phase names and brief one-line descriptions appearing in
           multiple files is EXPECTED (cross-referencing, not duplication)
           — only flag substantial blocks of identical prose or
diff --git a/AGENTS.md b/AGENTS.md
index 23970470..2a035646 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -37,10 +37,12 @@ workflow-name/
   guidelines.md         # Behavioral rules: principles, hard limits, safety, quality
   README.md             # Human-readable documentation (prerequisites, artifacts, usage)
   skills/
-    controller.md       # Optional phase dispatcher
+    controller.md       # Optional discovery and ambiguous-input router
+    dispatch.md         # Optional lightweight explicit-phase dispatcher
+    completion.md       # Optional centralized next-step guidance
     phase-name.md       # Implementation for each phase
   commands/
-    phase-name.md       # Thin wrappers that invoke controller or SKILL.md
+    phase-name.md       # Thin wrappers that invoke a controller, dispatcher, SKILL.md, or phase
   scripts/              # Optional — deterministic operations invoked by skills
   prompts/              # Optional — prompt templates for sub-agent delegation
 ```
@@ -69,7 +71,7 @@ guidelines, README, or artifact lifecycle by default.
 3. **Relative paths**: All file references must be relative to the file's location (for symlink compatibility)
 4. **Phase-based execution**: Most workflows operate through discrete phases with explicit transitions
 5. **Shared resources**: Cross-cutting concerns live in `_shared/` and are referenced by relative path from workflows or simple skills
-6. **Phase overrides**: Projects can override individual phases by placing a replacement skill file at `.workflows/{workflow}/skills/{phase}.md` in their repo root. The controller checks for this override before falling back to the built-in default. See CONTRIBUTING.md for details.
+6. **Phase overrides**: Projects can override individual phases by placing a replacement skill file at `.workflows/{workflow}/skills/{phase}.md` in their repo root. The controller or lightweight dispatcher checks for this override before falling back to the built-in default. See CONTRIBUTING.md for details.
 
 ### Shared Resources (`_shared/`)
 
@@ -95,8 +97,8 @@ Recipes are self-contained, parameterized procedures that packages reference via
 ### File Reference Conventions
 
 Critical for symlink resolution:
-- `commands/*.md` reference `../skills/controller.md` (if workflow has a controller) or `../SKILL.md` (for workflows without a controller) or `../skills/phase-name.md` (direct phase reference)
-- `skills/controller.md` (when present) references sibling skills as `phase-name.md` (not `skills/phase-name.md`)
+- `commands/*.md` reference `../skills/controller.md`, `../skills/dispatch.md`, `../SKILL.md`, or `../skills/phase-name.md`; dispatchers identify the target with an explicit phase parameter
+- `skills/controller.md`, `skills/dispatch.md`, and `skills/completion.md` reference sibling skills as `phase-name.md` (not `skills/phase-name.md`)
 - `SKILL.md` references `guidelines.md` and optionally `skills/controller.md` (same directory)
 - `skills/{skill-name}/SKILL.md` references its resources relative to the simple skill directory (for example, `references/rendering.md`)
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a41d13ff..df594f3a 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -37,10 +37,12 @@ workflow-name/
   guidelines.md         # Behavioral rules: principles, hard limits, safety, quality, escalation
   README.md             # Human-readable documentation
   skills/
-    controller.md       # Optional -- phase dispatch, transitions, next-step recommendations
+    controller.md       # Optional -- workflow routing and orchestration
+    dispatch.md         # Optional -- lightweight explicit-phase dispatch
+    completion.md       # Optional -- centralized next-step recommendations
     phase-name.md       # One file per phase
   commands/
-    phase-name.md       # Thin wrappers that invoke the controller or SKILL.md for a specific phase
+    phase-name.md       # Thin wrappers that invoke a router, SKILL.md, or phase
 
 Project-level phase overrides (in the consuming repo):
 
@@ -78,12 +80,16 @@ Some workflows use a controller to manage phase execution and transitions. This
 
 - List all phases with references to sibling skill files (e.g. `assess.md`, not `skills/assess.md`).
 - Define how to execute a phase (announce, read, execute, report, wait).
-- Provide next-step recommendations after each phase.
+- Provide next-step recommendations after each phase, directly or through a
+  dedicated completion guide.
 - Never auto-advance -- always wait for the user.
 
 ### skills/phase-name.md
 
-Each phase skill contains the detailed steps for that phase. At the end, it should instruct the agent to report findings and re-read the controller for next-step guidance.
+Each phase skill contains the detailed steps for that phase. At the end, it
+should report findings and follow the workflow's completion contract: either
+return to the invoking router, read a completion guide, or re-read the
+controller, as defined by that workflow.
 
 ### commands/phase-name.md
 
@@ -99,13 +105,21 @@ Dispatch the **phase-name** phase. Context:
 $ARGUMENTS
 ```
 
-The path `../skills/controller.md` is relative to the command file's location inside `commands/`. If the workflow has no controller, commands can reference `../SKILL.md` or the phase skill directly.
+The path `../skills/controller.md` is relative to the command file's location
+inside `commands/`. A workflow may instead use a lightweight
+`../skills/dispatch.md` from its command wrappers to resolve overrides and load
+only the requested phase and a dedicated completion guide. Migrate workflows
+separately so each change can account for its routing and override contracts.
+If the workflow has no controller or dispatcher, its command wrapper or
+`../SKILL.md` entry point must perform the same override resolution before
+reading the resolved phase file. Never bypass override resolution by reading a
+phase skill directly.
 
 ## Path Conventions
 
 All internal file references must be **relative to the file's own location**:
 
-- `commands/*.md` reference the controller as `../skills/controller.md` (or `../SKILL.md` if no controller)
+- `commands/*.md` reference `../skills/controller.md`, `../skills/dispatch.md`, `../SKILL.md`, or a phase skill directly
 - `skills/controller.md` (when present) references sibling skills as `assess.md`, `fix.md`, etc.
 - `SKILL.md` references `guidelines.md` and optionally `skills/controller.md` (both in the same directory)
 
@@ -115,21 +129,23 @@ This ensures symlinks resolve paths correctly regardless of where the workflow i
 
 ## Phase Overrides
 
-Projects can override individual phase skills without forking the workflow. When a controller dispatches a phase, it checks for a project-level override before falling back to the built-in default:
+Projects can override individual phase skills without forking the workflow. Every phase route—whether invoked through a controller, dispatcher, workflow entry point, or command wrapper—must resolve the phase filename and check for a project-level override before falling back to the built-in default:
 
-1. **`.workflows/{workflow}/skills/{phase}.md`** — project-level override at the repo root
-2. **`{phase}.md`** — workflow's built-in default (sibling file in `skills/`)
+1. **`.workflows/{workflow}/skills/{phase-file}`** — project-level override at the repo root
+2. **`{phase-file}`** — workflow's built-in default (sibling file in `skills/`)
 
-For example, a team that needs a custom `/sync` phase for the design workflow drops a file at `.workflows/design/skills/sync.md` in their repo. The controller picks it up automatically and announces the override to the user.
+For example, a team that needs a custom `/sync` phase for the design workflow drops a file at `.workflows/design/skills/sync.md` in their repo. The route resolves that file and announces the override to the user.
 
-**Filename mapping.** Most workflows map `/phase` to `{phase}.md`, but some use different filenames. For example, docs-writer maps `/gather` to `gather-context.md` and `/plan` to `plan-structure.md`. Check the Phases list in the workflow's controller to find the correct filename for the override.
+**Filename mapping.** Determine `{phase-file}` once from the workflow's routing documentation—its controller, dispatcher, or documented phase map—and use that same filename for both the project override and built-in fallback. Most workflows map `/phase` to `{phase}.md`, but some use different filenames. For example, docs-writer maps `/gather` to `gather-context.md` and `/plan` to `plan-structure.md`.
 
 ### Rules for Override Files
 
-- **Start from a copy.** Copy the built-in phase file and modify it rather than writing from scratch. This avoids accidentally omitting contract scaffolding such as artifact paths, exit behavior, or the controller re-read instruction.
+- **Start from a copy.** Copy the built-in phase file and modify it rather than writing from scratch. This avoids accidentally omitting contract scaffolding such as artifact paths and exit behavior.
 - **Full replacement.** An override replaces the entire phase — it is not merged with the built-in. The override file must be self-contained.
-- **Same contract.** The override must read the same input artifacts and write the same output artifacts as the built-in phase. Downstream phases and the controller depend on this contract (see the Artifacts table in each controller).
-- **Same exit behavior.** End the override file with the same "report findings and re-read the controller" instruction so the controller can recommend next steps.
+- **Same contract.** The override must read the same input artifacts and write the same output artifacts as the built-in phase. Downstream phases and the workflow router depend on this contract (see the workflow's Artifacts table).
+- **Same exit behavior.** Preserve the built-in phase's completion contract.
+  Depending on the workflow, that may return to the invoking router, read a
+  completion guide, or re-read the controller.
 - **No cross-references to built-in internals.** The override should not reference sibling files in the workflow's `skills/` directory — it lives in the project repo and should be self-contained.
 
 ### Version Control
@@ -138,7 +154,7 @@ Commit `.workflows/` to the consuming repo. Overrides are team-level decisions 
 
 ### Discoverability
 
-When a project uses overrides, document them in the project's `CLAUDE.md` or `AGENTS.md` so newcomers know which phases behave differently from the built-in defaults. The controller announces overrides at runtime, but a static list prevents surprises when reading workflow documentation.
+When a project uses overrides, document them in the project's `CLAUDE.md` or `AGENTS.md` so newcomers know which phases behave differently from the built-in defaults. The route announces project overrides at runtime, but a static list prevents surprises when reading workflow documentation.
 
 ### Example Project Layout
 
@@ -254,7 +270,7 @@ for example `$bugfix assess`.
 
 1. Install locally: `./install.sh cursor` (or `all`).
 2. Open a Cursor project and reference the package to verify discovery.
-3. For a workflow, run at least one phase and verify controller dispatch. For a
+3. For a workflow, run at least one phase and verify its configured routing. For a
    simple skill, exercise its primary behavior and permission gates.
 4. Run every changed script's tests and the same checks configured in CI.
 5. Uninstall and reinstall to verify clean teardown: `./uninstall.sh && ./install.sh cursor`.
diff --git a/_shared/recipes/phase-override-resolution.md b/_shared/recipes/phase-override-resolution.md
index 9e171306..c50197b1 100644
--- a/_shared/recipes/phase-override-resolution.md
+++ b/_shared/recipes/phase-override-resolution.md
@@ -1,6 +1,6 @@
 ---
 name: phase-override-resolution
-version: 0.1.0
+version: 0.1.1
 ---
 # Recipe: Phase Override Resolution
 
@@ -23,9 +23,13 @@ default. Use the first match found:
    at the repo root
 2. **`{PHASE_FILE}`** — workflow's built-in default (sibling file in `skills/`)
 
-If the override file exists but is empty, appears malformed, or does not
-contain exit instructions to re-read the controller, warn the user and fall
-back to the built-in default.
+If the override file exists but is empty, appears malformed, or does not end
+with a detectable terminal instruction, warn the user and fall back to the
+built-in default. The terminal instruction must explicitly direct one supported
+exit: return control to the invoking router, read a completion guide, or re-read
+a controller. The invoking workflow's router determines which supported exits
+it accepts or normalizes; preserve the built-in phase's behavioral contract
+without requiring one routing architecture for every workflow.
 
 If using a project override, announce it: *"Using project override for
 /{phase}."*
diff --git a/bugfix/SKILL.md b/bugfix/SKILL.md
index a1e3c054..ef99c1c3 100644
--- a/bugfix/SKILL.md
+++ b/bugfix/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: bugfix
-version: 0.7.0
+version: 0.7.1
 description: >-
   Diagnostic and repair workflow that analyzes error logs, traces root causes,
   implements fixes, and verifies with regression tests.
diff --git a/code-review/SKILL.md b/code-review/SKILL.md
index 683328ff..80a22955 100644
--- a/code-review/SKILL.md
+++ b/code-review/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: code-review
-version: 0.4.0
+version: 0.4.1
 description: >-
   AI-driven code review workflow that reviews uncommitted changes using a
   discoverable reviewer profile, presents findings for human decision, and
diff --git a/cve-fix/SKILL.md b/cve-fix/SKILL.md
index a3183a01..9d850e56 100644
--- a/cve-fix/SKILL.md
+++ b/cve-fix/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: cve-fix
-version: 0.4.0
+version: 0.4.1
 description: >-
   Automated CVE remediation that reads vulnerability details from Jira
   vulnerability tickets, applies multi-strategy dependency fixes, validates
diff --git a/design/SKILL.md b/design/SKILL.md
index d75938a3..fdc4968f 100644
--- a/design/SKILL.md
+++ b/design/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: design
-version: 0.9.0
+version: 0.9.1
 description: >-
   Design-and-decompose workflow that takes a PRD, researches the problem space,
   drafts a technical design document with a requirement-anchored testplan,
diff --git a/docs-writer/SKILL.md b/docs-writer/SKILL.md
index 69e919be..b4ca9873 100644
--- a/docs-writer/SKILL.md
+++ b/docs-writer/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: docs-writer
-version: 0.3.0
+version: 0.3.1
 description: Documentation workflow that converts requirements into structured AsciiDoc sections, runs Vale for style compliance, and produces merge-ready content. Use when creating or updating AsciiDoc documentation from Jira tickets, GitHub issues, or feature descriptions.
 ---
 # Docs Writer Workflow Orchestrator
diff --git a/e2e/SKILL.md b/e2e/SKILL.md
index 8ee655a1..f097b15c 100644
--- a/e2e/SKILL.md
+++ b/e2e/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: e2e
-version: 0.6.0
+version: 0.6.1
 description: >-
   Story-to-e2e-test workflow that takes a Jira [QE] Story, discovers the
   project's e2e testing infrastructure, plans test scenarios, writes e2e
diff --git a/implement/README.md b/implement/README.md
index 5273aa89..dda6986f 100644
--- a/implement/README.md
+++ b/implement/README.md
@@ -40,6 +40,13 @@ graph TD
 | Publish | `/publish` | Push branch, create draft PR | `06-pr-description.md` |
 | Respond | `/respond` | Address reviewer comments | `07-review-responses.md` |
 
+Each phase command invokes `skills/dispatch.md` with the requested phase. The
+dispatcher resolves any project override, loads only that phase, and passes
+along the command context. After the phase reports its result,
+`skills/completion.md` supplies the shared next-step guidance without loading
+the full controller. The controller remains the entry point for workflow
+discovery and ambiguous requests.
+
 ## Typical Flow
 
 ```text
@@ -138,7 +145,9 @@ implement/
 │   ├── 01-context.md           # Ingest context skeleton
 │   └── story-testplan.md       # Story-scoped testplan skeleton
 ├── skills/
-│   ├── controller.md           # Phase dispatcher and transitions
+│   ├── controller.md           # Discovery and ambiguous-input router
+│   ├── dispatch.md             # Explicit-phase dispatcher
+│   ├── completion.md           # Shared next-step guidance
 │   ├── ingest.md               # Fetch story, explore codebase
 │   ├── plan.md                 # Design implementation approach
 │   ├── revise.md               # Incorporate plan feedback
diff --git a/implement/SKILL.md b/implement/SKILL.md
index d122d10b..b9fab8e8 100644
--- a/implement/SKILL.md
+++ b/implement/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: implement
-version: 0.8.0
+version: 0.9.0
 description: >-
   Story-to-code workflow that takes a Jira Story, plans the implementation,
   writes contract-based tests and production code via TDD, validates against
diff --git a/implement/commands/code.md b/implement/commands/code.md
index 48b26072..b5a828d7 100644
--- a/implement/commands/code.md
+++ b/implement/commands/code.md
@@ -4,8 +4,8 @@ description: "Write tests and production code via TDD, committing incrementally"
 ---
 # /code
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=code`.
 
-Dispatch the **code** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/ingest.md b/implement/commands/ingest.md
index 9f34699e..4c0da7cf 100644
--- a/implement/commands/ingest.md
+++ b/implement/commands/ingest.md
@@ -4,12 +4,8 @@ description: "Fetch Jira story, load design/PRD context, explore codebase, build
 ---
 # /ingest
 
-Read `../skills/controller.md` only if it is not already in this session.
-Resolve the ingest skill via `../../_shared/recipes/phase-override-resolution.md`
-(WORKFLOW=`implement`, PHASE_FILE=`ingest.md`). Read the resolved
-`ingest.md` and execute it. Do not glob this workflow. Do not load
-`guidelines.md` or `gh-stack`. Do not call `GetDynamicTools`.
+Read `../skills/dispatch.md` and follow it with `PHASE=ingest`.
 
-Dispatch the **ingest** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/plan.md b/implement/commands/plan.md
index bfa27ac8..bea0e6bc 100644
--- a/implement/commands/plan.md
+++ b/implement/commands/plan.md
@@ -4,8 +4,8 @@ description: "Design the implementation approach with task breakdown and test st
 ---
 # /plan
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=plan`.
 
-Dispatch the **plan** phase. Open cited files from `01-context.md` (slices only; see `../skills/plan.md` Step 1). Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/publish.md b/implement/commands/publish.md
index fb4cc130..e19bfa97 100644
--- a/implement/commands/publish.md
+++ b/implement/commands/publish.md
@@ -4,8 +4,8 @@ description: "Push branch and create a draft PR in the source repo"
 ---
 # /publish
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=publish`.
 
-Dispatch the **publish** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/respond.md b/implement/commands/respond.md
index 8691f99b..5504e883 100644
--- a/implement/commands/respond.md
+++ b/implement/commands/respond.md
@@ -4,8 +4,8 @@ description: "Fetch PR review comments, propose responses, apply code changes"
 ---
 # /respond
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=respond`.
 
-Dispatch the **respond** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/revise.md b/implement/commands/revise.md
index 8d6f99b4..1e1c92da 100644
--- a/implement/commands/revise.md
+++ b/implement/commands/revise.md
@@ -4,8 +4,8 @@ description: "Incorporate user feedback into the implementation plan"
 ---
 # /revise
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=revise`.
 
-Dispatch the **revise** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/commands/validate.md b/implement/commands/validate.md
index 5eb13854..25a5892e 100644
--- a/implement/commands/validate.md
+++ b/implement/commands/validate.md
@@ -4,8 +4,8 @@ description: "Run tests, lint, coverage analysis, and iterate on gaps"
 ---
 # /validate
 
-Read `../skills/controller.md` and follow it.
+Read `../skills/dispatch.md` and follow it with `PHASE=validate`.
 
-Dispatch the **validate** phase. Context:
+Context:
 
 $ARGUMENTS
diff --git a/implement/skills/code.md b/implement/skills/code.md
index 1c054221..1362ce98 100644
--- a/implement/skills/code.md
+++ b/implement/skills/code.md
@@ -559,4 +559,4 @@ Report your results:
 - Any discoveries
 - Overall implementation status
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/completion.md b/implement/skills/completion.md
new file mode 100644
index 00000000..835a3a6f
--- /dev/null
+++ b/implement/skills/completion.md
@@ -0,0 +1,32 @@
+---
+name: completion
+description: Recommend next steps after one attended implement phase.
+---
+
+# Implement Phase Completion
+
+After the completed `PHASE` reports its results, recommend the best next step
+for the actual outcome, mention relevant alternatives briefly, and stop for the
+user.
+
+- **ingest:** Recommend `/plan` unless the story context has blocking gaps. If
+  the story is contradictory or incomplete, recommend clarification from the
+  story author before planning.
+- **plan:** Recommend `/revise` for user-requested changes, or `/code` when the
+  user has already reviewed and accepted the plan.
+- **revise:** Recommend `/code` when the user is satisfied, or another
+  `/revise` round when further changes remain.
+- **code:** Recommend `/validate`. If implementation exposed a plan gap, note
+  the inline plan update or offer `/plan` when redesign requires user review.
+- **validate:** Recommend `/publish` only when validation passed. When failures
+  remain, recommend fixing them and rerunning `/validate`; offer `/plan` for a
+  design concern or ambiguous acceptance criterion that requires re-scoping.
+- **publish:** Recommend `/respond` when review comments arrive; otherwise the
+  workflow is complete for now.
+- **respond:** Recommend `/validate` after code changes, another `/respond`
+  round while comments remain, or note completion when the PR is approved and
+  no work remains.
+
+The user may start at `/code` with an existing plan or partial implementation,
+and may skip `/publish` and `/respond` when working locally. Never auto-advance
+between attended phases.
diff --git a/implement/skills/controller.md b/implement/skills/controller.md
index a17e3541..4d6a7ee1 100644
--- a/implement/skills/controller.md
+++ b/implement/skills/controller.md
@@ -1,12 +1,13 @@
 ---
 name: controller
-description: Top-level workflow controller that manages phase transitions for story implementation.
+description: Discover and route ambiguous story implementation requests.
 ---
 
 # Implement Workflow Controller
 
-You are the workflow controller. Your job is to manage the implementation
-workflow by executing phases and handling transitions between them.
+Use this controller for workflow discovery and ambiguous-input routing. Once a
+phase is selected, delegate its execution and completion guidance to the
+lightweight dispatcher.
 
 ## Phases
 
@@ -58,100 +59,36 @@ the source repo:
 
 ## How to Execute a Phase
 
-1. **Announce** the phase to the user: *"Starting /plan."*
-2. **Locate** the skill file — read and follow
-   `../../_shared/recipes/phase-override-resolution.md` with
-   WORKFLOW=`implement`, PHASE_FILE=`{phase}.md`.
-3. **Read** the resolved skill file
-4. **Execute** the skill's steps — the user should see your progress
-5. When the skill is done, it will tell you to report findings and
-   re-read this controller. Do that — then use "Recommending Next Steps"
-   below to offer options.
-6. Present the skill's results and your recommendations to the user
-7. **Stop and wait** for the user to tell you what to do next.
-
-## Recommending Next Steps
-
-After each phase completes, present the user with **options** — not just one
-next step. Use the typical flow as a baseline, but adapt to what actually
-happened.
-
-### Typical Flow
-
-```text
-ingest → plan → [revise loop] → code → validate → publish → [respond loop]
-```
-
-### What to Recommend
-
-**Continuing forward:**
-
-- `/ingest` completed → recommend `/plan` (almost always the right next step)
-- `/plan` completed → recommend `/revise` for user review of the plan, or `/code` if the user has already reviewed inline
-- `/revise` completed (user satisfied) → recommend `/code`, or another `/revise` round
-- `/code` completed → recommend `/validate` (always — never skip validation)
-- `/validate` completed (all passing) → recommend `/publish`
-- `/validate` completed (failures remain) → recommend fixing issues, then re-running `/validate`
-- `/publish` completed → recommend `/respond` when review comments arrive
-- `/respond` completed → recommend another `/respond` round, or note that the workflow is done when the PR is approved and merged
-
-**Looping back:**
-
-- `/plan` reveals story gaps or contradictions → suggest the user clarify with the story author or update the story
-- `/code` reveals plan gaps → the plan is updated inline during implementation; offer `/validate` when implementation is complete
-- `/validate` reveals test failures → offer to diagnose and fix, then re-run `/validate`
-- `/validate` reveals a design concern (e.g., low public-API coverage signals a component needs decomposition) → present the concern to the user; user decides whether to loop back to `/plan` for redesign or accept an exception
-- `/validate` reveals unsatisfied acceptance criteria → if fixable (missing tests or implementation gaps), fix during validation; if the criterion is ambiguous or requires re-scoping, escalate to the user
-- `/respond` requires code changes → apply changes, re-run `/validate`, then continue responding
-
-**Skipping:**
-
-- If the user already has a plan or partial implementation, they may start at `/code`
-- If the user wants to skip PR creation (e.g., working locally), `/publish` and `/respond` may be skipped
-
-### How to Present Options
-
-Lead with your top recommendation, then list alternatives briefly:
-
-```text
-Recommended next step: /code — begin TDD implementation following the
-approved plan.
-
-Other options:
-- /revise — if you want to adjust the plan first
-- /validate — if you've already made code changes and want to check them
-```
+Set `PHASE` to the selected phase, then read `dispatch.md` and follow it. The
+dispatcher owns phase announcement, override resolution, execution, and
+completion routing for both built-in phases and project overrides.
 
 ## Starting the Workflow
 
-Before dispatching any phase, check if the project has its own `AGENTS.md`
-or `CLAUDE.md`. If they are **already in this session** (workspace rules
-or a prior read), do not re-read them. Otherwise read them — they may
-contain project-specific conventions, testing standards, or other
-guidance that affects how the workflow operates.
-
-For **ingest**, do not load `guidelines.md`. Those rules apply to
-`/plan` and `/code`. Do not glob the implement workflow directory.
-Do not call `GetDynamicTools`. Write each ingest artifact path once.
-
 When the user provides a Jira issue key or URL:
-1. Execute the **ingest** phase
-2. After ingestion, present results and wait
+1. Set `PHASE=ingest`.
+2. Read `dispatch.md` and follow it.
+
+If the user invokes a specific command (e.g., `/code`), set `PHASE` to that
+command's phase, then read `dispatch.md` and follow it. Do not force the user
+through earlier phases.
 
-If the user invokes a specific command (e.g., `/code`), execute that phase
-directly — don't force them through earlier phases.
+For any other input, summarize the available phases, ask the user for a Jira
+issue key or URL or a specific phase command, and stop without reading
+`dispatch.md`.
 
 ## Error Handling
 
-If any phase fails (Jira MCP errors, build failures, test failures, git
-errors):
+If a phase cannot complete because of an operational error (for example, a
+Jira MCP, build, or git error):
 
 1. **Stop immediately.** Do not advance to the next phase.
 2. **Report the error** to the user with the specific error message.
 3. **Offer options:** retry the failed step, skip the phase (if optional), or escalate.
 
 Do not fabricate results when a tool call fails. Do not silently continue
-past errors.
+past errors. A completed validation report with a failing verdict is a valid
+phase outcome; route it through `completion.md` for fix-and-rerun guidance.
 
 ## Context Management
 
@@ -168,7 +105,8 @@ subagent spawning.
 ## Rules
 
 - **Never auto-advance.** Always wait for the user between phases.
-- **Recommendations come from this file, not from skills.** Skills report findings; this controller decides what to recommend next.
+- **Recommendations come from `completion.md`.** Phase skills report findings;
+  the completion guide provides the authoritative next-step model.
 - **Jira is read-only.** The `/ingest` phase reads from Jira but never modifies it. No phase in this workflow writes to Jira.
 - **Plan evolves during implementation.** `/code` updates `02-plan.md` as tasks are completed. This is expected, not a sign of plan failure.
 - **Validation is mandatory before publishing.** Never recommend `/publish` unless `/validate` has passed.
diff --git a/implement/skills/dispatch.md b/implement/skills/dispatch.md
new file mode 100644
index 00000000..66eebaf1
--- /dev/null
+++ b/implement/skills/dispatch.md
@@ -0,0 +1,26 @@
+---
+name: dispatch
+description: Resolve and execute one explicitly requested implement phase.
+---
+
+# Implement Phase Dispatch
+
+Before dispatching, read the project's `AGENTS.md` or `CLAUDE.md` only if
+neither is already in the session. Then, given `PHASE`, announce
+`Starting /{PHASE}.` and read and follow
+`../../_shared/recipes/phase-override-resolution.md` with `WORKFLOW=implement`
+and `PHASE_FILE={PHASE}.md`. Read and execute the resolved phase file, passing
+through the command context unchanged.
+
+The built-in fallback is the phase file beside this dispatcher. Follow the
+phase through its reporting step. Treat any supported phase exit—returning to
+the invoking router, requesting completion guidance, or re-reading the
+controller—as a return to this dispatcher. Then read `completion.md` and follow
+its guidance for `PHASE`; the dispatcher is the only component that reads the
+completion guide.
+
+If override resolution fails, an operational error prevents the phase from
+completing, or the phase lacks a supported terminal exit, report the failure and
+stop without reading `completion.md`. A completed phase report with a failing
+verdict, including `validate.md` reporting `FAIL`, is a valid outcome: read
+`completion.md` so it can provide fix-and-rerun guidance.
diff --git a/implement/skills/ingest.md b/implement/skills/ingest.md
index ce20c09a..154499ef 100644
--- a/implement/skills/ingest.md
+++ b/implement/skills/ingest.md
@@ -156,4 +156,4 @@ If the user declined overwrite in 7a, report the diff and that existing context
 
 ## Done
 
-Follow `controller.md` only if already in session.
+Return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/plan.md b/implement/skills/plan.md
index 99bafb69..6b0c758b 100644
--- a/implement/skills/plan.md
+++ b/implement/skills/plan.md
@@ -262,4 +262,4 @@ Report your results:
 - Note any risks or open questions
 - Assessment of plan completeness
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/publish.md b/implement/skills/publish.md
index 43985e5b..b58d3e2b 100644
--- a/implement/skills/publish.md
+++ b/implement/skills/publish.md
@@ -226,7 +226,6 @@ Present:
 - PR URL (the full `https://github.com/...` link, not just `owner/repo#number`)
 - Branch name and base
 - Number of commits included
-- Next steps (share with reviewers, wait for comments, then use `/respond`)
 
 ## Output
 
@@ -240,6 +239,5 @@ Present:
 Report your results:
 - PR URL and branch name
 - Commits included
-- Suggested next steps
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/respond.md b/implement/skills/respond.md
index e9e2d8b0..4eb09cab 100644
--- a/implement/skills/respond.md
+++ b/implement/skills/respond.md
@@ -234,4 +234,4 @@ Report your results:
 - Re-validation recommendation
 - Outstanding items
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/revise.md b/implement/skills/revise.md
index cb9c270e..70d729ce 100644
--- a/implement/skills/revise.md
+++ b/implement/skills/revise.md
@@ -124,4 +124,4 @@ Report your results:
 - Any consistency updates made as a side effect
 - Assessment of plan readiness for `/code`
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/implement/skills/validate.md b/implement/skills/validate.md
index 47a51736..6dc12c6e 100644
--- a/implement/skills/validate.md
+++ b/implement/skills/validate.md
@@ -426,4 +426,4 @@ Report your results:
 - Regression status
 - Overall verdict
 
-Then **re-read the controller** (`controller.md`) for next-step guidance.
+Then return to the invoking workflow router for completion guidance.
diff --git a/kcs/SKILL.md b/kcs/SKILL.md
index fa94f1fd..df81331b 100644
--- a/kcs/SKILL.md
+++ b/kcs/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: kcs
-version: 0.3.0
+version: 0.3.1
 description: >-
   KCS article workflow that gathers bug context from Jira and user input,
   drafts a KCS Solution article in markdown, validates it against the KCS
diff --git a/prd/SKILL.md b/prd/SKILL.md
index b8f1a057..4e23ff38 100644
--- a/prd/SKILL.md
+++ b/prd/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: prd
-version: 0.9.0
+version: 0.9.1
 description: >-
   Requirements-to-PRD workflow that ingests requirements from Jira, clarifies
   ambiguities through iterative Q&A, drafts a Product Requirements Document,
diff --git a/sizing/SKILL.md b/sizing/SKILL.md
index 0fe486e8..748e4312 100644
--- a/sizing/SKILL.md
+++ b/sizing/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: sizing
-version: 0.3.0
+version: 0.3.1
 description: >-
   Pre-cycle Feature sizing workflow that assesses Features from Jira using
   T-shirt sizes (XS–XXL), produces per-team effort breakdowns (DEV, QE, UX, UI, DOCS),
@@ -23,8 +23,7 @@ description: >-
      execute the `/ingest` phase in batch mode
    - Otherwise, ask the user for a Feature key or release identifier
 
-If a step fails or produces unexpected output (e.g., Jira MCP errors, network
-failures, invalid issue keys), stop and report the error to the user. Do not
-advance to the next phase. Offer to retry the failed step or escalate.
+If a step fails or produces unexpected output (e.g., Jira MCP errors, network failures,
+invalid issue keys), stop and report the error to the user. Do not advance to the next phase. Offer to retry the failed step or escalate.
 
 For principles, hard limits, safety, quality, and escalation rules, see `guidelines.md`.