muse-delegate

Muse Delegate

你是协调者。这项技能让你能够把范围明确的编码任务交给独立的实现者——Muse Code（muse），之后审查其成果并自行提交。你撰写任务说明并负责判断；Muse 在自己的 exec 运行中编写代码；你负责验证并提交。

这里的内容并非针对某一种协调 Agent。这个流程只需要能够运行 shell 命令和读取文件，因此任何具备这两项能力的 Agent 都能执行。完整的委派 → 审查 → 提交流程已使用 Claude Code 作为协调者运行过。其他协调者尚未验证。

何时不该使用

• 任务足够小，可以直接完成——委派带来的额外开销不值得。
• 未安装 muse CLI，或尚未完成身份验证（运行 muse login，或设置 META_API_KEY）。
• 你想自己编写代码。
• 你使用的是原生 Windows，且需要受支持的启动器。上游的 muse 启动器仅支持 Darwin/Linux；此技能仍包含在 Windows 合约矩阵中，但不支持在 Windows 上实际调用 Muse 安装程序。

首次调用前请阅读：自主运行模式

无头 Muse 只能使用 muse exec。muse resume 是交互式 TUI，绝不会调用。 --resume-last 会被拒绝；要继续某次运行，请使用 --session <id>（Muse 的 --session-id）。

写入运行会保持 Muse 的沙盒开启，并传入 --disable-approval，以免无头运行因工具审批提示而挂起。此外还会传入 --trust-workspace 和 --user-input-auto-resolve。这既不是 --yolo，也不是 --full-access——不要擅自将它们设为默认值。--trust-workspace 会将目标仓库的规则和技能加载到实现者运行环境中；中继机制不会缩减实现者在沙盒内可用的工具集，因此任务范围由任务说明界定。

--read-only 会添加 --disable-write（禁止非 shell 的文件系统写入）以及 --disable-shell。审批仍会被禁用，以免审查因提示而受阻。

--provider echo|meta 是仅供中继使用的标志，用于测试和明确指定的探测。它不是用于调整整个平台的开关。

前置条件（检查一次即可）

1. muse --version 能够成功运行。若不能，请安装 Muse Code 并运行 muse login（或导出 META_API_KEY）。
2. 确认 PATH 中的 muse 是哪个。 command -v muse 会显示当前使用的启动器。中继会将运行时使用的版本记录到 result.json。
3. 你当前位于目标 git 仓库中，或将使用 --cd 指向该仓库。

选择实现者模型

Muse 有已配置的默认模型，因此新的运行可以省略 --model。如果需要指定目录 ID，请传入 --model，或传入会设置该 ID 的 fleet --lane。在通过 --session 恢复的运行中，应省略 --model，以保留该会话的模型。如果用户没有指定一组可用模型，请先询问，不要擅自猜测计量计费的 ID。

更多详情：references/writing-the-brief.md。

流程

每项任务都要执行以下五个步骤。步骤 1、4 和 5 由你判断；步骤 2 和 3 是机械操作。

1. 撰写任务说明

Muse 只能看到你发送的文本以及它能从工作树中读取的内容——没有聊天记录，也没有共享上下文。任务所需的一切都要写进任务说明：目标、当前状态、要修改的内容、要保持不变的内容、项目实际的检查命令（从仓库的 AGENTS.md/CLAUDE.md/Makefile 中查找——不要自行假设），以及报告要求。告诉 Muse 不要提交（由你提交）。每份任务说明只处理一项任务。完整指南和模板： references/writing-the-brief.md。

2. 分派

使用捆绑的辅助工具将简报发送给 Muse。它封装了 muse exec --json --prompt-file，会捕获运行过程并写入结构化的 result.json。（下文的 <skill-dir> 是此技能的安装目录，也就是包含此 SKILL.md 的文件夹。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# optional model:                           add --model <id>
# fleet lane from delegate-setup:           add --lane <name>  (dials apply; flags still win)
# reasoning intensity:                      add --effort none|minimal|low|medium|high|xhigh|max|ultra
# read-only (no non-shell writes, no shell): add --read-only
# continue a specific Muse session:         add --session <id>  (delta brief only; no --resume-last)
# hard time limit (watchdog):               add --timeout 2h  (default: off; implementation runs routinely need 1-2h)
# see all options:                          node .../relay.mjs --help

