/v-orchestrate

description: Materialize a Compound V execution manifest from a plan (or an accepted fast-path pre-eval). Applies the routing policy and writes manifest.yaml plus an initial state.json into docs/superpowers/execution/<run-id>/ — without dispatching. Binds every pre-eval-backed run. Use this to inspect or edit the manifest before /v:dispatch.

You are running **`/v:orchestrate`** — the **materialize** step of Compound V. You turn a verified plan into the machine-readable contract the dispatcher runs: a `manifest.yaml` plus an initial `state.json` in a fresh run directory. This command **does not dispatch** — it produces the manifest and stops, so the user (or `/v:dispatch`) can inspect or edit it first.

The argument is `{{args}}`. It is normally a **plan path**. It may instead be an **accepted fast-path pre-eval** — a `pre_eval_id` (`YYYY-MM-DDThhmmssZ-<slug>-<nonce>`) or a path to `docs/superpowers/pre-eval/<pre_eval_id>.json` whose `decision` is `FASTPATH_ELIGIBLE` — in which case take **Step 0** and stop.

The manifest schema and rules are defined in [`skills/compound-v/execution-manifest.md`](../skills/compound-v/execution-manifest.md); the routing decisions come from [`skills/compound-v/routing-policy.md`](../skills/compound-v/routing-policy.md); the run-dir layout and `state.json` shape come from [`skills/compound-v/state-machine.md`](../skills/compound-v/state-machine.md). Read those — they are the authority; this command is the procedure.

Resolving the plugin root

The `scripts/` this command calls ship with the plugin — they are not files in your own repository. Resolve the plugin root once per session before calling any of them:

CV="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/*/superpowers-v/*/ 2>/dev/null | sort -V | tail -1)}"
CV="${CV:-$PWD}"; CV="${CV%/}"

`CLAUDE_PLUGIN_ROOT` is set for hooks but is not set in this Bash environment, so treat it as a hint, never the whole answer — the fallback line covers an installed plugin cache or a checkout of this repo.

Steps

0a. **Obtain a triage record if there is none (spec §A3).** Every run this command materializes must trace to a committed pre-eval record — `compound-v-validate-manifest.py` requires a well-formed `triage` block, and [`/v:dispatch`](v-dispatch.md) passes `--require-triage` in every mode, so a run without one cannot be dispatched. **Before anything else**, look for a record covering this work:

   ls docs/superpowers/pre-eval/*.json 2>/dev/null | tail -20

A record covers this work when its `localization.resolved_paths` (or `declared_paths`) are the files this plan touches. If `{{args}}` already *is* a `pre_eval_id` or a record path, that is the record — skip to Step 0.

One may already exist without anyone having asked for it: since v3.4 the `UserPromptSubmit` hook (`hooks/triage-prompt-nudge.sh`) runs the same scorer `/v:triage` step T2 runs, once per session, so the record for this work may be sitting there **uncommitted**. If so, commit it (`/v:triage` step T3) and use it rather than minting a second.

**If none exists, run [`/v:triage <the request>`](v-triage.md) now** and use the record it writes and commits. Do not hand-write a record, do not invent a `pre_eval_id`, and do not proceed without one: those two producers are the only ones, and a reconstructed audit trail is the fabricated-evidence pattern rather than a repair. Carry the resulting `pre_eval_id` into Step 6's `state.json`, Step 8b's `bind`, and the manifest's `triage` block.

**Copy the record's `flavor` into the manifest's `triage` block verbatim when it has one.** The only value is `scoped_plus` — a SCOPED-sized change on a sensitive path — and it is a routing *consequence*, not a routing input: it tells this command to give the run a `type: review` job with `tier: deep` and `backend: claude` (`/v:dispatch` step 2 refuses the manifest without one) and it tells step 8 to run the mandatory cross-model second opinion. A record with no `flavor` gets no `flavor` key; never add one to buy a deeper review the scorer did not ask for, and never drop one to skip a review it did.

Triage may come back **DIRECT**. A DIRECT change has no manifest, no run directory and no worktree, so **this command is not its next step**. Implement it in place, run the test floor, and commit it as an ordinary commit together with its record. Only a record that was SCOPED or FULL to begin with arrives here.

0. **Fast-path branch (accepted pre-eval → committed single-job run).** If `{{args}}` resolves to an accepted `FASTPATH_ELIGIBLE` pre-eval record (a `pre_eval_id`, or a `docs/superpowers/pre-eval/<pre_eval_id>.json` path with `decision: FASTPATH_ELIGIBLE`), do **not** run the plan-based flow below — the fast path has no full plan and no three audits. Instead delegate to the deterministic materializer, which runs the authoritative **Phase-M** lifecycle (mint a deterministic run-id from `pre_eval_id` → copy the pinned taxonomy snapshot into the run → write spec/plan **stubs**, block-YAML audit **skip-records**, the single-job `fast_path` manifest with the review **declaration** only, and the captured implementer prompt → **commit all artifacts except `state.json`** → **append + commit the `bind` event** → **commit `state.json` at `FASTPATH_DISPATCHED` LAST**). It also runs the validator in `--mode pre-dispatch` as an in-code gate before binding, so a manifest the validator would reject never reaches dispatch.

   python3 "$CV/scripts/compound-v-fastpath-materialize.py" materialize \
     --repo . --pre-eval-id <pre_eval_id> [--prompt-file <captured-implementer-prompt>]

The materializer is **idempotent + crash-consistent**: a committed `state.json` at `FASTPATH_DISPATCHED` ⇒ the `bind` is already durable ⇒ the run is complete (re-running is a no-op); a run interrupted before `state.json` is rebuilt deterministica