v2.24.0

# Spec: `utility-pm-workflow-orchestrator` (dispatch skill)

**Status:** SPEC / build-ready. Derived from the approved design.
**Date:** 2026-06-01
**Parent design:** [`design_plan-orchestrator.md`](design_plan-orchestrator.md) (sections 2.2, 4, 5, 6, 8)
**Master plan:** [`plan_v2.24.0.md`](plan_v2.24.0.md)
**Target release:** v2.24.0 (additive MINOR)
**Component:** 2 of 3 (engine sub-agent, THIS dispatch skill, plan-handoff). The engine spec is `spec_pm-workflow-orchestrator-engine.md`; the plan-handoff spec is `spec_prioritized-action-plan-handoff.md`.
**Pattern siblings:** [`skills/utility-pm-release-conductor/SKILL.md`](../../../../skills/utility-pm-release-conductor/SKILL.md) (structural model), plus the three other dispatch skills (`utility-pm-critic`, `utility-pm-skill-auditor`, `utility-pm-changelog-curator`).

This is the dispatch ("control-panel") component: the cross-client user interface that dispatches to the native engine sub-agent on Claude Code, or reads the engine definition and runs the loop inline on every other client. It owns no execution logic of its own beyond runtime detection, the dual-mode dispatch, the tool-capability pre-flight, the `--dry-run` readiness probe, and the honest status surface. The parse contract, run loop, step-status rubric, and refusals are the engine's; both the engine and this skill's inline branch read them from one shared reference file (`references/PARSE-CONTRACT.md`) to avoid prompt/inline drift (D12 referential discipline).

---

## 1. Purpose

`utility-pm-workflow-orchestrator` is the cross-client front door to the plan orchestrator. It does the same job for the orchestrator that `utility-pm-release-conductor` does for the release conductor: detect the runtime, dispatch to the native sub-agent where one exists (Claude Code), and reference-and-execute the same behavior inline where it does not (every non-Claude client).

The orchestrator runs an ordered sequence of pm-skills against a single input - either a saved `foundation-prioritized-action-plan` (Mode A) or a user-named chain plus context (Mode B) - pausing for human go/no-go by default and refusing to advance past a failed or empty step. This skill is the user-facing surface for that engine; the engine system prompt lives at `agents/pm-workflow-orchestrator.md`.

Two non-negotiable honesty commitments distinguish this skill from a copy of the conductor's:

- The orchestrator ships **EXPERIMENTAL on ALL non-Claude clients, including Codex** (design section 6.2), not "DRY-RUN VALIDATED by inheritance." It writes up to three full PM artifacts and may thread state, which is strictly harder than the conductor and has never been live-validated off Claude Code.
- Until a live smoke test confirms native sub-agent-to-skill delegation via the `Skill` tool works in the installed plugin (design section 12 residual question 1), even the Claude Code native path ships **EXPERIMENTAL**, exactly as the conductor labels its non-Claude path.

## 2. Skill identity

- **Classification:** `utility` (a dispatch wrapper, not a PM work product). This is why the skill is exempt from the three-thread sample requirement (section 9.3).
- **Family:** the FIFTH dispatch skill of the `utility-pm-{role}` family (critic, auditor, curator, conductor, orchestrator).
- **Invocation lifetime:** spans the full run; many steps and confirmation pauses.
- **Execution model:** DELEGATE. Dispatches to the engine sub-agent (Claude Code) or reads `agents/pm-workflow-orchestrator.md` and walks the loop inline (non-Claude). Never re-implements skill methods, never authors PM artifacts itself.
- **Proactive:** NO. Explicit invocation only, modeled on the conductor. The description carries no "use proactively" phrasing (design section 7.3, copy-paste hazard flagged because `pm-critic`'s frontmatter does carry it).
- **Composes with:** the engine (`agents/pm-workflow-orchestrator.md`), the shared `references/PARSE-CONTRACT.md`, and `skills/foundation-prioritized-action-plan/` (its producer, which hands plans to this skill in v1.1.0 HANDOFF mode).

## 3. Component design

### 3.1 Three pieces (design section 2.2)

The skill body is three pieces, structurally mirroring `utility-pm-release-conductor`:

1. A lightweight prose **"Runtime detection step"** line (no programmatic probe; the model reads the client signals it already has).
2. A Claude Code **native-dispatch H3 branch**: invoke `@agent-pm-skills:pm-workflow-orchestrator` with the input plus flags from `$ARGUMENTS`, relay the engine's per-step output to the main chat.
3. A non-Claude **inline-execution H3 branch**: read `agents/pm-workflow-orchestrator.md`, treat its body as this-turn operating instructions, read `references/PARSE-CONTRACT.md`, run the tool-capability pre-flight, then walk the loop inline.

### 3.2 Dual-mode runtime detection (design section 6)

Run mode (CHECKPOINTED vs GUARDED AUTO) is orthogonal to mechanism (native vs inline); mechanism is set by the client, run mode by the user's flags. The detection step routes to exactly one of the two H3 branches.

**Claude Code (native):** the skill invokes the engine sub-agent; the engine delegates each step via the `Skill` tool to the real downstream skill, runs in its own isolated context window, and surfaces the per-step block and artifacts back to the main chat. Because the empirical-verification gate (design section 6.1) is not yet closed, the skill labels this path EXPERIMENTAL and instructs running `--dry-run` first.

**Non-Claude (reference + execute inline):** no separate sub-agent context. The skill reads `agents/pm-workflow-orchestrator.md`, treats its body as operating instructions, and at each step reads the downstream skill's `SKILL.md` and executes its method inline in the same window. Both run modes apply inline. This is the same "reference + execute inline" pattern the conductor's non-Claude branch uses, scaled to a write-heavy multi-artifact flow.

### 3.3 Tool-capability pre-flight (design section