辅助工具会将产物写入临时目录，因此正在审查的仓库会保持干净。它绝不会提交——请参阅步骤 5。运行机制、标志和 result.json 的结构： references/dispatch-and-poll.md。

3. 等待完成

辅助工具会一直阻塞，直到 Muse 完成，因此请根据编排器提供的功能运行，并在其返回时恢复：

• Claude Code： 将 Bash 调用设为 run_in_background: true；完成时会收到通知。
• 纯 Shell／其他 Agent： 对于较短的任务，在前台运行；也可以在后台运行并轮询结果文件。result.json 存在且包含 status 时，运行即告完成。（运行前发生的用法错误——参数错误或简报为空——会以代码 2 退出且不写入结果文件，因此也要检查退出代码。缺少 muse 二进制文件时会以 127 退出，但仍会写入状态为 muse_unavailable 的 result.json。--resume-last 属于用法错误：无界面恢复应使用 --session <id>。）

不要相信进度跟踪器，要以实际情况为准：只有在写入 result.json 且进程已退出后，运行才算结束。Muse 可能会以 0 退出，却没有 run.terminal.completed 事件；中继会将这种情况报告为 failed，而非 completed。实施者的完整报告位于 result.json 的 finalMessage 字段中（也会在标准输出的报告标记之间完整打印）。

4. 审查——不要相信自述

Muse 的 result.json 包含其最终消息和任何关于门禁的声明。务必重新验证，不要直接采信：

• 亲自重新运行项目的门禁（步骤 1 中的测试／lint／构建命令）。切勿盲信“门禁已通过”。
• 对照简报阅读差异：Muse 是否按要求完成，没有多做（范围蔓延）或少做？结果中的 touchedFiles 是你的检查起点。
• 如果安装了相关的防护技能，请对差异运行这些技能（如 guard-skills 中的 clean-code-guard、test-guard 等）——此技能负责产出成果，其他技能负责评判成果。
• 对于架构／迁移更改，进行往返验证；对于删除内容，使用 grep 检查是否存在悬空引用。

完整清单：references/review-and-land.md。

5. 落地

实施者编辑工作树；编排器负责提交。 提交应由验证工作的一方执行。只有在门禁通过且差异符合要求后，才能：

• 亲自提交已验证的工作，并使用清晰的提交说明。
• 如果需要修改，使用 --session <id> 发送增量简报（不要重述整个任务），然后再次审查。无界面模式不支持 --resume-last。

授权模式

委派由人类自行选择启用。一旦他们选择启用（“运行这个队列”“继续”），提交已验证且通过门禁的工作就是双方约定的契约——这正是整个流程的目的。此授权有两项限制：指出问题，不要擅自处理（报告 Muse 的设计决策、有理有据但未受委托的改动，以及不阻塞任务的小问题，而不是默默保留这些内容），以及遇到范围变更就暂停（如果要正确完成任务就必须超出简报范围，请先询问，不要自行扩大授权）。完整说明请参阅 references/review-and-land.md。

参考文档

• references/writing-the-brief.md — 如何编写一份 Muse 无需人工干预即可执行的简报：结构、XML 块、报告约定，以及如何嵌入实际的门禁命令。
• references/dispatch-and-poll.md — relay.mjs 标志、result.json 约定、各编排器的后台运行方式，以及运行异常时的恢复方法。
• references/review-and-land.md — 审查清单、提交边界，以及通过 --session 进行的返工周期。
• references/multi-task-queues.md — 如何运行顺序队列：延续约束、跟踪进度，以及运行结束时的一致性检查。