Plan Orchestrate

Bridge a plan document to the current ECC slash-command surface by emitting one ready-to-paste command per step. This skill is a router only: it picks the command and fills in the command's own documented argument form. It does not compose agent chains and does not influence what a command runs internally — each command owns its own execution behavior. The skill is generative only; it never executes commands. The user pastes each line when ready.

When to Use

• User has a multi-step plan document (PRD, RFC, implementation plan) and wants ready-to-paste commands for each step.
• User says "turn this plan into commands", "what command should I run for each step", "orchestrate this plan".
• A step-by-step plan exists but the user does not want to manually pick a command per step.

Skip when:

• The work is one ad-hoc step → run the appropriate slash command directly (see the catalogue below).
• The plan is unreadable or empty. Lack of explicit numbering alone is not a skip condition — see the "No clear steps" edge case below.
• The plan should run autonomously in the background → prefer dmux-workflows or the native workflows/*.workflow.js scripts instead.

Inputs

<plan-doc-path> [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]

• <plan-doc-path> — required; relative or absolute path (@docs/... accepted).
• --scope — limits emitted steps; defaults to all.
• --dry-run — print decomposition + command rationale only; do not emit final commands.

Scope rule — a step is only emitted if the command can carry it

Every emitted command must carry its step's identity and scope. A command accepts arguments only in the form its own file documents (frontmatter argument-hint or a ## Usage section; docs/COMMAND-REGISTRY.json is the generated index). The only form that carries a plan step is a free-form task-description argument, because that argument travels with the command when it is pasted.

Scope-carrying commands — accept a free-form task description:

Everything else fails closed. Commands whose documented arguments cannot carry plan scope — /build-fix, /test-coverage, /update-docs (no argument form at all), /code-review (only [pr-number | pr-url | blank]), /security-scan ([path] and format/severity flags only), /loop-start ([pattern] and --mode only) — are never emitted. A step that classifies to one of them is reported as:

BLOCKED — /<command> cannot carry plan scope; run manually if wanted: <exact documented command form>

Blocked steps appear in the overview and per-step output and are excluded from the Batch execution block. This is deliberate: a bare /update-docs pasted inside a five-step batch has no machine-readable link to the step it was planned for. The user can still run the manual command themselves; the router just refuses to present an unscoped command as if the step were orchestrated.

This table is a validated snapshot of the command files, not an independent source of truth. tests/skills/plan-orchestrate-registry.test.js validates every command named here against commands/<name>.md and docs/COMMAND-REGISTRY.json and fails when they disagree. If a command file and this skill ever disagree at runtime, the command file wins. A command that has since been retired from commands/ fails closed like a no-argument command — the step is reported BLOCKED and the router never emits a name the command surface no longer has.

Task description (scope-carrying commands only)

For scope-carrying commands, each emitted <task description> must:

• Be self-contained (the command does not need the plan document open).
• Start with [Plan: <path>#step-<id>] — this marker is the step's machine-readable link.
• Include 1–3 verifiable acceptance criteria.
• Include a Scope guard (Out of scope: ...) only if the plan declares one for this step. Inherit verbatim. If the plan has no out-of-scope statement, omit the clause entirely — do not invent one.
• Be 200–600 characters; one line; embedded " escaped as \"; no literal newlines.

…