From f1d24892ab1fab469ad26cab5a82b66418fb54b3 Mon Sep 17 00:00:00 2001 From: Baker B Date: Mon, 4 May 2026 05:15:53 -0400 Subject: [PATCH] chore(skills): parallel sub-agent batch patterns for /issue and /prepwaves MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - /issue: adds Batch Creation section (N>1 issues) — parallel Sonnet sub-agents launched in a single message; Sonnet preserved for issue body quality; partial failure handled per-row not abort - /prepwaves: Step 2b rewritten to parallelize spec_validate_structure calls with Haiku sub-agents; epic_sub_issues stays inline as it must complete before validators can spawn Continuation of skill optimization pass started in #571. Closes #573 --- skills/issue/SKILL.md | 48 +++++++++++++++++++++++++++++++++++++++ skills/prepwaves/SKILL.md | 14 +++++++++++- 2 files changed, 61 insertions(+), 1 deletion(-) diff --git a/skills/issue/SKILL.md b/skills/issue/SKILL.md index b23f409..e45958e 100644 --- a/skills/issue/SKILL.md +++ b/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 issue in repo using the /issue skill. + +Type: +Repo: +Epic flag: <--epic N, or omit> + +Intent: + + +Label hints (override sub-agent judgment if supplied): +- priority: +- urgency: +- size: +- wave: + +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: diff --git a/skills/prepwaves/SKILL.md b/skills/prepwaves/SKILL.md index 4051f14..84f3085 100644 --- a/skills/prepwaves/SKILL.md +++ b/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 | | <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`.