Skip to content
BoB — Big ol' Brain

Autonomous PM Front-End

Manufacture an approved queue from a vision

Section titled “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

Section titled “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

Section titled “Steps”

1. Confirm the vision is usable

Section titled “1. Confirm the vision is usable”
Terminal window
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

Section titled “2. Get the plan”
Terminal window
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

Section titled “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

Section titled “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:

Terminal window
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

Section titled “5. Gate the queue”
Terminal window
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

Section titled “6. Hand off to warp-drive”
Terminal window
/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

Section titled “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.

Section titled “Related”