Skip to content

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-vision fails closed on a thin or missing doc.
  • The /business-case, /capability, /requirement, and /groom skills provisioned (they are universal PM commands).
  • gh authenticated for the repo.

Steps

1. Confirm the vision is usable

bash
node ~/.claude/scripts/warp-drive/pm-frontend.js check-vision --json

ok: 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 scaffold

This 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 approved

The 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-high

The 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.