# 团队技能 `$team` 是 OMX 基于 tmux 的并行执行模式。它在分割窗格中启动真正的工作人员 Codex 和/或 Claude CLI 会话，并通过 `.omx/state/team/...` 文件以及 CLI 团队互操作（`omx team api ...`）和状态文件来协调它们。该技能操作敏感。将其视为操作员工作流程，而不是通用提示模式。 ## 该技能必须做什么 ## GPT-5.4 指导对齐 * 默认为简明、证据密集的进度和完成报告，除非用户或风险级别需要更多细节。 * 将较新的用户任务更新视为活动工作流分支的本地覆盖，同时保留早期的非冲突约束。 * 如果正确性取决于额外的检查、检索、执行或验证，请继续使用相关工具，直到团队工作流程扎根。 * 自动继续执行清晰、低风险、可逆的后续步骤；仅当下一步有重大分支、破坏性或依赖于偏好时才询问。当用户触发“$team”时，代理必须： 1. 直接使用`omx team ...`调用OMX运行时 2.避免用进程内“spawn_agent”扇出替换流程 3. 验证启动和表面混凝土状态/窗格证据 4. 保持团队状态处于活动状态，直到工作人员终止（除非显式中止） 5. 在需要时处理清理和陈旧窗格恢复如果“omx team”不可用，则停止并出现硬错误。 ## 调用合约 omx 团队 [ralph] [N:代理类型] "<任务描述>" 示例： omx 团队 3：执行者“分析功能 X 并报告缺陷” omx 团队“调试片状集成测试” omx 团队 ralph“通过验证提供端到端修复” ### 克劳德队友 (v0.6.0+) 重要提示：“N:agent-type”（例如“2:executor”）选择 **工作者角色提示**，而不是工作者 CLI（“codex”与“claude”）。要启动 Claude 队友，请使用团队工作人员 CLI 环境变量： # 强制所有队友使用 Claude CLI OMX_TEAM_WORKER_CLI=claude omx 团队 2:执行者“更新文档和报告” # 混合团队（工人 1 = Codex，工人 2 = Claude） OMX_TEAM_WORKER_CLI_MAP=codex，克劳德 omx 团队 2：执行者“拆分文档/代码任务” # 自动模式：当工作进程启动参数/模型包含“claude”时，选择 Claude OMX_TEAM_WORKER_CLI=auto OMX_TEAM_WORKER_LAUNCH_ARGS="--model claude-..." omx team 2:executor "运行混合验证" ## 前提条件在运行 `$team` 之前，确认： 1.安装`tmux`（`tmux -V`） 2. 当前领导者会话位于 tmux 内部（已设置“$TMUX”） 3. `omx` 命令解析为预期的安装/构建 4. 如果运行 repo-local `node bin/omx.js ...`，请在 `src` 更改后运行 `npm run build` 5. 检查前导窗口中的 HUD 窗格计数，并在拆分前避免重复的“hud --watch”窗格建议的飞行前检查： tmux 列表窗格 -F '#{pane_id}\t#{pane_start_command}' | rg 'hud --watch' ||真实如果存在重复项，请删除“omx team”之前的额外内容，以防止 HUD 最终出现在工作堆栈中。 ## 前置上下文入口门在启动“omx team”之前，需要一个接地的上下文快照： 1. 从请求中派生任务 slug。 2. 重用`.omx/context/{slug}-*.md`中的最新相关快照（如果可用）。 3. 如果不存在，请使用以下命令创建 `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`)： * 任务说明 * 期望的结果 *已知事实/证据 * 约束条件 * 未知/悬而未决的问题 * 可能的代码库接触点 4. 如果模糊性仍然很高，请首先运行“explore”以获取棕地事实，然后在团队启动之前运行“$deep-interview --quick ”。在满足该门之前，不要启动工作窗格；如果被迫快速进行，请在启动报告中明确说明范围/风险限制。 ## 当前运行时行为（已实现） `omx team` 目前执行： 1.解析args(`ralph`,`N`,`代理类型`,任务) 2. 清理任务文本中的团队名称 3.初始化团队状态： * `.omx/state/team//config.json` * `.omx/state/team//manifest.v2.json` * `.omx/state/team/<团队>/tasks/task-.json` 4. 在以下位置编写团队范围的工人指示文件： * `.omx/state/team/<团队>/worker-agents.md` * 使用项目“AGENTS.md”内容（如果存在）+工作覆盖，而不改变项目“AGENTS.md” 5. 从 Leader cwd 解析规范共享状态根 (`/.omx/state`) 6. 将当前 tmux 窗口拆分为工作窗格 7. 启动工作人员： * `OMX_TEAM_WORKER=<团队>/工人-` * `OMX_TEAM_STATE_ROOT=/.omx/state` * `OMX_TEAM_LEADER_CWD=<领导者-cwd>` * 由 `OMX_TEAM_WORKER_CLI` / `OMX_TEAM_WORKER_CLI_MAP` 选择的工作 CLI（`codex` 或 `claude`） * 使用“--worktree”时可选的工作树元数据环境 8. 等待工作人员准备就绪（“捕获窗格”轮询） 9. 编写每个工作进程的“inbox.md”并通过“tmux send-keys”触发 10、将控制权交还给领导；后续使用 `status` / `resume` / `shutdown` 重要： * 领导者仍保留在现有窗格中 * 工作窗格是独立的完整 Codex/Claude CLI 会话 * 工作人员可以在单独的 git 工作树（`omx team --worktree[=]`）中运行，同时共享一个团队状态根 * Worker ACK 转到 `mailbox/leader-fixed.json` * 通知钩子更新工作人员的心跳并在活跃团队模式下推动领导者 * 提交路由对于每个工作触发器使用此 CLI 解析顺序： 1. 运行时状态提供的显式工作人员 CLI（保留工作人员身份/配置）， 2. 该工作索引的“OMX_TEAM_WORKER_CLI_MAP”条目， 3. 后备`OMX_TEAM_WORKER_CLI`/自动检测。 * 启动和触发提交行为均支持混合 CLI-map 团队。 * 触发器提交因 CLI 而异： * Codex 可能会在繁忙的窗格上使用队列优先的“Tab”（取决于策略）。 * Claude 始终使用直接仅输入 (`C-m`) 回合（从不队列优先 `Tab`）。 ### 团队合作模型+思维解析（当前合同）团队模式从一个共享的启动参数集中解析工作人员**模型标志**（不是每个工作人员模型选择）。模型优先级（从最高到最低）： 1.`OMX_TEAM_WORKER_LAUNCH_ARGS`中的显式工作模型 2.继承leader`--model`标志 3.注入低复杂度默认值：`gpt-5.3-codex-spark`（仅当1+2不存在且团队`agentType`为低复杂度时）思维层面规则（关键）： * **没有模型名称启发式映射。** * 团队运行时不得**从模型名称子字符串（例如，“spark”、“high-capability”、“mini”）推断“model_reasoning_effort”。 * 当领导分配队友角色/任务时，OMX 会从已解析的工作角色（“低”、“中”、“高”）动态分配**每个工作人员的推理工作量**。 * 显式启动参数仍然获胜：如果“OMX_TEAM_WORKER_LAUNCH_ARGS”已经包含“-c model_reasoning_effort=...”，则该显式值会覆盖每个工作线程的动态分配。规范化要求： * 解析 `--model ` 和 `--model=` * 删除重复/冲突的模型标志 * 精确发出一个最终规范标志：`--model ` * 在工作启动配置中保留不相关的参数 * 如果存在显式推理，则保留规范的 `-c model_reasoning_effort=""`；否则注入辅助角色的默认推理级别 ## 所需的生命周期（运营商合约）运行“$team”时遵循以下确切的生命周期： 1.启动团队并验证启动证据（团队线路、tmux目标、窗格、ACK邮箱） 2. 首先使用运行时/状态工具监控任务和工作进程（`omx team status `、`omx teamresume `、邮箱/状态文件） 3.关机前等待终端任务状态： * `待处理=0` * `进行中=0` * `failed=0` （或明确确认的失败路径） 4. 然后运行`omx team shutdown ` 5. 验证关闭证据和状态清理当工作人员正在积极写入更新时，请勿运行“关闭”，除非用户明确请求中止/取消。当运行时/状态证据可用时，不要将临时窗格类型视为主要控制流。 ## 消息分发策略（CLI优先，状态优先）为了避免脆弱的行为，**消息/任务传递不得由临时 tmux 类型驱动**。所需的默认路径： 1. 使用“omx team ...”运行时生命周期命令进行编排。 2. 使用 `omx team api ... --json` 进行邮箱/任务突变。 3. 通过邮箱/状态证据（`mailbox/*.json`、任务状态、`omx 团队状态`）验证交付。严格的规则： * **不得** 使用直接“tmux send-keys”作为传递指令/消息的主要机制。 * **不得** 在未首先检查运行时/状态证据的情况下发送垃圾邮件输入/触发键。 * **必须** 更喜欢持久状态写入 + 运行时调度（`dispatch/requests.json`、邮箱、收件箱）。 * 直接 tmux 交互是**仅后备**，并且仅在失败检查（例如 `worker_notify_failed:`）或显式用户请求（例如“按 Enter”）之后。 ## 操作命令 omx 团队状态 <团队名称> omx 团队简历 <团队名称> omx 团队关闭 <团队名称> 语义： * `status`：读取团队快照（任务计数、死亡/未报告的工作人员） * `resume`：重新连接到实时团队会话（如果存在） * `shutdown`：正常关闭请求，然后清理（删除`.omx/state/team/`） ## 数据平面和控制平面 ### 控制平面 * tmux 窗格/进程（每个工作人员“OMX_TEAM_WORKER”） * 通过 `tmux display-message` 发送领导通知 ### 数据平面 * `.omx/state/team//...` 文件 * 团队邮箱文件： * `.omx/state/team//mailbox/leader-fixed.json` * `.omx/state/team/<团队>/mailbox/worker-.json` * `.omx/state/team//dispatch/requests.json`（持久调度队列；钩子首选，后备感知） ### 关键文件 * `.omx/state/team//config.json` * `.omx/state/team//manifest.v2.json` * `.omx/state/team/<团队>/tasks/task-.json` * `.omx/state/team/<团队>/workers/worker-/identity.json` * `.omx/state/team/<团队>/workers/worker-/inbox.md` * `.omx/state/team/<团队>/workers/worker-/heartbeat.json` * `.omx/state/team//workers/worker-/status.json` * `.omx/state/team-leader-nudge.json` ## 团队突变互操作（CLI-first）使用“omx team api”进行机器可读的突变/读取，而不是传统的“team_*”MCP 工具。 omx team api <操作> --input '{"team_name":"my-team",...}' --json 示例： omx team api send-message --input '{"team_name":"my-team","from_worker":"worker-1","to_worker":"leader-fixed","body":"ACK"}' --json omx 团队 api 声明任务 --input '{"team_name":"my-team","task_id":"1","worker":"worker-1"}' --json omx 团队 api 转换任务状态 --input '{"team_name":"my-team","task_id":"1","from":"in_progress","to":"completed","claim_token":""}' --json `--json` 响应包含用于自动化的稳定元数据： * `schema_version` * `时间戳` * `命令` *`好的` * `操作` *“数据”或“错误” ## Team + Worker 协议注释领导对工人： * 将完整的作业写入工人“inbox.md” * 使用“tmux send-keys”发送短触发器（<200 个字符）工人对领导： * 通过`omx team api send-message --json`发送ACK到`leader-fixed`邮箱 * 通过`omx team api <操作> --json`声明/转换/发布任务生命周期任务ID规则（关键）： * 文件路径使用`task-.json`（例如`task-1.json`） * MCP API `task_id` 使用裸 ID（例如 `"1"`，而不是 `"task-1"`） * 切勿指示工作人员读取 `tasks/{id}.json` ## 环境旋钮有用的运行时环境变量： * `OMX_TEAM_READY_TIMEOUT_MS` * Worker准备超时（默认45000） * `OMX_TEAM_SKIP_READY_WAIT=1` * 跳过准备等待（仅限调试） * `OMX_TEAM_AUTO_TRUST=0` * 禁用信任提示的自动前进（默认行为自动前进） * `OMX_TEAM_WORKER_LAUNCH_ARGS` * 额外的参数传递给worker启动命令 * `OMX_TEAM_WORKER_CLI` * Worker CLI 选择器：`auto|codex|claude` （默认值：`auto`） * 当worker `--model`包含`claude`时`auto`选择`claude`，否则`codex` * 在“claude”模式下，工作人员仅使用一个“--dangerously-skip-permissions”启动，并忽略显式的模型/配置/工作启动覆盖（使用默认的“settings.json”） * `OMX_TEAM_WORKER_CLI_MAP` * 每个工作线程 CLI 选择器（逗号分隔 `auto|codex|claude`） * 长度必须为“1”（广播）或恰好是团队工作人员数量 * 示例：`OMX_TEAM_WORKER_CLI_MAP=codex，codex，克劳德，克劳德` * 如果存在，则覆盖`OMX_TEAM_WORKER_CLI` * `OMX_TEAM_AUTO_INTERRUPT_RETRY` * 触发提交回退（默认：启用） * `0` 禁用自适应队列->重新发送升级 * `OMX_TEAM_LEADER_NUDGE_MS` * 领导者微调间隔（以毫秒为单位）（默认 120000） * `OMX_TEAM_STRICT_SUBMIT=1` * 强制严格发送密钥提交失败行为 ## 故障模式和诊断操作员注意事项（对于克劳德窗格很重要）： * 当工作人员主动处理时，手动输入注入（`tmux send-keys ... C-m`）可能会显得“什么也不做”；输入可以按窗格/任务流排队。 * 这不一定是运行时错误。在诊断调度失败之前确认工人/团队状态。 * 避免重复盲目输入垃圾邮件；一旦窗格空闲，它可能会创建嘈杂的重复提交。 ### 安全手动干预（最后手段）仅在检查 `omx team status ` 和邮箱/状态证据后使用： 1. 捕获窗格尾部以确认当前工作状态： * `tmux 捕获窗格 -t %<工作窗格> -p -S -120` 2. 如果窗格卡在交互状态，请先安全地返回到空闲提示符： * 可选中断“C-c”或转义流（特定于 CLI）一次，然后重新检查窗格捕获 3. 发送一个简洁的触发器（单行）并等待证据： * `tmux send-keys -t % "ack + 继续当前任务；报告状态" C-m` 4. 重新检查： * 通过“capture-pane”的窗格输出 * 邮箱更新（`mailbox/leader-fixed.json` 或工作人员邮箱） * `omx 团队状态 <团队>` ### `worker_notify_failed:` 含义： * Leader写入收件箱但触发提交路径失败检查： 1. `tmux list-panes -F '#{pane_id}\t#{pane_start_command}'` 2. `tmux capture-pane -t % -p -S -120` 3. 验证工作进程是否处于活动状态并且不会卡在信任提示上 4. 如果运行 repo-local 则重新构建 (`npm run build`) ### 团队开始但领导者没有收到 ACK 检查： 1.工作窗格捕获显示收件箱处理情况 2. `.omx/state/team//mailbox/leader-fixed.json` 存在 3. 加载 Worker 技能并调用 `omx team api send-message --json` 4.任务ID不匹配不会阻塞工作流 ### 工作日志 `omx team api ... ENOENT` （或旧版 `team_send_message ENOENT` / `team_update_task ENOENT`）含义： * 当工作进程仍在运行时，团队状态路径不再存在。 * 典型原因：领导者/手动流程在工作人员完成之前运行了“omx team shutdown ”（或删除了“.omx/state/team/”）。检查： 1.`omx team status `并确认关闭时任务是否仍在`in_progress` 2.验证`.omx/state/team//`是否存在 3. 检查工作窗格尾部是否有关闭后写入 4. 确认执行期间没有发生外部清理（`rm -rf .omx/state/team/`）预防： 1. 在关闭之前强制执行完成门（没有正在进行的任务） 2.仅在终端完成或显式中止时使用“shutdown” 3. 如果中止，预计后期工作人员写入会失败并将 ENOENT 视为预期的拆卸工件 ### 关闭报告成功，但陈旧的工作窗格仍然存在原因： *配置跟踪或之前失败的运行之外的陈旧窗格修复： * 手动窗格清理（参见 clean-slate 命令） ## 从头开始恢复从领导窗格运行： # 1) 检查窗格 tmux 列表窗格 -F '#{pane_id}\t#{pane_current_command}\t#{pane_start_command}' # 2) 仅杀死陈旧的工作窗格（示例） tmux 终止窗格 -t %450 tmux 终止窗格 -t %451 # 3) 删除过时的团队状态（示例） rm -rf .omx/state/team/<团队名称> # 4) 重试 omx 团队 1：执行者“新鲜重试” 指南： * 不要杀死领导者窗格 * 不要终止 HUD 窗格（`omx hud --watch`），除非有意重新启动 HUD ## 执行期间所需的报告操作该技能时，提供具体的进度证据： 1. 团队开始行（`团队开始：`） 2. tmux 目标和工作窗格的存在 3.领导邮箱ACK路径/内容检查 4. 状态/关闭结果如果没有文件/窗格证据，请勿声称成功。如果关闭时发生“in_progress>0”，则不要声明干净完成。 ## MCP 作业生命周期工具对于编程或代理驱动的团队生成（与交互式 CLI 使用相反），OMX 通过“团队服务器”公开四个 MCP 工具：工具|描述 ---|--- `omx_run_team_start` |在后台生成 tmux CLI 工作人员；立即返回一个“jobId” `omx_run_team_status` |正在运行的作业的非阻塞状态检查 `omx_run_team_wait` |通过自动闲置窗格微移来阻止直到作业完成 `omx_run_team_cleanup` |杀死工作的工作 tmux 窗格（仅限提前停止） ### CLI 与 MCP 工具 * **`omx team ...` CLI** — 交互式团队编排的主要方法。当您在实时 tmux 会话中进行操作并希望直接查看窗格可见性时，请使用此选项。 * **`omx_run_team_*` MCP 工具** — 用于程序化或代理驱动的团队生成（类似于 OMC 的 `omc_run_team_*` 工具）。当代理需要启动工作程序、轮询状态并收集结果而无需手动干预时，请使用这些。 ### 命名区别存在两种清理工具，切勿混淆： * `team_cleanup` (**state-server**)：删除磁盘上的团队状态 **文件** (`.omx/state/team//`)。团队跑步完全完成后使用。 * `omx_run_team_cleanup` (**team-server**)：杀死 tmux 工作人员**窗格**以完成作业。仅在提前停止工人时使用；否则`omx_run_team_wait`处理自然终止。 ### 基本用法示例 1. omx_run_team_start({ 团队名称：“修复错误”，代理类型：[“法典”]，任务：[{主题：“修复错误”，描述：“...”}]， cwd：“/路径/到/项目” }) → 返回 { jobId: "omx-abc123" } 2. omx_run_team_wait({ job_id: "omx-abc123", timeout_ms: 300000 }) → 阻塞直至完成，自动推动空闲窗格 3. omx_run_team_cleanup({ job_id: "omx-abc123" }) → 仅在提前停止工人时才需要如果您需要在工作人员运行时交错其他工作，则可以在步骤 1 和 2 之间调用“omx_run_team_status”进行非阻塞轮询。 ## 限制 * Worktree 配置需要 git 存储库，并且可能会因分支/路径冲突而失败 * 发送键交互在负载下可能对时间敏感 * 先前运行中陈旧的玻璃可能会造成干扰，直到手动清洁为止 ## 场景示例 **好：** 在工作流程已经有了明确的下一步之后，用户说“继续”。继续当前的工作分支，而不是重新启动或重新提出相同的问题。 **好：** 用户仅更改输出形状或下游交付步骤（例如“制作 PR”）。保留早期不冲突的工作流程约束并在本地应用更新。 **不好：** 用户说“继续”，工作流程会重新启动发现或在收集缺少的验证/证据之前停止。

团队

包含技能