/stdd:batch — fan out independent slices to parallel subagents

/stdd:batch — fan out independent slices to parallel subagents

Args: $ARGUMENTS

This packages the batch fan-out that would otherwise be a hand-written orchestration instruction: spawn one isolation: worktree subagent per Independent? yes slice, each running the stdd loop in its own gated worktree, then collect the results. It is the unattended counterpart to a session per worktree: you trade watching each RED for running many slices at once. Reach for it only for independent slices that are already well understood; when you want eyes on each RED, use /stdd:worktree <slice> and a session instead.

Parse the arguments

• --impl (if present): implementation-only mode. Each subagent runs /stdd:tdd <slice> → /stdd:review <slice> and assumes the spec (and its committed red-team stamp) already exist. Without it: whole-loop mode, where each subagent authors and red-teams its own spec first.
• Remaining tokens (after removing --impl): an explicit set of slices to run. If none are given, the set is every Independent? yes slice.

Resolve the slice set

1. If explicit slices were named, validate each is safe to parallelize:

   bash "${CLAUDE_PLUGIN_ROOT}/scripts/worktree.sh" check <slice>
   

   Drop (and report) any that exit non-zero. A slice not marked Independent? yes must run serially in the primary tree, not here.

2. Otherwise, enumerate the whole independent set:

   bash "${CLAUDE_PLUGIN_ROOT}/scripts/worktree.sh" list
   

   If it exits non-zero, it printed why (no roadmap, or nothing marked Independent? yes). Stop and relay that: there is nothing to fan out.

3. Show the user the resolved set and the mode before spawning: e.g. Fanning out 3 slices (whole loop): billing/invoice, reports/export, notify/email. These run concurrently, and each runs a full test suite, so a large set is genuinely heavy. If it exceeds a handful, say so and let the user narrow it.

Fan out — one subagent per slice

Spawn one subagent (Task tool) per slice with isolation: worktree, all in one batch so they run in parallel. Each subagent already has its own worktree from the harness, so it must not call /stdd:worktree (no nesting). The PreToolUse guard, the pre-commit gate, and the coverage audit all resolve to the subagent's own worktree, so every subagent is gated against its own tree.

Brief for whole-loop mode (no --impl):

You are implementing the single slice <slice> end to end in your worktree. Run the stdd loop: /stdd:spec <slice> → /stdd:review <slice> --spec → /stdd:tdd <slice> → /stdd:review <slice>. Author the spec from its docs/roadmap.md entry, red-team it, then implement it one criterion at a time to GREEN. Commit your work. If a [NEEDS CLARIFICATION] marker or a design question blocks you and you cannot resolve it from the roadmap, stop and report it rather than guessing. Return JSON: { slice, mode:"whole", ac_coverage, tests:"pass|fail", blocked?, note }.

Brief for implementation-only mode (--impl):

The spec docs/specs/<slice>.md and its committed red-team stamp already exist; do not author or edit the spec. Run /stdd:tdd <slice> → /stdd:review <slice>, implementing each acceptance criterion test-first to GREEN, and commit your work. If the red-team gate blocks (a missing or stale stamp, or an unresolved [NEEDS CLARIFICATION] marker), stop and report: fixing the spec is out of scope for this mode. Return JSON: { slice, mode:"impl", ac_coverage, tests:"pass|fail", blocked?, note }.

Report

Print one consolidated table: slice · mode · AC coverage · tests (pass/fail) · blocked?/note. End with a one-line tally, e.g. 3/3 slices green or 2 green, 1 blocked (notify/email: unresolved [NEEDS CLARIFICATION]).

Then tell the user how to land the work: review and merge each subagent's branch (this command does not merge for you), and run /stdd:review tree-wide in the primary afterward to catch any AC-tick drift the merges introduced.