团队协作

团队技能

使用 Claude Code 的隐式代理团队，生成 N 个协调的代理在共享任务列表上协同工作。Claude Code 2.1.178+ 移除了原生的 TeamCreate/TeamDelete 命令；当设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 时，每个会话拥有一个隐式团队，通过 Agent/Task 工具使用不同的 name 值直接生成团队成员。本技能仍然保留了 OMC 旧版 tmux/CLI 工作节点编排的文档（omc team / /omc-teams）。

swarm 兼容性别名已在 #1131 中被移除。

使用方法

/oh-my-claudecode:team N:agent-type "任务描述"
/oh-my-claudecode:team "任务描述"
/oh-my-claudecode:team ralph "任务描述"

参数

• N - 团队成员代理的数量（1-20）。可选；默认为基于任务分解自动调整大小。
• agent-type - 为 team-exec 阶段生成的 OMC 代理类型（例如 executor、debugger、designer、codex、gemini、antigravity）。可选；默认为阶段感知路由。使用 codex 可生成 Codex CLI 工作节点，使用 gemini 可生成 Gemini CLI 工作节点（企业/API-key 层级），或者使用 antigravity 可生成 Antigravity CLI (agy) 工作节点（Gemini CLI 的 Google 继任者；需要安装相应的 CLI）。请参阅下面的阶段代理路由。
• task - 需要分解并分配给团队成员的高级任务
• ralph - 可选修饰符。当存在时，将团队流水线封装在 Ralph 的持久化循环中（失败后重试，完成前进行架构师验证）。请参阅下面的团队 + Ralph 组合。

示例

/team 5:executor "修复项目中所有的 TypeScript 错误"
/team 3:debugger "修复 src/ 中的构建错误"
/team 4:designer "为所有页面组件实现响应式布局"
/team "重构 auth 模块并进行安全审查"
/team ralph "构建一个完整的用户管理 REST API"
# 使用 Codex CLI 工作节点 (需要: npm install -g @openai/codex)
/team 2:codex "审查架构并提出改进建议"
# 使用 Gemini CLI 工作节点 (需要: npm install -g @google/gemini-cli)
/team 2:gemini "重新设计 UI 组件"
# 使用 Antigravity CLI 工作节点 (需要: 按照 https://antigravity.google 安装)
/team 2:antigravity "重新设计 UI 组件"
# 混合使用：Codex 用于后端分析，Gemini/Antigravity 用于前端（使用 /oh-my-claudecode:ask 按任务委派）

架构

用户: "/team 3:executor 修复所有 TypeScript 错误"
              |
              v
      [团队协调器 (负责人)]
              |
              +-- 使用会话的隐式 Claude Code 团队
              |       -> 不调用 TeamCreate；负责人保持当前会话
              |
              +-- 分析并分解任务为子任务
              |       -> explore/architect 生成子任务列表
              |
              +-- 根据实施计划创建任务列表条目
              |       -> TODO/任务条目 #1, #2, #3 及其依赖关系
              |
              +-- 更新任务列表条目 (预分配负责人)
              |       -> 任务 #1 负责人=worker-1 等
              |
              +-- Task(name="worker-1") x 3
              |       -> 将团队成员生成到团队中
              |
              +-- 监控循环
              |       <- 团队成员消息 (由活跃的团队界面自动传递)
              |       -> task-list/TodoWrite 审查进度
              |       -> 通过活跃的团队界面给团队成员发送消息以解除阻塞/协调
              |
              +-- 完成
                      -> 通过活跃的团队界面请求每个团队成员关闭
                      <- 收到团队成员关闭确认
                      -> 清除 OMC 团队状态 (不调用 TeamDelete)
                      -> rm .omc/state/team-state.json

原生 Claude Code 团队模型 (2.1.178+):

- 本技能不会创建每个团队的 ~/.claude/teams/<name>/ 目录。
- TeamCreate/TeamDelete 命令不可用。
- `team_name` 仅作为被忽略的遗留元数据被原生 Claude Code 接受；不要依赖它进行路由。
- 直接通过 Agent/Task 使用 `name="worker-N"` 生成团队成员。

