Appearance
Manufacture an approved queue from a vision
Goal: start from a vision doc alone and end with an approved work queue that /warp-drive can consume — without authoring any requirements by hand.
This is the Level 4 "clear the runway" front-end (#869). It sequences the existing PM command skills; it does not reimplement them. For the backbone CLI contract see the Autonomous PM Front-End reference.
Prerequisites
- A vision doc at
docs/vision.md(or pass--path). It must be substantive: a Vision section plus problem/goal/user framing.check-visionfails closed on a thin or missing doc. - The
/business-case,/capability,/requirement, and/groomskills provisioned (they are universal PM commands). ghauthenticated for the repo.
Steps
1. Confirm the vision is usable
bash
node ~/.claude/scripts/warp-drive/pm-frontend.js check-vision --jsonok: true → proceed. ok: false → the reasons[] tell you what is missing (no Vision heading, too thin, no problem/goal framing). Do not invent a vision — an absent vision is a human-only blocker.
2. Get the plan
bash
node ~/.claude/scripts/warp-drive/pm-frontend.js scaffoldThis prints the ordered chain — /business-case → /capability → /requirement → /groom — grounded in a digest of your vision, with a reuse note on each step. Follow it in order.
3. Drive the PM chain
Run the skills in sequence, letting each one do its own authoring:
/business-case # justify the investment (skip for a narrow, obvious vision)
/capability # capabilities with user stories + a requirements checklist
/requirement # requirements with testable ACs, a priority label, Part-of links
/groom # reconcile the cluster, confirm readiness, mark ready reqs approvedThe one rule the gate enforces later: every requirement must come out of /groom with a priority label, testable acceptance criteria, and no unresolved blocked / needs-clarification collision.
4. Hand human-only blockers back as TODOs
When decomposition hits something only a human can do — a paid account, an API key, a domain registration, a design sign-off — file a TODO instead of guessing:
bash
node ~/.claude/scripts/warp-drive/pm-frontend.js emit-todo \
--title "register the production domain" \
--summary "Test-env promotion needs the domain registered and DNS delegated." \
--instructions "Register the domain;Delegate DNS to Cloudflare;Comment the zone ID here" \
--blocks 42 --priority p2-highThe todo is filed as todo,full-auto,<priority> assigned to paulirv, then validated against the TODO Format Contract. Preview without filing using --dry-run.
5. Gate the queue
bash
node ~/.claude/scripts/warp-drive/pm-frontend.js verify-queue --area <slug> --json- exit 0 — the queue is non-empty, consumable unchanged by warp-drive discovery, and every requirement is groom-ready. The runway is clear.
- exit 1 — read
failures[]and fix the offending requirements, then re-run. - exit 2 — a
gh/repo error, not a queue verdict.
6. Hand off to warp-drive
bash
/warp-drive --area <slug>Discovery picks up exactly the queue the gate just verified — the gate's oracle is discover-queue.sh, so there is no drift between "verified" and "consumed".
Doing it all at once
/autonomous-pm run --area <slug> walks these steps as one command; /autonomous-pm plan (or --dry-run) stops after the scaffold and authors nothing — the read-mostly pre-flight.
Related
- Autonomous PM Front-End reference
- Warp-Drive how-to — the loop that consumes the queue
- TODO Format Contract