roadmap-to-workflow

Drive an approved roadmap through a dynamic Workflow. This skill collects the roadmap's unchecked items, sorts them into dependency-ordered waves, then invokes the plugin-shipped Workflow driver (skills/_lib/roadmap-driver.js, via the Workflow tool's scriptPath) that, within each wave, plans all items in parallel and then implements, reviews, and ticks them off one item at a time in the shared working tree. It does not hand-roll that fan-out itself, and it does not author the Workflow script — the driver is a static file, inspectable at any time, parameterized only through args (Step 2). If the Workflow tool isn't available, it falls back to running items serially by hand, in the same dependency order (Step 2).

Per-item model control. Each roadmap item may carry a **Model:** hint (haiku | sonnet | opus); the driver passes it to that item's implement agent as opts.model, and scales the plan stage down for lightweight items (a haiku-hinted item is planned by sonnet at low effort; everything else by opus). The review agent ignores it — task:code-reviewer pins its own model, so a haiku item never gets a haiku review.

Per-item execution is a three-agent split by default — opus plans (sonnet for haiku-hinted items), the item's model implements and commits, task:code-reviewer reviews and commits its fixes on top; a fourth, cheap driver stage then ticks the roadmap checkbox (Step 2).

This skill is the opt-in for the Workflow tool — reading it and following the Steps is the authorization; there is no magic keyword and no separate confirmation.

Input: $ARGUMENTS — optional. A single positional <roadmap-slug> (or path) to skip the roadmap picker. No flags — item scope is chosen interactively (Step 0).

Format contract: docs/contract.md § Roadmap file format is the single source of truth for item grammar (### - [ ] N., **Dependencies:**, **Model:**); docs/contract.md § task.md format for the artifact each item's plan agent writes.

Step 0: Setup gate, pick roadmap, pick scope

roadmap-to-workflow is not an intake skill — it never runs setup itself (a roadmap can't exist without .task/CLAUDE.md, so an absent one means something upstream is broken).

echo "$CLAUDE_PLUGIN_ROOT"                                 # note this absolute path — pass it as `pluginRoot` in Step 2's args
source "${CLAUDE_PLUGIN_ROOT}/skills/_lib/resolve-ws.sh"   # sourcing runs find_ai_dir → sets AI_DIR
echo "$AI_DIR"                                             # note this one too — pass it as `aiDir` in Step 2's args
[[ -f "$AI_DIR/CLAUDE.md" ]] || echo "CLAUDE.md not found"
bash "${CLAUDE_PLUGIN_ROOT}/skills/validate/validate.sh" all

• CLAUDE.md not found (the guard above echoes it; validate.sh all also exits 2 with the same message) → hard-stop redirect (do not bootstrap here):

  The project isn't set up yet. Capture something first with /task:to-task, /task:to-plan, /task:to-roadmap, or /task:to-spec — those four set the project up inline. → Next: /task:to-roadmap

• Any other non-zero exit from validate.sh → validate.sh all checks every artifact, so an error may sit on a task or roadmap unrelated to this run. Mind the timing: at this point the roadmap has not been picked yet (that happens in the Roadmap sub-step below), so do not try to judge here which errors are "yours". Surface every reported error now, block on none of them, and hold the roadmap ones. Once <slug> is resolved below, check the held list: if an error was reported against that file, stop then — "→ Next: fix the reported error in .task/roadmap/<slug>.md, then rerun /task:roadmap-to-workflow <slug>". Errors on any other artifact never block. (The one case where the roadmap is already known at gate time is a positional <roadmap-slug> in $ARGUMENTS; there you may apply the check immediately.) WARN lines never set a non-zero exit; they are informational only.