omp-delegate

Oh My Pi Delegate

你是编排器。将范围明确的编码任务委派给独立的实施者——Oh My Pi（omp），然后审查其产出并由你亲自提交。你撰写任务说明并负责判断；实施者在自己的会话中修改代码；你负责验证并提交。

整个流程只需要一条 shell 命令和文件访问能力，因此任何类似的编排器都可以执行。

可执行文件是 omp，不是 pi

Oh My Pi 是 Pi 的一个分支。此技能驱动的是**omp**（@oh-my-pi/pi-coding-agent）。原版 Pi CLI 是另一个可执行文件（pi），使用不同的技能（pi-delegate）。如果未找到 omp，但已安装 pi，说明你安装的是 Pi，而不是 Oh My Pi。

以下情况不要使用

• 任务小到可以直接完成；委派带来的额外开销不值得。
• 未安装或未通过身份验证的 omp CLI。
• 用户要求使用原版 Pi CLI（pi）——请使用 pi-delegate。
• 你需要一个沙箱化的实施者。Oh My Pi 没有沙箱。--read-only 会限制可用工具；允许写入的运行则会在不提示的情况下执行（--yolo）。

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

1. 使用 bun install -g @oh-my-pi/pi-coding-agent 安装 omp（或使用 https://omp.sh 上提供的安装方式）。
2. 完成身份验证：对于订阅服务提供商，在 omp 中使用 /login；对于 API 密钥服务提供商，设置 API 密钥环境变量。凭据保存在 ~/.omp/ 下。
3. 确认 omp --version 可成功运行。
4. 在目标 git 仓库中工作，或通过 --cd 指向该仓库。

选择模型（可选）

省略 --model（和 --provider），即可使用 omp 为此项目／配置文件设置的默认值。可用模型目录取决于当前安装中已通过身份验证的服务提供商，并非此技能中的固定列表。

如需选择其他模型：

1. **列出当前安装实际可运行的模型。**不要传入 omp --list-models——该标志已移除，omp 会将其视为未知标志（退出码为 2）。请使用 models 子命令：
   • omp models — 列出所有可用模型，并按服务提供商分组
   • omp models --json — 以机器可读格式列出相同目录
   • omp models find <substring> — 按服务提供商、ID 或名称筛选（例如： omp models find sonnet）
   • omp models <provider> — 列出某个服务提供商的模型
2. 将该 ID 传递给中继。--model <pattern> 是 omp 自带的 --model：它会在目录中模糊匹配（服务提供商／ID、单独的 ID 或唯一子字符串）。如果匹配模式存在歧义，可用 --provider <name> 指定服务提供商。
3. 中继只会转发字母、数字和 . _ : / -。不接受包含 * 的 glob 模式。

--thinking <level> 是单独的推理强度设置，不是模型 ID。允许的值：off、auto、 minimal、low、medium、high、xhigh、max。中继会在分派前拒绝其他任何值（包括 inherit）；否则 omp 会发出警告并忽略无效值。

Fleet 通道（--lane）可以设置 provider、model 和 effort。通道的 effort 会转换为 --thinking；显式传入的 --thinking／--model／--provider 标志优先于通道设置。

中继不会转发 --api-key、--smol、--slow 或 --plan。这些仍由 omp 自己的 CLI 处理。

流程

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

1. 撰写任务说明

Oh My Pi 只能看到你发送的文本以及它能在工作区中检查的内容——没有聊天记录或 共享上下文。请说明目标、当前状态、需要修改的内容、需要保持不变的内容、项目的实际检查门槛，以及报告要求。告诉 omp 不要提交。每份任务说明只包含一项任务。 omp 会自动加载工作区及其父目录中的 AGENTS.md／CLAUDE.md 上下文文件，因此仓库说明无需内联也能传达给它。请参阅 references/writing-the-brief.md。

2. 派发

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

使用捆绑的中继程序。它会将任务说明通过标准输入传递给 omp --mode json，捕获 JSON 事件流，并写入 result.json。（<skill-dir> 是安装了此 SKILL.md 的文件夹。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# list models first:                       omp models   (or: omp models --json)
# choose a model:                          add --model <id from omp models>
# choose a provider:                       add --provider <name>
# set thinking level:                      add --thinking high
# read-only run (review/diagnosis):        add --read-only
# trust project .omp resources:            add --approve
# resume the most recent session:          add --resume-last  (delta brief only)
# resume a specific session:               add --session <id> (delta brief only)
# hard time limit (watchdog):              add --timeout 2h  (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options:                         node .../relay.mjs --help

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

3. 等待完成

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

中继程序会一直阻塞，直到 omp 运行结束。使用编排器的后台命令功能运行它，或在 shell 中将其放到后台运行，并轮询 result.json。运行前的用法错误会以状态码 2 退出，且不会写入结果；缺少 omp 时会以状态码 127 退出，并写入 status: "omp_unavailable"。

应以进程状态和工作树为准，而不是进度显示。进程已退出且 result.json 存在，即表示任务完成。omp 的完整报告位于 result.json 的 finalMessage 字段中（也会在标准输出中、报告标记之间完整打印）。

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

将 omp 的最终消息和门禁声明视为待核实的说法：

• 自行重新运行项目的门禁。
• 对照任务说明阅读差异，从 touchedFiles 开始。
• 如果已安装，请运行相关的防护技能。
• 对迁移进行往返验证，并在移除或重命名后 grep 悬空引用。

请参阅 references/review-and-land.md。

5. 提交

实现者编辑工作树；编排器负责提交。 只有在门禁通过且差异符合要求后才提交。如果需要返工，请使用 --resume-last 或 --session <id> 发送增量任务说明，然后再次审查。

自主性和权限

Oh My Pi 没有沙箱。打印模式没有审批界面，因此可写的中继程序运行始终会传递 --yolo（tools.approvalMode: yolo）——否则用户的 always-ask 或 write 配置会导致任务一直停滞，直到监控程序超时。其他控制措施如下：

1. --read-only 会将 omp 可调用的工具限制为 --tools read,grep,glob。它不会传递 --yolo。如果项目资源可信，已安装的扩展代码仍会在用户的主机权限下运行。
2. 默认情况下，中继程序会传递 --no-extensions --no-skills --no-rules，因此不会发现项目的 .omp 扩展、技能和规则。对于用户信任的代码库，可以通过 --approve 明确选择启用。
3. touchedFiles 和差异记录了发生的更改。每次运行后都要检查它们。

授权模型

是否委派由人类决定。一旦他们选择委派（“运行这个队列”“继续”），提交已验证且通过门禁的工作就是双方约定的责任。仍有两项限制：说明，不包揽（报告 omp 的设计决策、有理有据但未经请求的改动，以及不阻塞任务的小问题）；以及范围变更时停止（如果正确完成任务需要超出任务说明的范围，应先询问，而不是擅自扩大授权）。请参阅 references/review-and-land.md。

参考资料

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