Dispatch Implementation

Step 8 helper for plans with ≥ 2 steps marked Parallel-friendly: yes. Dispatches one forge-implementer subagent per qualifying step, each in isolation: "worktree". Once a step is assigned to a parallel implementer, this skill (and the forge-implementer subagent) refers to it as the implementer's "work unit". Worktree isolation is the safety net: implementers cannot see or stomp on each other's edits, the orchestrator gets per-unit branches/diffs, and the user's main worktree stays clean until merge.

If the plan has fewer than 2 parallel-friendly steps, do NOT use this skill. Implement in the main session — the parallelism does not pay for itself once you account for orchestrator-side dispatch + merge overhead. The forge skill's "After approval" section spells out the routing.

Required Inputs

• The approved revised master plan in conversation context (from /forge:plan-revise, with user approval at Step 7).
• The list of Parallel-friendly: yes steps from the plan. If invoked with all (default), dispatch every qualifying step in parallel; if invoked with a specific W-ID (e.g. 2 for W2), dispatch only that one (used for re-runs of a failed step).

Pre-dispatch — TaskCreate per work unit

Before the parallel Agent calls, MUST invoke TaskCreate once per work unit being dispatched. Pair content + activeForm per the workflow standard:

TaskCreate(
  content: "Implement step W<N>: <step title>",
  activeForm: "Implementing step W<N>: <step title>"
)

The task list is what the user reads while the parallel implementers run. One row per work unit, in W-ID order.

After all TaskCreate calls land, mark every work-unit task in_progress via TaskUpdate in a single tool-use block, then fire all Agent calls in the next single tool-use block. Do NOT interleave per-unit TaskUpdate calls with Agent calls — every task must be in_progress before any implementer dispatches.

Dispatch Template

For each qualifying step being dispatched, MUST invoke Agent in a single tool-use block (parallel execution):

Agent(
  description: "Implement step W<N>: <step title>",
  subagent_type: "forge-implementer",
  model: "sonnet",         # mirrors forge-implementer.md frontmatter; explicit so the dispatch is self-documenting
  run_in_background: false,
  isolation: "worktree",
  prompt: """
## Your work unit (plan step W<N>)
<full step block from the plan: title, files touched, description (with inline contract-clause references like "fulfills C1, C3"), done-when criterion, Parallel-friendly: yes annotation>

## Integration contract (your unit fulfills only the clauses cited in your description, but you MUST not violate other clauses)
<full integration contract appendix from the plan — appears only when ≥ 2 disjoint steps exist, which is the precondition for this skill running>
"""
)

The forge-implementer agent's system prompt (in forge/agents/forge-implementer.md) carries the full constraints — files-touched discipline, contract honoring, citation discipline, blocker escalation, single-commit rule, return format. The dispatch prompt only inlines the per-step content.

The turn budget is set exclusively by the agent's maxTurns: frontmatter (currently 60). The Agent tool does NOT accept max_turns or name at the call site — both are silently dropped by the harness — so do not pass them here. To change the per-implementer budget, edit the agent's frontmatter.

Keep the agent ID from each dispatch result. Blocker resolution resumes implementers by ID via SendMessage (see "Handling implementer reports").

Critical Constraints

• `isolation: "worktree"` on every dispatch. Without it, parallel implementers race on the same files. The worktree gives each its own filesystem view + branch.
• `subagent_type: "forge-implementer"` on every dispatch.
• All dispatches in one tool-use block. Sequential dispatch defeats the parallelism the worktree isolation enables.
• `TaskCreate` before `Agent`. The user reads the task list while implementers run; one row per work unit.
• NEVER instruct implementers to call `AskUserQuestion`. Subagents cannot reliably use it (background mode fails silently). Implementers escalate blockers in their report; the orchestrator handles user interaction.
• NEVER tell implementers to merge their worktrees. The orchestrator merges after aggregation, in /forge:build-and-report.

Handling implementer reports

When implementers return:

• Hard blockers (non-empty Blockers section) — STOP. The orchestrator decides between resume-with-decision, revise-plan-and-redispatch, reassign-unit, or accept-with-evidence. Do not proceed to merge with an unresolved hard blocker. MUST invoke TaskUpdate to keep the task in_progress (with an updated activeForm describing the blocker) until resolved.
• Resume-first. When the blocker needs only a ruling the orchestrator (or the user at the approval gate) can give — a contract-clause interpretation, a plan-vs-reality drift the plan author can rule on, an expanded "Files touched" set — and the work unit itself is unchanged, MUST invoke SendMessage to that implementer's agent ID with the decision. The implementer resumes in its existing worktree with its read context intact, which is far cheaper than a fresh dispatch that re-reads everything.
• Fresh dispatch only when the work unit changes. If resolving the blocker re-slices the plan (new step boundaries, reassigned files), revise the plan first and re-dispatch that unit fresh — stale context misleads once the assignment itself has changed.
• If SendMessage is unavailable in this session (older Claude Code builds), fall back to revise-plan-and-redispatch.
• Done-when criterion: no / partial-because — same treatment as a hard blocker.
• All units returned clean — MUST invoke TaskUpdate to mark each work-unit task completed. Then proceed to /forge:build-and-report.

Next Step

After all implementers return clean, invoke /forge:build-and-report to merge worktrees, run the project's build, and emit the final report.