Batch Issues into Waves

Decide which Issues can ship side by side, and in what order.

Input

A scope ($ARGUMENTS): milestone:<name>, label:<name>, epic:<number>, or Issue numbers. Optional: -- <additional context> such as a wave size cap or Issues to pin together. --unattended skips the approval step. --start also starts the ready Issues and reports the scope's status; without it, nothing starts.

Process

Step 1: Collect Candidates

List the scope's Issues with List Issues by Scope in issue-operations, keeping only number, title, labels, execution mode, and dependency references — bodies are read later, per Issue. Then fetch open PRs once and match each Issue locally, following Open PRs in open-work.

Exclude, with a stated reason each: HITL Issues, Issues labeled blocked, Issues with an open PR, and Issues with a prerequisite outside the scope that is unmet per Prerequisites in open-work (one query for all of them). Everything left is AFK and free to start. With --start, classify every Issue instead, following Classify in start.

Step 2: Estimate Touch Sets (delegate)

For each candidate, produce its touch set — the files and directories the implementation will most likely change. When the scope has more than five Issues, delegate to forge-scout sub-agents in parallel on a cheap fast model, about five Issues per scout so shared greps run once; otherwise estimate inline. Unlike implement's blind research, the scout receives the Issues here — the touch set is about them.