메뉴
Agent Teams 協作派發指南。Use when: (1) Agent A 的發現會改變 Agent B 正在進行的工作, (2) 用戶要求使用 team/swarm, (3) 多代理人需即時協商共用介面或 API 契約。涵蓋 team 建立、Ticket-Task 橋接、teammate 入職、生命週期管理。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | agent-team |
| description | Agent Teams 協作派發指南。Use when: (1) Agent A 的發現會改變 Agent B 正在進行的工作, (2) 用戶要求使用 team/swarm, (3) 多代理人需即時協商共用介面或 API 契約。涵蓋 team 建立、Ticket-Task 橋接、teammate 入職、生命週期管理。 |
Agent Teams 是 Claude Code 的實驗性功能，允許多個 Claude 實例組成團隊、共享任務清單、即時通訊。本 Skill 指導 PM 在使用 Agent Teams 時如何讓 teammates 遵循 Ticket 規範。
定位：Agent Teams 是混合模式中的一個選項，不取代現有 Task subagent。
核心判斷：「Agent A 的發現會改變 Agent B 正在進行的工作嗎？」
| 具體情境 | 判斷理由 |
|---|---|
| 獨立模組各自實作（Widget/Repository/Controller） | 各自獨立，無交互需求 |
| 批量重命名/導入路徑修正/格式化 | 純機械操作 |
| 多視角分析（各視角獨立產出報告） | 各報告不互相依賴，PM 事後彙整 |
| 多來源外部研究（各來源獨立） | 各自查詢不同網站，結論不互相依賴 |
| 測試失敗分析（單一明確原因） | incident-responder 單一代理人足夠 |
| 標準 TDD Phase 開發 | Phase 順序天然序列 |
| 具體情境 | 判斷理由 |
|---|---|
| 跨模組測試失敗（大量失敗、原因不明） | 一個代理人的發現會改變另一個的調查方向 |
| 前後端同時開發共用 API | API 契約需雙方即時協商 |
| 元件 + ViewModel 共同設計介面邊界 | 介面契約在工作中定義，非預先確定 |
| 架構審查 + 安全審查（涉及認證/授權） | SA 架構發現可能改變安全評估範圍 |
| 多來源研究（結論相互依賴） | 一個來源的發現影響另一個的查詢策略 |
| 除錯：多假設平行測試（原因不明） | 一個假設被否定後要即時通知其他代理人調整方向 |
| QA 批量測試（多 URL/多頁面/多端點驗證） | 純平行加速，社群驗證有效 |
| 大型重構：多模組同時修改共用介面 | 共用介面變更需即時同步，避免衝突 |
| 狀況 | 推薦方式 | 理由 |
|---|---|---|
| 各視角獨立產出，PM 事後彙整 | Task subagent | 現有方法論標準流程 |
| 一個視角的發現會改變另一視角方向 | Agent Teams | 需即時調整分析範圍 |
成本提醒：Agent Teams 約 3-4 倍 Token 成本。僅在「Agent A 的發現會改變 Agent B 正在進行的工作」時使用。
5 個階段：
| 階段 | 名稱 | 執行者 | 核心動作 |
|---|---|---|---|
| 1 | Plan | PM | 確認 Ticket、設計任務分解、並行安全檢查 |
| 2 | Create | PM | TeamCreate → TaskCreate → spawn teammates |
| 3 | Coordinate | Team | Teammates 認領 Task + claim Ticket、PM 監控 |
| 4 | Converge | PM | 收集結果、驗證驗收條件、派發 auditor |
| 5 | Shutdown | PM | SendMessage shutdown → TeamDelete → ticket complete |
詳細操作指引：references/team-lifecycle.md
核心原則：Ticket 是 Source of Truth，Task 是 ephemeral 協調層。
| 原則 | 說明 |
|---|---|
| Ticket 持久化 | Ticket .md 檔案跨 session 存在 |
| Task 臨時性 | Agent Teams Task List 隨 session 消失 |
| 映射關係 | 每個 Task 必須關聯一個 Ticket |
| 更新責任 | Teammate 負責更新 Ticket 進度日誌 |
| Complete 權限 | 只有 PM 可以 ticket track complete |
詳細規則：references/ticket-task-bridge.md
PM 在 spawn teammate 時，必須提供入職指令，包含：
| 項目 | 說明 |
|---|---|
| 身份識別 | team name、role、assigned ticket |
| Ticket 操作 | claim、append-log、禁止 complete |
| 通訊協定 | SendMessage 目標、阻塞升級 |
| 品質標準 | implementation-quality.md、FLUTTER.md |
完整模板：references/teammate-onboarding-protocol.md
若 team 協作失敗：
停用方式：刪除 .claude/skills/agent-team/ 即完全停用。
用戶說：「30 個測試同時失敗，原因不明，涉及 3 個模組」
判斷：一個代理人的發現（如「根因在共用的 EventBus」）會改變其他代理人的調查方向 → Agent Teams
動作：
用戶說：「分析這個 PR 的架構影響和安全風險」
判斷：架構分析和安全分析各自獨立產出報告，PM 事後彙整 → Task subagent
動作：
以下經驗來自社群實際使用回饋（Anthropic Engineering Blog, Addy Osmani, claudefa.st）：
| 實踐 | 說明 |
|---|---|
| Plan First, Then Swarm | 先用 Plan Mode 定義任務分解，再啟動 Team。避免 team 在模糊目標下浪費 token |
| 明確檔案所有權 | spawn 時指定每個 teammate 負責的檔案/目錄，避免衝突 |
| CLAUDE.md 作為共享契約 | 每個 teammate 都會載入 CLAUDE.md，利用此機制傳遞共享規範 |
| Delegate Mode | team-lead 用 Shift+Tab 進入委派模式（僅協調，不實作），降低 token 消耗 |
Last Updated: 2026-02-25 Version: 1.2.0
Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, logs, prompts, schema/ticket fields, and long-form technical articles. Use when cognitive load and token cost matter. Triggers: 寫註解, 寫文件, 寫日誌, 寫 prompt, 寫文章, 技術文章, post-mortem, 架構決策, 除錯復盤, 欄位設計, atomic, reusable.
Branch Worktree Guardian - Git 分支和 Worktree 管理工具。Use for: (1) 新開發需求時建立隔離分支, (2) 使用 worktree 機制避免分支衝突, (3) 驗證當前工作分支正確性, (4) 預防在錯誤分支上開發
broken-link 偵測工具。掃描 .claude/ 目錄所有 Markdown 文件中的路徑引用，偵測失效連結。Use for: (1) 一次性掃描所有 broken links, (2) 搭配 /loop 定期監控, (3) 修改規則/方法論/代理人文件後驗證路徑完整性。Use when: user runs /broken-link-check, 或搭配 /loop 定期執行, 或發現 broken link 錯誤後。
子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket，各由 Agent 獨立執行，結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務
認知負擔評估與審查工具。作為決策樹、代理人、Code Review 的基本參考標準。用於: (1) 任務複雜度評估, (2) 代理人升級判斷, (3) 任務拆分建議, (4) 程式碼品質審查與熱點識別
Extracts reusable patterns from Claude Code sessions and captures knowledge as atomic memory units, then evaluates whether each memory should be upgraded to framework-shared rules, methodologies, or error-patterns. Use when session ends (Stop hook), when recording technical decisions, implementation insights, or lessons learned. Handles automatic pattern detection, structured memory capture with interconnected knowledge links, and post-write upgrade decision flow to prevent cross-project principles being trapped in single-project memory.
