vibe-delegate

Vibe Delegate

你是编排者。将边界明确的编码任务交给独立的实现者——Mistral Vibe CLI（vibe），然后审查其产出并亲自提交。你负责撰写任务说明并做出判断；Vibe 在自己的会话中编写代码；你负责验证并提交。

这个工作循环只需要 shell 命令和文件访问权限，因此任何类似的编排者都能驱动它。

以下情况请勿使用

• 任务足够小，可以直接完成；委派带来的开销不值得。
• 未安装或未通过身份验证的 vibe CLI。

前置条件（只需检查一次）

1. 安装 uv，然后安装 Mistral Vibe：
   • uv tool install mistral-vibe
2. 使用 vibe --setup 配置 API 密钥，或在环境中设置 MISTRAL_API_KEY。
3. 确认 vibe --version 能成功运行。
4. 在目标 Git 仓库中工作，或将 --cd 指向该仓库。

工作循环

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

1. 撰写任务说明

Vibe 只能看到你发送的文本以及它能在工作区中检查到的内容——没有聊天记录，也没有共享上下文。请说明目标、当前状态、要更改的内容、保持不变的内容、项目实际的检查门槛，以及报告要求。告知 Vibe 不要提交。每份任务说明只包含一项任务。参见 references/writing-the-brief.md。

默认模式无法在无交互情况下批准大多数 shell 命令，因此由编排者运行检查门槛。只有在人类明确授权使用 --full-access 时，才要求 Vibe 运行这些检查。

2. 派发

对于 Codex 编排的后台工作，请先安装并配置独立的 codex-background 支持工具。如果缺少其 MCP 工具或注册表，请停止并报告所需的设置；不要悄悄退回到由模型驱动的轮询。然后调用其已注册的 delegate_run MCP 工具，替代下面的 shell 示例。 遵循该技能，使用结构化的通用参数、保持提供方标志不变，并通过 runId 重新连接。保持请求待处理，直到任务完成，然后继续执行本技能中的审查和提交步骤。其他编排者使用下面的 shell 工作流。

使用随附的辅助脚本。它封装了 Vibe 的无头 --prompt 模式，捕获结构化事件流，并写入 result.json。（<skill-dir> 是已安装且包含此 SKILL.md 的文件夹。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# limit turns for cost control:           add --max-turns <n>
# indicative price threshold/token cap:  add --max-price <usd> --max-tokens <n>
# planning/read-only:                     add --plan-only
# unrestricted shell and tools:           add --full-access (explicit authorization required)
# resume the most recent session:         add --resume-last  (delta brief only)
# resume a specific session:              add --session <id> (delta brief only)
# see all options:                        node .../relay.mjs --help

子进程的 cwd 会固定工作区。中继程序默认将产物写入系统临时目录，且不会提交。参见 references/dispatch-and-poll.md。

3. 等待完成

使用 codex-background 的 Codex 会让原始 MCP 请求保持待处理：不要由模型驱动休眠、状态轮询或日志轮询。只有在请求中断后，才使用 delegate_wait 重新连接。

辅助脚本会阻塞，直到 Vibe 完成。使用编排者的后台命令功能运行它，或在 shell 中将其置于后台，并轮询 result.json。运行前的用法错误会以 2 退出，且不会写入结果；找不到 vibe 时会以 127 退出，并写入 status: "vibe_unavailable"。 看门狗会写入 status: "timeout"；在 POSIX 系统上终止中继程序时，它会先停止 Vibe 的进程树，然后写入 status: "aborted"。

应以进程状态和工作树为准，而非进度显示。只有进程已退出且 result.json 存在，才算完成。

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

将 Vibe 的最终消息和检查门槛声明视为未经证实的说法：

• 亲自重新运行项目的检查门槛。
• 根据任务说明阅读差异，从 touchedFiles 开始。
• 如果已安装相关防护技能，请运行它们。
• 移除或重命名内容后，往返验证迁移，并通过 grep 查找悬空引用。

参见 references/review-and-land.md。

5. 提交

实现者修改工作树；**由编排者提交。**只有在检查门槛通过且差异符合要求后才提交。如果需要返工，请使用 --resume-last 或 --session <id> 发送差异说明，然后再次审查。

自主性与权限

在 --prompt 模式下，中继始终会显式设置 Agent 配置：

中继标志	Vibe 获得的配置	适用场景
(默认)	--agent accept-edits	常规实现——内置文件编辑已获批准
--plan-only	--agent plan	只读审查、探索或规划
--full-access	--agent auto-approve	需要任意 shell/工具权限且已获明确授权的运行

默认模式允许 Vibe 在目标工作树中编辑文件。需要审批的 shell 命令（包括大多数项目门禁）在无头模式下会被拒绝；由编排器运行这些门禁。--full-access 会关闭 Vibe 的工具审批，并允许其以用户账户执行任意 shell/工具操作；仅在获得明确人工授权时使用。运行后务必检查 touchedFiles 和差异。

始终传入 --trust，以避免无头运行时出现交互式目录信任提示。它不是沙箱，也不会授予工具权限。

授权模型

委派任务需要由人主动选择。一旦对方表示已同意（“运行这个队列”“继续”），提交已验证且通过门禁的工作就是双方约定的任务内容。仍有两条限制：呈现而非吸收（报告 Vibe 的设计决策、有理有据但未被要求的改动，以及不影响阻塞的细小问题），以及遇到范围变更时暂停（如果正确完成任务需要超出简述范围，应先询问，而不是擅自扩大授权）。参见 references/review-and-land.md。

参考资料

• references/writing-the-brief.md — 结构、报告约定、真实门禁、argv 传递和增量简述。
• references/dispatch-and-poll.md — 标志、产物、result.json、轮询和故障恢复。
• references/review-and-land.md — 审查清单、提交边界，以及通过 Vibe 会话返工。
• references/multi-task-queues.md — 顺序队列、约束延续、进度跟踪和最终一致性检查。