---

name: subagent-orchestrator description: Orchestrate OpenClaw subagents for continuous autopilot workflows. Use when managing UI/代码/验证/档案/侦察 task lines, continuing multi-round work without waiting for the user to restate each step, cleaning finished sessions while preserving memory records, routing default models by role, or updating AGENT_TASK_BOARD / subagent handoff rules.

subagent-orchestrator

Run continuous task lines through the main controller, not by accident.

Core rules

1. Treat autopilot as a continuous line

   • Do not stop at “one run finished”.
   • A finished run means handoff, not “whole line done”.
   • Continue until one of: complete, blocked, paused by user.

2. The main controller must directly re-dispatch

   • Do not wait for the user to remind you to continue.
   • For every autopilot line, the main controller decides the next slice and spawns it.

3. Keep the task board current

   • Update AGENT_TASK_BOARD.md before or when dispatching the next round.
   • Record: goal, current round, completed items, remaining items, next slice, follow-up roles.

4. Keep subagent replies short

   • Prefer: goal / completed / files / status / next / risk.
   • Avoid long background restatements.

5. Clean finished sessions, keep memory

   • Finished subagent sessions do not need to be kept.
   • Before forgetting them, write the durable record into memory/YYYY-MM-DD.md.
   • Include at least: task goal, changed files, result status, risk, next step.
   • Promote stable collaboration rules into MEMORY.md when needed.

6. Do not keep unnecessary artifacts

   • Temporary screenshots, temp files, and intermediate outputs can be deleted when no longer needed.
   • If the user wants screenshot proof, prefer sending it directly instead of long-term local retention.

Role routing

Do not hard-code project-specific model rules into this skill.

Use the current session defaults unless the user or project rules override them. If a project has role-specific model preferences, keep them in project memory, task board rules, or project docs — not as universal orchestrator behavior.

Dispatch pattern

When an autopilot line is active:

1. Read the current line from AGENT_TASK_BOARD.md
2. Pick the next small closed slice
3. Spawn the correct role
4. Require short structured return
5. On completion:
   • summarize for the user
   • update memory
   • clean finished session if no longer needed
   • immediately dispatch the next slice if the line is still active

Cross-role coordination

Cross-role dependency pattern

When one role creates a dependency for another role:

• the producing role must explicitly name the follow-up role in next_role
• the main controller should dispatch that follow-up role without waiting for the user to restate it
• do not let dependent task lines drift apart

Examples:

• research -> UI integration
• code logic -> validation
• code structure -> UI presentation

Validation

Validation is a follow-up role, not usually the main line. Trigger it after:

• a meaningful UI slice
• a meaningful code slice
• a user asks for proof/checks

Return protocol

Keep the canonical protocol in references/SUBAGENT_RECORD_PROTOCOL.md and use it together with this skill.

Require subagents to include these header fields before the short report:

• tag: one of autopilot | done | idle | blocked | handoff | need_user
• line: the task line name, such as ui-autopilot, code-autopilot, scout-art, archive-worldview
• node: the current task-line node id, such as code-n4, ui-n5
• goal_status: use only partial | complete | waiting | blocked (do not invent values like half_done, in_progress, done)
• next_role: free-form next owner/role label, such as ui, code, verify, research, archive, user, none, or any project-specific role name

Then use the short body (see references/SUBAGENT_RECORD_PROTOCOL.md for the full paired format):

1. Goal
2. Completed (max 3-4)
3. Changed files
4. Status
5. Next
6. Risk

Tag meanings

• autopilot: this round finished, but the whole line is probably not done; main controller must compare against the task board and either continue or close
• done: the whole line is complete
• idle: this role is waiting for another line or condition; do not continue this role yet
• blocked: the line cannot safely continue automatically
• handoff: this round finished and the next role is already clear
• need_user: user decision is required before any safe continuation

Main-controller decision rules

When a subagent returns:

1. If tag=done

   • close the line
   • write memory
   • clean finished session

2. If tag=autopilot

   • compare against AGENT_TASK_BOARD.md
   • resolve the current line and node
   • ignore vague per-run completion phrasing in the body
   • if node != end_node, dispatch the next node immediately in the same controller turn
   • only close the line when current_node == end_node and the line completion condition is actually satisfied

Anti-drop guard

For every autopilot return, the main controller must verify all three:

• the line exists on the task board
• the line is not yet complete
• a next dispatch was either sent, or the line was explicitly converted to idle, blocked, need_user, or done

If none of those happened, the turn is incomplete and should not be considered finished.

Stricter continuation rules

A local slice finishing is not enough to stop a line. Do not treat phrases like “this small closure is done”, “this round passed”, or “this piece is complete” as permission to pause.

The controller may stop only when one of these is true:

• current_node == end_node and the line completion condition is actually satisfied
• the return is explicitly blocked
• the return is explicitly need_user
• the user explicitly paused/stopped the line

If a subagent returns goal_status: complete for a node, that means:

• the node itself finished
• the controller must immediately resolve next_on_done
• and dispatch the next owner in the same turn unless the line is truly at end_node

Delivery-proof rule

If a task claims a delivery/output was completed on an external surface (for example Discord/Telegram/channel/thread/board), the controller must require proof. A claim like “已上屏 / 已交付 / 已发布 / 已发送” is not sufficient by itself.

Minimum proof for delivery-type tasks:

• target channel/thread id
• message id (or equivalent object id)
• a human-checkable location description

If any proof item is missing, treat the task as not delivered yet. Do not mark the line done or the node complete on verbal assurance alone.

Mandatory node advancement

After receiving a valid autopilot return with line and node, the main controller must do this in order:

1. resolve the matching task-line in AGENT_TASK_BOARD.md
2. resolve the current node definition
3. advance current_node to that node's next_on_done
4. if the advanced node is not end_node, dispatch the owner of the advanced node immediately in the same turn

Do not stop after summarizing the finished round. The turn is only complete after the node has been advanced and the next node has either been dispatched or explicitly put into idle / blocked / need_user / done.

3. If tag=handoff

   • dispatch next_role directly
   • update task board

4. If tag=idle

   • do not continue this role yet
   • mark dependency in task board
   • resume after the dependency line advances

5. If tag=blocked

   • stop automatic continuation
   • summarize blocker
   • ask only for the smallest required decision if needed

6. If tag=need_user

   • ask the user
   • do not keep other roles guessing

Completion conditions

Only mark a line done when:

• the user says stop/pause, or
• the task board objective is fully satisfied and no meaningful next slice remains.

Do not mark done just because one run finished.