chore(skills): parallel sub-agent batch patterns for /issue and /prepwaves

skills/issue/SKILL.md

@@ -567,6 +567,54 @@ Create immediately — do not ask for approval. Issues are cheap to edit and clo
 If `work_item` reports a missing label at create-time (race or pre-existing
 `epic::X` for a different `X`), surface the error; do not silently retry.
 
+## Batch Creation (N > 1 issues in one pass)
+
+When a calling agent (e.g. `/devspec`, `/prepwaves`) needs to create multiple
+issues in a single pass, spawn them as **parallel sub-agents** rather than
+looping serially. This keeps the issue-drafting work out of the main context
+window and collapses wall-clock time to the slowest single issue.
+
+**When to use:** any time the caller has ≥ 2 issues to create in the same
+invocation and the issues have no creation-time dependencies on each other
+(i.e. no issue needs the number of another issue before it can be created).
+
+**When NOT to use:** if issue B needs the number of issue A to embed in its
+body (e.g. a Plan issue that references sub-issues by number). Create A first,
+then batch the rest.
+
+**Sub-agent template** (one per issue, all launched in a single message):
+
+```
+subagent_type: general-purpose
+model: sonnet
+prompt: "Create a <type> issue in repo <owner/repo> using the /issue skill.
+
+Type: <feature|bug|chore|doc|story|plan|epic>
+Repo: <owner/repo>
+Epic flag: <--epic N, or omit>
+
+Intent:
+<Full description of what this issue should cover. Be specific enough that
+the sub-agent can fill out all six required H2 sections (Summary, Implementation
+Steps, Test Procedures, Acceptance Criteria, Dependencies, Metadata) without
+making design decisions. This is the same quality bar as a human /issue prompt.>
+
+Label hints (override sub-agent judgment if supplied):
+- priority: <critical|high|medium|low, or omit to let sub-agent infer>
+- urgency: <immediate|soon|normal|eventual, or omit>
+- size: <S|M|L|XL, or omit>
+- wave: <N, or omit>
+
+Return: issue number and URL only. No other output."
+```
+
+**Model:** `sonnet` — issue body quality is load-bearing (Flight Agents execute
+directly from it). Do not downgrade to Haiku.
+
+**Collecting results:** each sub-agent returns `{number, url}`. Assemble these
+into the batch report table in Step 5. If any sub-agent fails, report the
+failure inline in the table row rather than aborting the whole batch.
+
 ## Step 5: Report
 
 Confirm creation with the issue number, URL, and a nudge to review:

skills/prepwaves/SKILL.md

@@ -19,7 +19,19 @@ Analyze one or more Plan tracking issues, validate their sub-issue specs, comput
 ## Procedure
 
 1. **Inputs.** Plan tracking-issue numbers passed by the user (`/prepwaves #2` or `/prepwaves #2 #3 ...`). Each Plan becomes one Phase in `phases-waves.json`.
-2. **Pre-flight readiness table.** For each Plan: call `epic_sub_issues(N)` (tool name is a historical identifier — the call enumerates the Plan's sub-issues); for each child call `spec_validate_structure(N)`. Present a table (Issue | Title | Deps | Changes | Tests | AC | Ready?). If any sub-issue is not ready, stop and ask the user how to proceed.
+2. **Pre-flight readiness table.** For each Plan:
+   a. Call `epic_sub_issues(N)` inline to get the list of sub-issue numbers (must complete before spawning validators — you need the list first).
+   b. Launch **one Haiku sub-agent per sub-issue in a single message** (parallel). Each sub-agent runs `spec_validate_structure` for its issue and returns a one-line result: `#N | <title> | <deps> | Changes:✓/✗ | Tests:✓/✗ | AC:✓/✗ | <Ready/NOT READY>`. Sub-agents have no data dependencies on each other — all can run concurrently.
+
+   Sub-agent template (one per sub-issue, all launched in a single message):
+   ```
+   subagent_type: general-purpose
+   model: haiku
+   prompt: "Call mcp__sdlc-server__spec_validate_structure for issue #<N> in repo <owner/repo>.
+            Return a single line: #<N> | <title> | deps:<dep_list or none> | Changes:<✓ or ✗> | Tests:<✓ or ✗> | AC:<✓ or ✗> | <Ready or NOT READY: list missing sections>"
+   ```
+
+   Assemble the returned lines into the readiness table. If any sub-issue is NOT READY, stop and ask the user how to proceed.
 3. **Compute waves.** Call `wave_compute(epic_ref)` (param name is historical — pass the Plan's issue ref) to get the topologically-sorted wave plan, then `wave_topology(...)` to classify. Present the wave plan (waves, issues, dependency chain, branch naming `feature/<N>-<desc>`).
 4. **Cross-repo detection.** For each Phase about to be persisted, walk every sub-issue's ref. Resolve each ref's `owner/repo` (per-issue `repo` field, else plan-level `repo`, else the orchestrator's current project repo). Collect distinct repo slugs that differ from the orchestrator's project repo. If the set is non-empty, set `cross_repo: true` and `target_repos: [<slug>, ...]` on that Phase in the plan JSON. Single-repo Phases leave both fields unset. Cheap — no extra LLM calls; pure walk over refs already in `wave_compute`'s output.
 5. **Approval gate.** Wait for explicit user approval. Iterate on the plan here — not during `/nextwave`.