團隊

團隊技能

使用 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 "task description"
/oh-my-claudecode:team "task description"
/oh-my-claudecode:team ralph "task description"

參數

• 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) 工作器（Google 的 Gemini CLI 後繼者；需要安裝相應的 CLI）。請參閱下方的階段代理路由。
• task - 要分解並分配給團隊成員的高階任務描述。
• ralph - 可選修飾詞。使用時，會將團隊流程包裝在 Ralph 的持久化迴圈中（失敗時重試，完成前需經架構師驗證）。請參閱下方的團隊 + Ralph 組合。

範例

/team 5:executor "fix all TypeScript errors across the project"
/team 3:debugger "fix build errors in src/"
/team 4:designer "implement responsive layouts for all page components"
/team "refactor the auth module with security review"
/team ralph "build a complete REST API for user management"
# 使用 Codex CLI 工作器（需要：npm install -g @openai/codex）
/team 2:codex "review architecture and suggest improvements"
# 使用 Gemini CLI 工作器（需要：npm install -g @google/gemini-cli）
/team 2:gemini "redesign the UI components"
# 使用 Antigravity CLI 工作器（需要：依照 https://antigravity.google 安裝）
/team 2:antigravity "redesign the UI components"
# 混合使用：Codex 處理後端分析，Gemini/Antigravity 處理前端（透過 /oh-my-claudecode:ask 為每個任務委派）

架構

使用者: "/team 3:executor fix all TypeScript errors"
              |
              v
      [團隊協調器 (主導)]
              |
              +-- 使用會話的隱含 Claude Code 團隊
              |       -> 不呼叫 TeamCreate；主導保留在當前會話
              |
              +-- 分析並將任務分解為子任務
              |       -> explore/architect 產生子任務列表
              |
              +-- 從實作計畫建立任務列表條目
              |       -> TODO/task 條目 #1, #2, #3，帶有依賴關係
              |
              +-- 更新任務列表條目（預先指派負責人）
              |       -> task #1 owner=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 或僅限 artifact 的 Ultragoal，除非主導者明確交接，否則請將團隊保留為主要的迴圈主體。僅將 /goal 用作已記錄的原生 Claude Code 交接目標，或作為主導會話的可見證據；不要聲稱 /goal 評估器會獨立執行命令、讀取檔案或取代 team-verify / team-fix。僅限 artifact 的 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. 專家代理補充執行代理。 將分析/審查工作路由給 architect/critic 等 Claude 代理，UI 工作則給 designer 代理。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-exec → team-verify

- **已決定**: 使用 3 個服務（auth、api、worker）的微服務架構。PostgreSQL 持久化。JWT 用於身份驗證令牌。
- **已否決**: 單體架構（擴展性問題）、MongoDB（團隊擅長 SQL）、Session 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 個子任務：

• 每個子任務應是檔案範圍或模組範圍，以避免衝突
• 子任務必須彼此獨立，或具有明確的依賴順序
• 每個子任務…

[為了簡潔，此處省略後續內容]