working-with-an-openrig-team

用途

该技能规范了编码代理应用（如 Claude Code、Codex、Cursor、VS Code）通过 OpenRig MCP 服务器与 OpenRig 团队协作的完整循环。用户运行一个由多个代理组成的团队，每个代理有自己的终端，并在聊天结束后继续工作。当前编码代理不是这些终端之一，而是用户通向团队的前门：负责把工作交给团队、跟踪进展、将团队的问题转达给用户，并带回团队产出。MCP 服务器自身的说明定义了各工具的行为，本技能描述围绕这些工具的协作循环。

主要能力

1. 检查连接：调用 rig_whoami 获取当前连接作为哪个座位（seat）行事。每个创建的工作项都记录来自该座位，团队关于该工作的提问也会回到该座位。若无座位，仍可派发工作，但发送者为 rig_whoami 指出的未知发送者，无返回地址，需告知用户 qitemId 并通过 rig_queue_show 跟踪；接收团队问题、记录用户回答、列出自己的工作项需要座位。

2. 查询团队：调用 rig_team 并传入 rig 名称，查看团队座位、各座位用途及负责人（lead）。工作默认发给负责人，除非用户指定座位。若负责人为 null（leadNote 说明原因）且团队恰好只有一个座位，则发给该座位；否则询问用户由哪个座位接收。

3. 派发工作：使用 rig_queue_create，传入 destination（负责人或用户选择的座位）和 body。body 应面向有能力的同事撰写：目标、重要性、完成标准、可查看的位置，并添加一行摘要。创建后告知用户返回的 qitemId，双方靠它再次找到该工作项。若调用超时，先用同一 qitemId 调用 rig_queue_show 检查，再决定是否重试；重试必须传同一 qitemId，绝不能用新 id，否则会重复创建工作。

4. 跟踪工作：用 qitemId 调用 rig_queue_show 获取状态、当前所有者和状态转换。座位转交工作时，工作项会指明下一个座位，需沿链跟踪到最新项后再报告。报告应基于记录内容：已接受或已认领不等于完成，安静也不等于卡住；说明看到的内容及最后变更时间。团队完成时不会唤醒当前聊天，需在用户询问或回来时检查。

5. 处理团队问题：关于当前工作的提问会到达当前座位，用 rig_queue_list 加 owned 列出。向用户展示问题和团队草稿（以工作项给出的原文），然后请用户回答。只记录用户实际告诉你的内容：先 rig_queue_claim 认领，再用 rig_queue_update 关闭，state 设为 done，closureReason 设为 no-follow-on，resolution 中只放用户输入的原内容，不加标签、引号、备注、路径或你自己的摘要。若用户不在无法回答，保持工作项打开并告知用户它在等待，绝不代选答案。有些问题直接发给用户（在当前座位之外），在用户已有的团队应答处（如 OpenRig TUI 或 Slack）等待；可提醒用户它们在等待，但回答不属于当前代理职责。

6. 读取结果：工作项完成后，其 resolution 是答案，transitions 保存团队记录的备注。若工作项指明 evidenceRef，用 rig_artifact_read 读取，传入该工作项的 qitemId（不是路径）；工具会在当前连接可读的共享根目录内读取该工作项的 evidenceRef。读取共享根目录中的其他文件时，传入根目录名称和路径。若连接无法读取，把路径交给用户。如需请求修改，创建新工作项并将 revises 设为之前工作项的 qitemId，使修订与原始工作关联。

7. 后续查看：rig_queue_list 加 mine 列出当前座位发送或拥有的工作项；加 all 包括已完成工作；加 since 查看某时间后变更的内容。同一座位的新聊天可访问相同工作，工作项寿命超过对话。

使用方式

首次需与用户一起设置（只需一次）：OpenRig 在本机运行团队，rig ps 列出用户的 rigs。在某个 rig 上为当前应用选择一个地址，例如 cursor@my-team。该地址是队列接收工作项的地址，但不会为其启动任何东西。若要告知团队其用途，用户可将其作为托管成员加入名册（OpenRig 包中的 docs/reference/hosted-members.md）。然后将应用连接到该地址，并启动新会话使 MCP 服务器随之启动：

• Claude Code：在插件设置中将其设为插件的 OpenRig 座位。
• Codex：运行 codex mcp add openrig --env OPENRIG_SESSION_NAME=<address> -- rig mcp serve --front-door。Codex 默认不会向 MCP 服务器转发所有 shell 环境变量，若团队的 OpenRig home 不是默认值，还需加 --env OPENRIG_HOME=<that home>。
• 其他应用：添加一个运行 rig mcp serve --front-door 且 OPENRIG_SESSION_NAME 设为该地址的 MCP 服务器，并关闭插件的 openrig 服务器，使应用只运行一个。在 VS Code 中给自建的起另一个名字，如 openrig-seat；在 Cursor 中禁用 openrig · Plugin。从 shell 启动应用时设置变量仅对该次启动有效。

适用场景

• 用户希望通过编码代理应用把任务交给本机的 OpenRig 团队，并跟踪团队处理。
• 需要将团队关于工作的提问转达给用户，并把用户回答原样记录回工作项。
• 需要读取团队产出的结果或证据文件，或对已有工作请求修改。
• 需要在后续对话中继续查看同一座位发送或拥有的工作项。

限制

• 技能不会向应用添加面板，团队完成时也不会唤醒当前聊天。
• 同一台机器上使用该应用的任何人都会以插件指定的座位行事。
• 只能连接本机上的团队；托管在别处的团队需要该主机自己的连接。
• 无座位时无法接收团队问题、记录用户回答或列出自己的工作项。
• 不代用户选择答案；用户不在时应保持问题打开并告知等待。
• 重试派发工作必须使用同一 qitemId，否则会重复创建。