dispatch

name	dispatch
description	Fan out a batch of independent, well-specified tasks (backlog items, issue numbers) to parallel worktree-isolated implementer subagents, each ending at a draft PR plus a critic review. For a single large feature, use the project's own /orchestrate instead (/orchestrate-creator scaffolds one).
argument-hint	[bullet-list of tasks | path/to/tasks.md | #123 #124 ...]
disable-model-invocation	true

/dispatch

Parallel fan-out for a batch of independent tasks in the current repository. This skill ends at draft PRs plus a review verdict per task; marking PRs ready, merging, and follow-up on later CI/review comments stay with the user.

Respond in the user's conversation language. Skip narration between tool calls.

Subagent budget (inlined so this skill is self-contained). Per-response output-token caps (Claude Code 2.1.228): Opus 5 · Sonnet 5 · Fable 5 64,000 / Haiku 4.5 32,000; pre-5 models vary either way (8,192 to 64,000). Model choice is a cost lever, not a budget lever — Sonnet buys no headroom over Opus. Keep each dispatched task within ~800 changed lines. For more depth read this kit's rules/subagent-usage.md (or ~/.claude/rules/subagent-usage.md if installed).

Pre-flight

1. git status — report a dirty worktree; dispatch itself never touches the user's current checkout (subagents work in their own worktrees).
2. Detect the base branch (origin/HEAD, fallback main).
3. Detect the verification command, in priority order — record what you find and include it verbatim in every delegation prompt:
   1. Commands documented in the repo's CLAUDE.md / AGENTS.md (build/test section)
   2. justfile → just test (+ lint/analyze recipes if present)
   3. Makefile → make test
   4. gradlew / build.gradle(.kts) → ./gradlew test
   5. Package.swift → swift test
   6. package.json scripts → npm test (or the repo's package manager)
   7. composer.json scripts → composer test / composer analyze
   8. Cargo.toml → cargo test
   9. pyproject.toml / pytest.ini → pytest
   10. *.sln / *.csproj → dotnet test If nothing is found, say so and ask the user for the command before dispatching.
4. Verification weight: judge whether the command is resource-heavy — device simulators/emulators, local LLM inference, large native builds, or anything the repo's CLAUDE.md flags as memory-hungry. Heavy verification caps concurrency, not batch size (see Workflow step 3).
5. gh auth status must pass (draft PRs are created via gh).
6. Ownership + PR-target check: if the origin owner is not the authenticated user's own account (gh api user) or an owner the user has already confirmed in this session, ask before dispatching — this skill pushes branches and creates PRs. Then run gh repo view --json isFork,parent,nameWithOwner: if the repo is a fork, gh pr create defaults to targeting the PARENT repo — confirm the intended PR target with the user. Record the resolved target as PR_REPO (owner/repo) and pass it explicitly via -R in every gh pr call, so a fork can never silently open PRs against someone else's upstream.

Workflow

1. Parse the argument into a task list:
   • Bullet list text → one task per bullet.
   • A file path → read it; one task per top-level bullet/heading.
   • #N issue numbers → gh issue view N on the current repo; the issue body is the task spec.
   • Empty → ask the user.
2. Independence check: if two tasks plausibly touch the same files, merge them into one task (same worktree) rather than risking conflicting PRs.
3. Build the dispatch plan — a table with one row per task: branch name (dispatch/<slug>, or the repo's documented branch convention), task summary, target files (best guess), model (per the global Plan & Delegate policy if installed; else: opus for hard logic, sonnet for well-specified work, haiku for mechanical edits), estimated size, and PR labels (issue-backed: carry the issue's labels; otherwise pick from gh label list — existing labels only, never create). Caps, stated in the plan:
   • Batch: max 5 tasks per dispatch (if more were given, propose the top 5 and hold the rest for a second round).
   • Concurrency: all at once by default; if pre-flight judged verification heavy, propose running in waves (default wave size 2) so parallel test runs don't exhaust memory. The user can override either cap at approval.
4. Plan critique (cheap, high ROI — catches rework before 5 worktrees exist): run ONE critic subagent on the dispatch plan itself. Its axes: task independence (hidden file overlaps, hidden dependencies between tasks), spec completeness of each delegation prompt, verification-command fitness, model assignments. Model by batch stakes (haiku/sonnet for routine batches, opus for risky ones). Fold its findings into the plan table. If the batch touches auth / payment / migrations / deploy paths, also offer the user a full /risk-review of the plan before dispatching — but don't run it unasked.
5. Gate — plan approval: show the table plus the critic's findings and stop. Dispatch nothing until the user approves. This is the single approval for the whole batch.
6. Mark issues in-progress (issue-backed tasks only, right after approval): gh issue edit <n> --add-assignee @me, and if the repo has an in-progress-style label (doing / in progress / wip — check gh label list), add it. Never create new labels.
7. Execute in parallel (within the approved wave size): launch one implementer subagent per task in the background, each with worktree isolation and the chosen model. Every delegation prompt must be self-contained: task spec, target paths, repo conventions pointer (CLAUDE.md), the verification command from pre-flight, branch name, and these standing orders:

Constraints

• Draft PRs only. Marking PRs ready / merge / comment reply are out of scope for this skill.
• GitHub metadata: assignee is always @me; use existing repo labels only — never create labels, never assign other users.
• Token guard: hard limits — 5 tasks per dispatch, one plan critic per dispatch, at most two critics per task diff (2 only when using both lenses, otherwise 1), one retry per failed task. Do not loop. If the batch needs more depth, tell the user to run /dispatch again.