next

/next (bro)

All mechanics live in the bro CLI. This skill is policy only. bro flow next computes the queue from bd ready, claims the top item atomically, and surfaces what it deliberately skipped.

Prereq: bro on PATH or npx -y @broject/bro@0, bd init done.

The loop

bro flow next          → claims the top ready bead, prints the work order
   implement      → branch, code, tests — verify like CI
   PR             → gh pr create (ready — /next owns the merge; drafts are for merge=human flows) → bro review act status → bro review act merge
   bd close <id>  → reason = the PR that landed it
   bro flow next       → repeat until "backlog empty"

If the backlog exists, it was already confirmed — never ask "should I continue?" between items. The queue is the approval.

What next never claims

• Human gates — beads titled HUMAN GATE … surface as gate: lines. Ask the user once per gate; their verdict is the result. Everything else proceeds without waiting on the gate.
• Epics — surface as epic: lines. Decompose into beads first (bd create children), don't implement an epic directly.
• Molecule steps — beads whose parent is a molecule belong to bro flow convoy; the flat queue doesn't steal them. Epic children carry a parent too but stay claimable — bro flow next checks the parent's type, not just the field.
• Foreign-scope beads — ids outside this checkout's issue_prefix are never claimed; they surface as foreign: N when the shared db carries other projects' work. scope = "all" in a plan opts out.
• Global beads — user-level beads live in a separate store (bro store init --global, bro task list --global). bro flow next --global runs the same pipeline against that store explicitly; project output never mixes them in.
• Coordination primitives — gt:slot-labeled beads (merge-queue semaphores) are excluded inside bd ready itself; a semaphore is never work.

Plans

bro plan run next.toml drives the same selection from a validated plan — limit (batch size), order (priority|oldest|newest), [filters] (types, max_priority, title match, labels — the declared scope: only beads carrying one of those labels are claimable, unlabeled and other-labeled work stays untouched), claim = false for a dry run, gates = "allow" to pre-authorize claiming HUMAN GATE beads, scope = "all" to lift project scoping, and scope = "global" (or bro flow next --global) to schedule from the user-level store. Batching is for parallel execution (one claimed bead per worktree/agent); a claimed gate still means a human decides — the plan was the go-ahead, not the verdict.

Policy

• One bead, one PR — unless several items are trivially the same change. Debt batches are the exception, not the rule.
• The gate decides done — bro review act status green before merge, bro review act merge to land it, branches deleted after.
• Stuck ≠ skipped — if an item can't proceed, say why (blocker, missing access, ambiguity), leave it open, and move to the next bead. Never silently drop it: bd update <id> --notes "<why>" records it.
• idle vs gated — state: idle means the backlog is truly empty: report and stop. state: gated means open items remain but none are claimable (gates/epics/mol steps) — report what's blocking and stop for the human, don't call it done. Don't manufacture work.