目标工作流关系

团队是 OMC 中并行、分阶段执行的权威。使用确定性冲突策略 refuse、adopt_existing 和 artifact_only，而不是非确定性的警告处理。如果任务提到 Claude Code /goal、Ralph 或仅专注于产物的 Ultragoal，则保持团队作为主要的循环权威，除非负责人明确移交。仅将 /goal 用作记录在案的原生 Claude Code 移交目标，或作为负责人会话中的可见证据；不要声称 /goal 评估器独立运行命令、读取文件或取代 team-verify / team-fix。仅专注于产物的 Ultragoal 引用应被视为持久的任务账本/检查点/证据产物，而不是工作节点本身的执行。

分阶段流水线 (规范团队运行时)

团队执行遵循分阶段流水线：

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (循环)

阶段代理路由

每个流水线阶段使用专门的代理——而不仅仅是执行器。负责人根据阶段和任务特征选择代理。

阶段	必需代理	可选代理	选择标准
team-plan	explore (haiku), planner (opus)	analyst (opus), architect (opus)	对于不明确的需求使用 analyst。对于边界复杂的系统使用 architect。
team-prd	analyst (opus)	critic (opus)	使用 critic 来挑战范围。
team-exec	executor (sonnet)	executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)	根据子任务类型匹配代理。对于复杂的自主工作使用 executor (model=opus)，UI 工作使用 designer，编译问题使用 debugger，文档使用 writer，测试创建使用 test-engineer。
team-verify	verifier (sonnet)	test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)	始终运行 verifier。对于认证/加密相关的更改，添加 security-reviewer。对于超过 20 个文件或架构更改，添加 code-reviewer。code-reviewer 也涵盖风格/格式检查。
team-fix	executor (sonnet)	debugger (sonnet), executor (opus)	使用 debugger 处理类型/构建错误和回归隔离。使用 executor (model=opus) 处理复杂的多文件修复。

路由规则:

1. 负责人按阶段选择代理，而不是用户。 用户的 N:agent-type 参数仅覆盖 team-exec 阶段的工作节点类型。所有其他阶段使用适合该阶段的专家。
2. 专家代理补充执行代理。 分析/审查路由给架构师/批评家 Claude 代理，UI 工作路由给设计师代理。Tmux CLI 工作节点是一次性的，不参与团队通信。
3. 成本模式影响模型层级。 在降级模式下：将 opus 代理降级为 sonnet，sonnet 在质量允许的情况下降级为 haiku。team-verify 始终至少使用 sonnet。
4. 风险等级升级审查。 安全敏感或超过 20 个文件的更改必须在 team-verify 中包含 security-reviewer + code-reviewer (opus)。

阶段进入/退出标准

• team-plan
  • 进入：团队调用被解析，编排开始。
  • 代理：explore 扫描代码库，planner 创建任务图，复杂任务可选择使用 analyst/architect。
  • 退出：分解完成，准备就绪可运行的任务图。
• team-prd
  • 进入：范围不明确或缺少验收标准。
  • 代理：analyst 提取需求，可选择使用 critic。
  • 退出：验收标准和边界明确。
• team-exec
  • 进入：任务列表分配和工作节点生成完成。
  • 代理：根据子任务类型生成相应专家类型的工作节点（参见路由表）。
  • 退出：执行任务在当前轮次达到终端状态。
• team-verify
  • 进入：执行轮次完成。
  • 代理：verifier + 适合任务的审查员（参见路由表）。
  • 退出（通过）：验证关卡通过，无需后续跟进。
  • 退出（失败）：生成修复任务，控制权转移到 team-fix。
• team-fix
  • 进入：验证发现缺陷/回归/不完整标准。
  • 代理：根据缺陷类型使用 executor/debugger。
  • 退出：修复完成，流程返回 team-exec 然后 team-verify。

验证/修复循环与停止条件

继续 team-exec -> team-verify -> team-fix 循环直到：

1. 验证通过且没有必须的修复任务剩余，或者
2. 工作达到具有证据的显式终端阻塞/失败结果。

team-fix 具有最大尝试次数限制。如果修复尝试超过配置的限制，则转变为终端状态 failed（避免无限循环）。

阶段交接约定

在阶段之间转换时，重要的上下文——做出的决策、被拒绝的替代方案、已识别的风险——仅存在于负责人的对话历史中。如果负责人的上下文被压缩或代理重启，这些知识将丢失。

每个即将完成的阶段必须在转换前生成一个交接文档。

负责人将交接文档写入 .omc/handoffs/<stage-name>.md。

交接文档格式

## 交接: <当前阶段> → <下一阶段>

- **已决策**: [本阶段做出的关键决策]
- **已拒绝**: [曾经考虑过但已被拒绝的替代方案]
- **风险**: [为下一阶段识别的风险]
- **文件**: [已创建或修改的关键文件]
- **待办**: [留给下一阶段处理的事项]

交接规则

1. 负责人在生成下一阶段代理之前先读取之前的交接文档。 交接文档的内容被包含在下一阶段的代理生成提示中，确保代理从一开始就拥有完整的上下文。
2. 交接文档会累积。 验证阶段可以读取所有先前的交接文档（plan → prd → exec）以获取完整的决策历史。
3. 团队取消时，交接文档会保留在 .omc/handoffs/ 中，用于会话恢复。原生 Claude Code 团队清理不会删除它们；在 Claude Code 2.1.178+ 中不存在 TeamDelete 调用。
4. 交接文档应轻量。 最多 10-20 行。它们捕捉决策和理由，而不是完整的规范（这些规范存在于交付文件中，如 DESIGN.md）。

示例

## 交接: team-plan → team-exec

- **已决策**: 采用包含 3 个服务（auth、api、worker）的微服务架构。使用 PostgreSQL 进行持久化。使用 JWT 进行认证令牌管理。
- **已拒绝**: 单体架构（扩展性问题）、MongoDB（团队专长是 SQL）、会话 cookie（API 优先设计）。
- **风险**: Worker 服务需要使用 Redis 作为任务队列——尚未配置。Auth 服务在初始设计中未包含速率限制。
- **文件**: DESIGN.md, TEST_STRATEGY.md
- **待办**: 数据库迁移脚本、CI/CD 流水线配置、Redis 配置。

恢复与取消语义

• 恢复: 从最后一个非终端阶段开始，使用阶段状态 + 实时任务状态。读取 .omc/handoffs/ 以恢复阶段过渡上下文。
• 取消: /oh-my-claudecode:cancel 请求团队成员关闭，等待响应（尽力而为），将阶段标记为 cancelled 并设置 active=false，捕获取消元数据，然后删除团队资源并根据策略清除/保留团队状态。.omc/handoffs/ 中的交接文件被保留以用于可能的恢复。
• 终端状态为 complete、failed 和 cancelled。

Windows psmux tmux 兼容网关

在原生 Windows 上，不要在检查实际的 tmux 兼容二进制文件之前告诉用户 /team 需要 WSL 或 tmux 不可用。原生 psmux 会安装一个 tmux 兼容的命令（通常是 tmux / tmux.cmd），并且是一个受支持的团队多路复用器。

在 Windows 上阻止或回退之前：

1. 检查 tmux -V（或平台等效命令，例如 where tmux 后跟 tmux -V）。
2. 将成功执行 psmux 支持的 tmux -V 视为 tmux 可用。
3. 如果 psmux/tmux 可用，则继续正常的团队流程；不要发出需要 WSL 的指导。
4. 仅当没有 tmux 兼容的二进制文件可用时，告诉用户安装 psmux 以支持原生 Windows，或者使用 WSL2 作为替代方案。

工作流

阶段 1: 解析输入

• 提取 N（代理数量），验证范围为 1-20
• 提取 agent-type，验证其映射到已知的 OMC 子代理
• 提取 task 描述

阶段 2: 分析与分解

使用 explore 或 architect（通过 MCP 或代理）分析代码库并将任务分解为 N 个子任务：

• 每个子任务应限定在文件范围或模块范围以避免冲突
• 子任务必须独立或具有清晰的依赖顺序
• 每个子任务