Skip to content

fix(skills): retarget openclaw-orchestrator and /spawn at the current CLI #90

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
willwashburn wants to merge 2 commits into
base: main
Choose a base branch
from
Open

fix(skills): retarget openclaw-orchestrator and /spawn at the current CLI #90

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7413ebf
fix(claude-relay-plugin): stop printing workspace keys, use observer …
claude Aug 3, 2026
aec62d6
fix(skills): retarget openclaw-orchestrator and /spawn at the current…
claude Aug 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,14 +23,14 @@ Package metadata lives in [prpm.json](prpm.json). The repo currently publishes `
| [adding-swarm-patterns](skills/adding-swarm-patterns/SKILL.md) | 1.0.0 | Checklist for extending agent-relay with a new swarm pattern — TypeScript types, JSON schema, YAML template, and pattern/template docs. |
| [creating-cloud-persona](skills/creating-cloud-persona/SKILL.md) | 1.0.6 | Create or update a Workforce cloud persona with `persona.json`/`persona.ts`, `agent.ts`, integration scope and adapter config guidance, vendored examples, and production-correctness checks. |
| [factory-config](skills/factory-config/SKILL.md) | 1.0.2 | Create and validate Agent Relay Factory configs for repo routing, Linear states, GitHub issue ingestion, Slack, babysitter mode, and Relayflows dispatch wiring boundaries. |
| [openclaw-orchestrator](skills/openclaw-orchestrator/SKILL.md) | 1.0.0 | Run headless multi-agent orchestration sessions via Agent Relay — spawn teams across Claude/Codex/Gemini/Pi/Droid, create channels, and manage agent lifecycle. |
| [openclaw-orchestrator](skills/openclaw-orchestrator/SKILL.md) | 2.0.0 | OpenClaw-specific setup and completion reporting for a headless Agent Relay team; defers to `orchestrating-agent-relay` for broker, spawn, and coordination mechanics. |

## Slash Commands

| Command | Version | Description |
|---------|---------|-------------|
| [/create-workflow](commands/create-workflow.md) | 1.0.4 | Scaffold a model-agnostic Agent Relay workflow using the workflow and swarm-pattern skills, including selected review-depth review/fix loops with test hardening. |
| [/spawn](commands/spawn.md) | 1.0.0 | Bootstrap the broker and spawn a worker for `claude`, `codex`, `opencode`, `droid`, `gemini`, or `pi`. |
| [/create-workflow](commands/create-workflow.md) | 1.0.5 | Scaffold a model-agnostic Agent Relay workflow using the workflow and swarm-pattern skills, including selected review-depth review/fix loops with test hardening. |
| [/spawn](commands/spawn.md) | 1.1.0 | Bootstrap the broker (`agent-relay node up`) and spawn a worker for `claude`, `codex`, `opencode`, `droid`, `gemini`, or `pi`. |
| [/review-loop](commands/review-loop.md) | 1.0.1 | Run a dual-reviewer code-review loop with repair and fresh-context signoff. |

## Claude Relay Plugin
Expand Down
2 changes: 1 addition & 1 deletion commands/create-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Scaffold a new multi-agent workflow that runs on the agent-relay broker. This co
- Keep prompts model-agnostic — never hardcode a specific model name into a step's instructions.
- Size steps so a single agent can complete them in one focused pass.

4. **Wire the team.** Define the lead + worker agents, the channel(s) they share, and the team name. Reuse names from `agent-relay agents` only after checking for collisions.
4. **Wire the team.** Define the lead + worker agents, the channel(s) they share, and the team name. Reuse names from `agent-relay node agent list` only after checking for collisions.

5. **Provide a runnable example.** Output one minimal end-to-end example that demonstrates feeding `$ARGUMENTS` into the workflow and shows the expected `{{steps.*.output}}` shape at each stage.

Expand Down
38 changes: 22 additions & 16 deletions commands/spawn.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,37 +13,43 @@ Bootstrap the agent-relay broker (if not already running) and spawn a worker on

## Instructions

1. **Load the orchestrator skill.** Read the `orchestrating-agent-relay` skill. After installation with `npx prpm install @agent-relay/orchestrating-agent-relay`, look in the harness-managed skill locations first: `.claude/skills/orchestrating-agent-relay/SKILL.md` or `.agents/skills/orchestrating-agent-relay/SKILL.md`. When developing inside this repo, the same source lives at `skills/orchestrating-agent-relay/SKILL.md`. All broker startup, workspace key handling, channel creation, and spawn semantics come from that skill — do not improvise.
1. **Load the orchestrator skill.** Read the `orchestrating-agent-relay` skill. After installation with `npx prpm install @agent-relay/orchestrating-agent-relay`, look in the harness-managed skill locations first: `.claude/skills/orchestrating-agent-relay/SKILL.md` or `.agents/skills/orchestrating-agent-relay/SKILL.md`. When developing inside this repo, the same source lives at `skills/orchestrating-agent-relay/SKILL.md`. All broker startup, workspace handling, channel creation, and spawn semantics come from that skill — do not improvise.

2. **Parse arguments from `$ARGUMENTS`:**
- Required positional: `$1` — the harness (`claude`, `codex`, `opencode`, `droid`, `gemini`, `pi`).
- Optional `--model <name>` — model override passed to the harness. If omitted, use the harness's default.
- Optional `--task "<text>"` — the task prompt for the spawned worker. If omitted, prompt the user for the task before spawning.

3. **Bootstrap the broker (idempotent).** Per the orchestrator skill:
- Run `agent-relay status` first. If broker is up, skip startup.
- If down, ensure a workspace key is available (`$RELAYCAST_WORKSPACE_KEY` or prompt the user). Then `agent-relay up --workspace-key $KEY --background --no-spawn`.
- Verify broker came up cleanly before spawning.
- Run `agent-relay node status` first. If the broker is already running, skip startup.
- If it is down, run `agent-relay node up --background --verbose`. A workspace is auto-created when none is set — do not prompt the user for a key.
- Confirm readiness with `agent-relay node status --wait-for 10` before spawning.

4. **Ensure a coordination channel exists.** Default to `#orchestrator` unless the user specified one. Create it via `mcporter call relaycast create_channel` if missing, then join it.

