plan-issueslisted

# /plan-issues — Wave assignment before parallel work loops **Type:** planning / execution-order analysis ## Purpose Before running multiple `/work-issue` loops in parallel, `plan-issues` partitions the open issues into **waves**: groups of issues that can safely run concurrently without file-level collisions, dependency violations, or migration-number clashes. **Waves answer "what can run NOW?" — priority answers "what matters most?"** Both are needed; they solve different problems. Waves are the execution-safety unit; priority is the importance ranking within a wave. ### Pipeline position ``` create-issue → plan-issues → [human review] → work-issue (wave 1) → work-issue (wave 2) → ... ``` ## Invocation variants ``` /plan-issues --repo owner/slug /plan-issues --repo owner/slug --milestone "v2.0" /plan-issues --repo owner/slug --label "sprint-current" /plan-issues # → resolves repo from cwd, uses all open issues ``` **Filters (optional):** `--milestone`, `--label`, `--issue <num>[,<num>...]` narrow the issue set. Without filters, all open issues are planned. ## Workflow ### 1. Issue fetch ```bash gh issue list --repo <slug> --state open --json number,title,labels,body,assignees --limit 100 ``` Apply any milestone/label/number filters. The result is the **candidate set** — the issues to be planned. ### 2. Loop-type classification For each issue, determine loop type from the `loop-type:<type>` label (set by `/create-issue`): - `loop-type: