roadmap-to-workflow

The one launcher. Fans an approved .task/roadmap/<slug>.md out to a dynamic Workflow running the plugin's shipped driver script (skills/_lib/roadmap-driver.js) — parallel planning, serialized implementation, dependency-ordered waves, ticking off the roadmap as items land. The skill computes the waves and passes them as arguments; the script itself never changes between runs.

See the autopilot guide for the full walkthrough.

Usage

/task:roadmap-to-workflow [<roadmap-slug>]

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

What it does

1. Scope — asks (via chips) how much to run: all remaining items, just the next dependency-wave, or a picked range like 1,3-5,8.
2. Waves — topologically sorts the unchecked items on **Dependencies:** into waves. A dependency cycle among scoped items is a hard stop.
3. Per item, three agents — the default shape is opus-plans / sonnet-implements / reviewer-reviews: a first agent plans the item (per skills/_lib/plan-driver.md, on sonnet at low effort when the item's **Model:** hint is haiku); a second implements and commits, using the item's **Model:** hint if present; a third is task:code-reviewer, which reviews that commit, proves each finding, fixes the confirmed ones inside the plan's Touches, runs .task/CLAUDE.md → Build and Tests, and amends. Context passes via the on-disk task file, not chat. The reviewer pins its own model, so the item's **Model:** hint never downgrades the review.
4. Parallel plans, serialized implement-then-review — within a wave, all items are planned in parallel (plan agents only write their own task files), then each item is implemented and reviewed strictly one at a time in the shared working tree, both inside the same serial loop. A barrier separates waves, so each implement sees its already-landed wave-mates' reviewed commits.
5. Driver auto-marks — after an item's review returns OK, the driver ticks its checkbox — never the per-item agent, so parallel wave-mates never race on the roadmap file. The flip is idempotent: an already-ticked item is the desired end state, not a failure. It stops the wave only when the roadmap holds no unique ### - [ ] N. heading for that item — renumbered, retitled, or duplicated.

Config

roadmap-to-workflow is not setup-capable — a roadmap can't exist without .task/CLAUDE.md. On a missing one it hard-stops and redirects you to run a capture skill first. This skill is the opt-in for the Workflow tool — reading and running it is the authorization.

Output

One digest line per stage as each wave lands; stop-on-FAIL (an implement or a review FAIL stops the run):

OK #1 migrate-auth-endpoints implemented, committed
OK #1 migrate-auth-endpoints reviewed — 2 fixes, tests green, commit amended
OK #2 update-client-sdk implemented, committed
OK #2 update-client-sdk reviewed — 0 findings, tests green
Ran `api-v2-migration`: 2 of 2 items landed and ticked, 0 still unchecked.
  Commits: a1b2c3d..e4f5a6b.
→ Done. Roadmap complete — `.task/roadmap/api-v2-migration.md` fully checked.

On failure:

FAIL #3 <item-slug> <what failed>
Ran `api-v2-migration`: 2 of 5 items landed and ticked, 3 still unchecked.
  Commits: a1b2c3d..e4f5a6b.
Stopped at #3 <item-slug> in wave 2. Its work is left in the working tree —
  inspect it with `git status` and `git log --oneline -3`.
→ Next: fix #3 (or re-plan it with `/task:to-plan api-v2-migration#3`), then rerun
  `/task:roadmap-to-workflow api-v2-migration` — already-ticked items stay ticked,
  only the unchecked remainder reruns.

Fallback

If the Workflow tool isn't available, it falls back to running items one at a time by hand, in the same wave order — to-plan then a plain implement session, ticking the checkbox before moving on.

Does not

• Run setup on a missing .task/CLAUDE.md — it hard-stops and redirects.
• Loop items in the main session, or re-author the Workflow script inline, instead of invoking the shipped driver (except the documented serial fallback).
• Run an item whose dependencies are still unchecked.
• Auto-mark a checkbox from inside a per-item agent — strictly the driver's job.
• Modify project code itself — all implementation happens inside the per-item implement agents, run one at a time in the shared working tree.