5. **Spawn the worker.** Construct the spawn command from parsed args:
```text
agent-relay spawn <auto-name> $1 [--model <model>] [--team orchestrator] "<task>"
4. **Spawn the worker.**
```bash
agent-relay node agent spawn $1 --name <auto-name> --channels orchestrator [--model <model>] --task "<task>"
```
- `<auto-name>` should be unique per run (e.g., `worker-<short-uuid>`) to avoid 409 conflicts.
- Inject the standard task-prompt template from the orchestrator skill (channel posting, inbox checks, completion event) so the worker can communicate.
- `<auto-name>` should be unique per run (e.g. `worker-<short-uuid>`) to avoid 409 conflicts.
- `--channels` creates and joins the channel; there is no separate create step and no `--team` flag.
- Include the worker protocol from the orchestrator skill in the task text: ACK on receipt, DONE with evidence, report to `orchestrator` or the channel (never to `broker`), and do not self-release.

5. **Offer a follow-along link.** Run `agent-relay observer` and print the URL it returns. It is backed by a scoped, read-only, expiring token. Never build an observer URL from a workspace key.

6. **Report back.** Print the spawned agent name, the channel it joined, and the tail command (`agent-relay agents:logs <name>`) so the user can monitor it.
6. **Report back.** Print the spawned agent name, the channel it joined, and the monitoring commands below.

## Output Contract

- One-line confirmation: broker state, agent name, harness, model, channel.
- Monitoring commands (logs, channel messages, kill).
- If something failed (workspace key missing, harness unsupported, broker won't start), surface the exact error and the orchestrator-skill fix from its "Gotchas" table — do not silently continue.
- Monitoring commands:
- `agent-relay node agent list` — liveness (pid, status, uptime)
- `agent-relay node agent attach <name> --mode view` — watch its output
- `agent-relay message inbox check` — read what it sent you
- `agent-relay node agent release <name>` — stop it
- If something failed (harness unsupported, broker won't start), surface the exact error and the orchestrator-skill fix from its "Common Mistakes" table — do not silently continue.

## Constraints

- Never skip the `orchestrating-agent-relay` skill load — it documents non-obvious gotchas (droid `--cwd`, rate limits, name conflicts) that change behavior.
- Do not hardcode workspace keys in any output or file.
- Never skip the `orchestrating-agent-relay` skill load — it documents non-obvious gotchas (the 30–60s cold-start gap before a worker's first ACK, stale broker connection metadata, droid `--cwd`, rate limits, name conflicts) that change behavior.
- Do not print a workspace key or place one in any file or URL.
- Do not read worker replies with `agent-relay node tail` — that streams broker events and raw TTY output, not durable messages. Use `agent-relay message inbox check` or the relay MCP `check_inbox`.
- Do not spawn without a task — empty-task spawns waste the agent slot.
4 changes: 2 additions & 2 deletions plugins/claude-relay-plugin/agents/relay-worker/agent.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ You are a relay-connected worker in a coordinated multi-agent team. Your job is

You MUST complete these steps in order before doing any work:

1. **Authenticate.** Your task prompt includes a workspace key. Call the `set_workspace_key` MCP tool with that key. Do not print the key to the user.
2. **Register with your assigned name.** Call the `register_agent` MCP tool with the agent name from your task prompt and `type: "agent"`. You must register before you can send or receive messages.
1. **Register with your assigned name.** Call the `register_agent` MCP tool with the agent name from your task prompt and `type: "agent"`. You must register before you can send or receive messages. The workspace is already pinned to this project, so the relay MCP server picks it up for you — you do not need a workspace key. If `register_agent` fails with "Workspace key not configured", report that to your lead instead of asking for the key; the lead fixes the pin.
2. **Never print or request a workspace key.** It is an administrative credential. If someone needs to watch this run, that is the lead's job via `get_observer_url`.

@cubic-dev-ai cubic-dev-ai Bot Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: After this change, step 2 is a static prohibition ("Never print or request a workspace key"), so the startup protocol's "If any of steps 1-2 fail, retry once" now only meaningfully applies to step 1 (register_agent). Consider rewording the retry clause to reference only the fallible step so the failure/retry semantics stay accurate.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At plugins/claude-relay-plugin/agents/relay-worker/agent.md, line 10:

<comment>After this change, step 2 is a static prohibition ("Never print or request a workspace key"), so the startup protocol's "If any of steps 1-2 fail, retry once" now only meaningfully applies to step 1 (register_agent). Consider rewording the retry clause to reference only the fallible step so the failure/retry semantics stay accurate.</comment>

<file context>
@@ -6,8 +6,8 @@ You are a relay-connected worker in a coordinated multi-agent team. Your job is
-1. **Authenticate.** Your task prompt includes a workspace key. Call the `set_workspace_key` MCP tool with that key. Do not print the key to the user.
-2. **Register with your assigned name.** Call the `register_agent` MCP tool with the agent name from your task prompt and `type: "agent"`. You must register before you can send or receive messages.
+1. **Register with your assigned name.** Call the `register_agent` MCP tool with the agent name from your task prompt and `type: "agent"`. You must register before you can send or receive messages. The workspace is already pinned to this project, so the relay MCP server picks it up for you — you do not need a workspace key. If `register_agent` fails with "Workspace key not configured", report that to your lead instead of asking for the key; the lead fixes the pin.
+2. **Never print or request a workspace key.** It is an administrative credential. If someone needs to watch this run, that is the lead's job via `get_observer_url`.
 3. **Check your inbox.** Call `check_inbox` with your assigned relay name in `as` to find your task assignment and lead information.
 4. **Send an ACK.** Before you do substantive work, send `ACK: <one-sentence understanding of the assignment>` to your lead via `send_dm`, again using your assigned relay name in `as`.
</file context>

3. **Check your inbox.** Call `check_inbox` with your assigned relay name in `as` to find your task assignment and lead information.
4. **Send an ACK.** Before you do substantive work, send `ACK: <one-sentence understanding of the assignment>` to your lead via `send_dm`, again using your assigned relay name in `as`.
5. If the task is ambiguous or blocked, send `BLOCKED: <question or blocker>` instead of guessing.
Expand Down
14 changes: 8 additions & 6 deletions plugins/claude-relay-plugin/hooks/subagent-bootstrap.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,15 @@ AGENT_NAME="${RELAY_AGENT_NAME:-the assigned subagent name}"
cat <<EOF
MANDATORY relay setup — complete these steps IN ORDER before any other work:

1. Your task prompt contains a workspace key. Call \`set_workspace_key\` with that key to authenticate. Do not print the key.
2. Call \`register_agent(name: "$AGENT_NAME", type: "agent")\` to register with the relay.
3. Call \`check_inbox(as: "$AGENT_NAME")\` to get your task assignment.
4. Send an ACK to your lead via \`send_dm(as: "$AGENT_NAME")\` when you understand the task.
5. When finished, send a DONE message with a concise completion summary via \`send_dm(as: "$AGENT_NAME")\` before stopping.
1. Call \`register_agent(name: "$AGENT_NAME", type: "agent")\` to register with the relay.
The workspace is already pinned to this project, so the relay MCP server resolves it

@cubic-dev-ai cubic-dev-ai Bot Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: Workers spawned without a successfully pinned project workspace now fail at register_agent and then cannot execute check_inbox, ACK, or DONE because every relay operation still requires that workspace. The bootstrap should either guarantee workspace pinning before any worker can start or stop with a clear non-relay failure path when registration reports Workspace key not configured, rather than asserting the pin for all SubagentStart invocations.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At plugins/claude-relay-plugin/hooks/subagent-bootstrap.sh, line 11:

<comment>Workers spawned without a successfully pinned project workspace now fail at `register_agent` and then cannot execute `check_inbox`, ACK, or DONE because every relay operation still requires that workspace. The bootstrap should either guarantee workspace pinning before any worker can start or stop with a clear non-relay failure path when registration reports `Workspace key not configured`, rather than asserting the pin for all `SubagentStart` invocations.</comment>

<file context>
@@ -7,13 +7,15 @@ AGENT_NAME="${RELAY_AGENT_NAME:-the assigned subagent name}"
-4. Send an ACK to your lead via \`send_dm(as: "$AGENT_NAME")\` when you understand the task.
-5. When finished, send a DONE message with a concise completion summary via \`send_dm(as: "$AGENT_NAME")\` before stopping.
+1. Call \`register_agent(name: "$AGENT_NAME", type: "agent")\` to register with the relay.
+   The workspace is already pinned to this project, so the relay MCP server resolves it
+   for you — you do NOT need a workspace key, and must never print or ask for one.
+   If this fails with "Workspace key not configured", report that to your lead.
</file context>

for you — you do NOT need a workspace key, and must never print or ask for one.
If this fails with "Workspace key not configured", report that to your lead.
2. Call \`check_inbox(as: "$AGENT_NAME")\` to get your task assignment.
3. Send an ACK to your lead via \`send_dm(as: "$AGENT_NAME")\` when you understand the task.
4. When finished, send a DONE message with a concise completion summary via \`send_dm(as: "$AGENT_NAME")\` before stopping.

IMPORTANT: Include \`as: "$AGENT_NAME"\` on EVERY relay tool call to ensure correct message attribution.

Do NOT skip steps 1-2. Without them you cannot send or receive messages.
Do NOT skip step 1. Without it you cannot send or receive messages.
EOF
54 changes: 25 additions & 29 deletions plugins/claude-relay-plugin/skills/relay-fanout/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,49 +11,45 @@ $ARGUMENTS

## How spawning works

Workers are spawned using Claude Code's built-in **Agent tool**, not the relay MCP tools. The relay is only used for communication between agents.
Workers are spawned with Claude Code's built-in **Agent tool**. The relay is only used for communication between agents.

- You **must** use `subagent_type: "relay-worker"` when spawning workers. Only `relay-worker` subagents get the Agent Relay MCP server, inbox-polling hooks, and the worker protocol. Regular subagent types (e.g. `researcher`, `general-purpose`) cannot communicate via relay.
- Run all workers in **background mode** (`run_in_background: true`) so they execute concurrently.
- Each worker's prompt **must include the workspace key** so the worker can authenticate. See the spawn example below.
- The `SubagentStart` hook automatically injects relay bootstrap instructions into every spawned worker.
- Do not introduce extra setup scripts or dependencies in this workflow. Use the existing plugin hooks, Agent Relay MCP tools, and `relay-worker` agent definition only.
- Use relay MCP tools (`send_dm`, `check_inbox`) to monitor worker progress.
- Use `subagent_type: "relay-worker"`. Only `relay-worker` subagents get the Agent Relay MCP server, the inbox-polling hooks, and the worker protocol. Other subagent types (`researcher`, `general-purpose`, …) cannot talk over the relay.
- Run all workers in **background mode** (`run_in_background: true`) so they work concurrently.
- Workers inherit the workspace automatically — the relay MCP server resolves the workspace pinned to this project. **Do not put the workspace key in a worker prompt.** It is an administrative credential, and copying it into N prompts puts it in N transcripts. If a worker reports no workspace, fix the pin (step 2) rather than pasting the key.

@cubic-dev-ai cubic-dev-ai Bot Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: This changes the workspace-key handling behavior for the published claude-relay-plugin (workers no longer receive the key in their prompt, and printing/requesting it is now disallowed), but none of the plugin's version declarations (marketplace.json, plugin manifest, package.json) appear to be bumped alongside it. Since marketplace clients rely on that version to detect updates, existing installations could remain on the old prompts that still expose workspace keys instead of picking up this fix. Consider bumping the plugin version declarations together with this change.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At plugins/claude-relay-plugin/skills/relay-fanout/SKILL.md, line 18:

<comment>This changes the workspace-key handling behavior for the published claude-relay-plugin (workers no longer receive the key in their prompt, and printing/requesting it is now disallowed), but none of the plugin's version declarations (marketplace.json, plugin manifest, package.json) appear to be bumped alongside it. Since marketplace clients rely on that version to detect updates, existing installations could remain on the old prompts that still expose workspace keys instead of picking up this fix. Consider bumping the plugin version declarations together with this change.</comment>

<file context>
@@ -11,49 +11,45 @@ $ARGUMENTS
-- Use relay MCP tools (`send_dm`, `check_inbox`) to monitor worker progress.
+- Use `subagent_type: "relay-worker"`. Only `relay-worker` subagents get the Agent Relay MCP server, the inbox-polling hooks, and the worker protocol. Other subagent types (`researcher`, `general-purpose`, …) cannot talk over the relay.
+- Run all workers in **background mode** (`run_in_background: true`) so they work concurrently.
+- Workers inherit the workspace automatically — the relay MCP server resolves the workspace pinned to this project. **Do not put the workspace key in a worker prompt.** It is an administrative credential, and copying it into N prompts puts it in N transcripts. If a worker reports no workspace, fix the pin (step 2) rather than pasting the key.
+- The `SubagentStart` hook injects the relay bootstrap (register, check inbox, ACK, DONE) into every worker.
+- Use the relay MCP tools (`send_dm`, `check_inbox`) to monitor progress.
</file context>

- The `SubagentStart` hook injects the relay bootstrap (register, check inbox, ACK, DONE) into every worker.
- Use the relay MCP tools (`send_dm`, `check_inbox`) to monitor progress.
- Do not add setup scripts or dependencies. Use the plugin's existing hooks, MCP tools, and `relay-worker` agent definition.

## Protocol

1. Pick a stable coordinator name such as `relay-lead`. On every relay tool call you make as the coordinator, include `as: "relay-lead"` so your messages, inbox checks, and reactions stay attributed to the lead.
2. **Set up the workspace.** Try calling `register_agent` with a coordinator name like `relay-lead`. If it fails with "Workspace key not configured", call `create_workspace` to generate one, then call `set_workspace_key` with the returned key, then `register_agent`. Save the workspace key — you will pass it to every worker.
3. **Tell the user they can follow along with the conversation.** Print the full observer URL with the real key value: `https://agentrelay.com/observer?key=<the actual key>`. Do not print a placeholder — print the real URL the user can click. This is mandatory.
4. Confirm the work is truly parallelizable. Every worker should be able to finish without waiting on another worker's output.
5. Decide the worker count from the task shape. Prefer 2 to 8 workers, but keep the count low enough that you can still monitor ACKs and completions reliably.
6. Partition the work into independent units. Each unit should have its own files, target, or scope boundary and should not require shared intermediate state.
7. Spawn one worker per unit using the Agent tool. **You must include the workspace key in the prompt**:
1. Pick a stable coordinator name — `relay-lead`. Pass `as: "relay-lead"` on **every** relay tool call you make, so your messages, inbox reads, and reactions stay attributed to the lead.
2. **Set up the workspace.** Call `register_agent` with `relay-lead`. If it fails with "Workspace key not configured", call `create_workspace`, then `register_agent` again. Both `create_workspace` and `set_workspace_key` pin the workspace to this project, which is how workers pick it up.
3. **Give the user a link to follow along.** Call `get_observer_url` and print the URL it returns. It is backed by a read-only token that expires, so it is safe to share. Never build an observer URL from the workspace key, and never print the key.
4. Confirm the work is genuinely parallelizable. Every worker must be able to finish without waiting on another worker's output. If that is not true, use the pipeline pattern instead.
5. Pick the worker count from the task shape. Prefer 2–8, and stay low enough that you can still track every ACK and DONE.
6. Partition the work into independent units — each with its own files, target, or scope boundary, and no shared intermediate state.
7. Spawn one worker per unit with the Agent tool:
```
Agent(
subagent_type: "relay-worker",
run_in_background: true,
prompt: "You are relay-worker-N. Your lead is relay-lead.
Workspace key: <the actual key>.
CRITICAL: On every relay tool call, include as: \"relay-worker-N\". Without as, your messages can be attributed to another agent.
CRITICAL: pass as: \"relay-worker-N\" on every relay tool call, or your messages
can be attributed to another agent.
Your unit: [specific target/scope].
Files: [list of files/directories].
Deliver: [concrete output]."
Deliver: [concrete output].
Do NOT release yourself when done — report DONE and stay idle for review."
)
```
8. Each worker's prompt must include:
- the workspace key
- the unit it owns
- the exact files, directories, or target it should handle
- its assigned relay name and who its lead is
- a reminder to use `as: "<worker-name>"` on every relay tool call
9. Wait for ACK from every worker via relay inbox with `check_inbox(as: "relay-lead")`. Missing ACK means the worker is not ready.
10. Let workers run independently. Only send follow-up DMs for blockers, missing ACKs, or a global decision that changes all units, always using `as: "relay-lead"` for coordinator messages.
11. Collect all DONE messages, verify the outputs, and merge the final summary. Call out any units that finished partially or encountered blockers.
8. Wait for an ACK from every worker with `check_inbox(as: "relay-lead")`. A missing ACK means that worker is not working — re-DM it.
9. Keep a live worker table in your notes: name, unit, ACK, blocked, DONE.
10. Let workers run independently. Only DM them for blockers, missing ACKs, or a global decision that changes every unit.
11. Collect every DONE, verify the outputs yourself, and merge the summary. Call out units that finished partially or hit blockers.

## Rules

- Do not use this pattern when stage N depends on stage N-1. That is a pipeline.
- Do not give multiple workers the same files unless duplicate review is intentional.
- Keep the task wording uniform so worker outputs are easy to compare and merge.
- Workers cannot spawn their own subagents — only the lead can spawn workers.
- Do not give two workers the same files unless duplicate review is the point.
- Keep the task wording uniform across units so the outputs are easy to compare and merge.
- Workers cannot spawn their own subagents — only the lead spawns.
Loading