pb-supervise-parallel-mission

pb-supervise-parallel-mission — N parallel workers, one result

Goal

You are the supervisor. Decompose the mission so no two children touch the same paths, spawn all workers in one batch, collect their reports WITHOUT ending your turn (inbox_wait), verify each result yourself, dispatch targeted fixes, then tear the fleet down and synthesize the single deliverable you owe.

Prerequisites (reference by name): ap-spawn-agent, ap-wait-fanin, ap-read-output, ap-tasks, ap-lifecycle. One worker only: see pb-new-agent-session. A parent that spawns its own children: see pb-nested-orchestrator.

Steps

1. Decompose into disjoint ownership

Split the mission so each child owns a disjoint set of files or topics. Two children writing the same paths means merge conflicts and blame loops. Write the ownership down BEFORE spawning — it goes verbatim into each brief.

2. Take the cursor FIRST

session_events_poll({})

Arm the watch before any child exists: events emitted before your first poll come back immediately with since, so a fast child can never slip past.

3. Spawn all N in ONE batch

Parallel agent_start calls in the same turn, distinct labels, each brief self-contained:

agent_start({
  adapter: 'hermes',
  model: 'z-ai/glm-5.3-flash',
  cwd: '<ABSOLUTE host path>',
  label: 'worker-files',
  access: { profileRef: 'openrouter-env' },
  mcpServers: [{ name: 'agentproto', transport: 'http', ref: 'http://127.0.0.1:18790/mcp' }],
  prompt: '<child brief - see template below>'
})

claude-code children drop mcpServers (native tools are built in). Keep every returned session id paired with its label.

4. Fan-in on the children's messages — never end your turn to wait

Each child reports with message_parent (see the brief template). Stay in your turn and loop:

inbox_wait({ from: 'children', kind: ['done', 'blocker'], timeoutMs: 45000 })

It returns as soon as a child reports — the message comes back as the tool result (daemon-attested sender in from), never as a later prompt. Handle each message (answer a blocker with message_reply({ replyTo: <msg id>, text })), then call it again. Stop when every child has sent done, or when pendingChildren in the result is empty (no child still working). timedOut: true just means "nothing yet" — loop again.