Skill: hackjsw/subagent-orchestrator (version 1.0.0)

--- 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.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)