agent-team

把「多會話 = 多部門」的協作機制落到專案資料夾裡。它不是角色扮演，而是崗位制度：每個會話有固定職責、寫入邊界、收件箱、交接班和審核閘。

先守住的邊界

先有適合業務場景的專案地基，再搭協作層。預設目標目錄 = 當前工作目錄；若缺 docs/ 或缺清晰的目標/進度/交接文件，先判斷專案類型：網際網路產品 / Vibe Coding 才優先建議 vibe-project-foundation；其他業務場景優先使用已有專用業務地基 Skill 或現有檔案結構。若沒有合適地基，先問清目標業務、交付物、驗收標準、過程資源、風險/複核方式，再幫用戶創建一個最小業務地基，然後搭協作層。
三層必須齊全：管理層 / 執行層 / 審核層。最小盤是 lead,do,review；不要為了「多 Agent」硬拆部門。
創建 docs/collaboration/、新增/刪除/替換部門、首次創建部門會話、改變跨會話路由或通知模式前，必須先讓用戶確認；已登記為自動/人工的短喚醒按 部門表.md 執行，不每次重複確認。
不直接寫業務程式碼；本 skill 只做團隊診斷、協作層搭建、會話登記和協作規則維護。
已有 docs/collaboration/ 時不要覆蓋；先讀現狀，再判斷是增量加部門、登記會話、更新規則還是重建。
啟動前硬閘：不得從「幫我搭建團隊/部門」直接預設成網際網路產品開發。必須先確認專案最終交付物和會話創建模式，再推薦部門。

運行鐵律

這些規則必須寫進生成物，且後續派活都要遵守：

三類節點閘：每個功能 / 環節只推進一個驗收節點。部門完成節點後先回報統籌部；統籌部按三類判斷：產品感知/重大邊界節點必須請用戶確認，流程性/技術性節點可自主推進，可自主推進但影響專案可見性的節點必須用簡短節點卡匯報。
收件箱是真相源：任務詳情和回報寫對應部門 收件箱.md；每個部門會話在上崗/接班時只做一次通知能力登記，後續按登記的「自動/人工」模式執行。通知只表達三類狀態：有新任務 / 任務已完成 / 遇到阻斷。
完成回報四件套：產出路徑、驗證結果（含未驗證項）、日誌收據、錯題自檢。缺任一項，統籌部不能視為完成閉環。
統籌不吃長上下文：統籌部先讀自己的收件箱，只核日誌收據存在；只有回報不足、收據錯誤、部門結論衝突或用戶要求時，才讀最小必要正文。
審核層獨立不等於盲審充分：審核部門親自驗證，不繼承執行部門長上下文，不採信「已通過」轉述；但也不能只沿執行部門 happy path 重跑一遍。凡涉及用戶看到 / 提示 / 錯誤文案 / 進度 / 狀態 / 彈窗 / 結果摘要 / 匯出檔案名 / 打包態視窗，必須測到 worker / UI / 用戶最終出口；只測 engine/API/helper 層不算通過。每個關鍵風險至少設計一個反向探針。
派單必須寫驗收出口和必測失敗路徑：統籌派單必須寫清 驗收出口 和 必測失敗路徑。驗收出口指用戶最終在哪裡看到結果 / 提示 / 錯誤 / 狀態 / 彈窗 / 結果摘要 / 匯出檔案名 / 打包態視窗；凡涉及用戶可見內容，不得只寫 engine/API/helper 層。必測失敗路徑至少列 1-3 個打破 happy path 的失敗、異常或邊界場景。缺失時接收部門回統籌補齊，不得自行腦補。
體驗先於測試：可運行功能先給用戶體驗；進入「需要用戶體驗 App」的節點時，統籌部預設直接幫用戶打開 App，不先問「要不要打開」，然後給一張短體驗卡。用戶明確確認「體驗 OK / 可以進測試」後，測試部才做專業品質關。
設計意圖必須可視化：凡涉及 UI、互動、視覺呈現、頁面佈局、設計稿、用戶體驗路徑的節點，設計部不能只交文字說明、ASCII 線框、Markdown 表格或抽象結論；必須提供用戶可直接判斷的設計意圖預覽。設計預覽不得聲稱等同真實 App UI；真實 UI 驗收以運行中的 App / 真實路由 / 構建或打包態截圖為準。
設計確認獨立於功能確認：用戶確認功能方向 OK 不等於視覺 / 互動通過。用戶確認設計視覺或互動方向前，統籌部不得派開發部正式實現；最多只能推進功能可行性或技術評估。
盲審/抽檢按觸發介入：同一功能鏈連續多輪無阻斷通過（預設 3 輪，可解釋調整）、鏈路跨 engine→worker→UI→用戶出口、涉及錯誤文案/狀態/發布/打包/安全/費用等高風險，或用戶/統籌覺得結論依據不足時，觸發子 Agent 盲審/抽檢。子 Agent 只回報盲審/抽檢結論，不直接改程式碼、不自動放行。
風險/成本按觸發介入：安全部只在大階段、上線/外發前或隱私、權限、金鑰、授權、第三方平台、生產配置等風險出現時介入；財務部只在成本節點介入，只預警上報不卡死發布。
放行由用戶拍板：審核層三關通過後，統籌部只給放行建議；標記完成、對外發布、付費等由用戶確認。
路由口訣：澄清類（不改產物、不裁決、不推進狀態）直連對方收件箱；要改 / 要裁決 / 要變狀態 / 要放行 / 要增刪部門，經統籌部。
測試不分流：用戶已體驗 OK 後進入測試，若測試部發現純程式碼 / 品質 / 異常路徑問題，測試部回寫統籌部，統籌部先用節點卡向用戶同步，隨後可自主派開發部返工；只有涉及體驗取捨、範圍變化、成本/安全/發布、方案選擇或重大事項時才停下等用戶確認。

統籌部三類節點決策

統籌部的判斷原則：

用戶負責產品體驗、功能取捨、設計判斷和重大風險拍板；統籌部負責技術流程、部門排程、常規品質關和無爭議推進。自主推進必須保留簡短匯報，遇到產品感知或重大邊界變化必須停下確認。

A. 必須用戶確認

凡是影響產品體驗、用戶感知、功能取捨、介面設計、互動流程、視覺呈現、MVP 邊界、產品路線、上線發布、外發交付、成本明顯增加、隱私/安全/雲端/金鑰/授權風險的節點，統籌部必須停下來讓用戶確認。

典型情況：

功能做完後，需要用戶上手體驗。
UI / 互動 / 設計稿完成後，需要給用戶看可視化預覽。
設計部產出只包含文字說明、ASCII 線框、Markdown 表格或抽象結論時，不得視為完成設計節點。
用戶只確認功能方向 OK、但未確認視覺 / 互動方向時，不得進入正式開發實現。
功能要新增、刪除、後置、改變範圍時，需要用戶判斷。
測試通過後是否正式收口、是否進入下一大階段，需要用戶確認。
涉及雲端、上傳、API Key、聯網下載、費用、打包體積明顯變化時，需要用戶確認。

B. 統籌可以自主推進

凡是用戶不適合判斷、且不改變產品體驗和重大邊界的流程性 / 技術性節點，統籌部可以按專業判斷推進，不必反覆詢問。

典型情況：

產品邊界確認後，派設計部做最小互動草案。
設計草案完成後，派開發部做實現評估。
設計視覺 / 互動已由用戶確認，且技術評估結論清楚、風險可控時，派開發部進入正式實現；UI 未確認前只能推進來實現評估 / 技術可行性。
用戶體驗 OK 後，派測試部做品質關。
測試部在用戶已體驗 OK 後發現純程式碼 / 品質 / 異常路徑問題，統籌部節點卡同步後派開發部返工。
測試無 P0/P1/P2 阻斷時，統籌部可以建議通過並進入收口確認。
日誌、交接、共享錯題集、進度記錄、輕量驗證、用戶確認收口後的 commit 存檔等常規動作。

C. 可以自主推進但必須匯報

這類不需要用戶拍板，但統籌部要用簡短節點卡告訴用戶「我已經推進到哪一步」。

節點卡示例：

「開發評估完成，但 UI 未確認，我只派開發做技術可行性評估。」
「設計視覺 / 互動已確認且開發評估風險可控，已派開發正式實現。」
「你體驗 OK 後，我已派測試部做品質關。」
「測試發現程式碼層問題，不涉及產品取捨；我已派開發部返工。」
「測試無阻斷，我準備收口存檔。」
「安全/財務本節點未觸發，所以未介入。」

驗收出口、失敗路徑與盲審抽檢

統籌派單必須把「驗收看哪裡」和「怎麼打破 happy path」寫進任務，不能只寫一個抽象驗收目標。

派單必填：

驗收出口：用戶最終在哪裡看到結果 / 提示 / 錯誤 / 狀態 / 彈窗 / 結果摘要 / 匯出檔案名 / 打包態視窗。凡涉及用戶可見內容，不得只寫 engine / API / helper 層。
必測失敗路徑：至少 1-3 個失敗、異常或邊界場景，用於打破 happy path。

缺任一項時，接收部門應回統籌部補齊，不得自行腦補。

審核 / 測試報告必填：

驗證層級：engine / adapter-service / worker-背景任務 / UI-用戶可見出口 / 打包態 / 未覆蓋層級。
用戶可見出口：實際測到的最終出口。
自設計反向探針：每個關鍵風險至少一個，說明如何證明不是只沿 happy path 重跑。
未覆蓋層級：沒有覆蓋的層級必須明寫，沒有則寫無。
是否觸發子 Agent 盲審 / 抽檢：寫觸發結論和依據。

審核層獨立不等於盲審充分。審核部門不能只沿執行部門 happy path 重跑一遍；凡是用戶看到 / 提示 / 錯誤文案 / 進度 / 狀態 / 彈窗 / 結果摘要 / 匯出檔案名 / 打包態視窗的驗收，必須測到 worker / UI / 用戶最終出口；只測底層不算通過。

盲審 / 抽檢觸發條件：

同一功能鏈連續多輪無阻斷通過，預設 3 輪，可按專案說明調整。
鏈路跨 engine→worker→UI→用戶出口。
涉及錯誤文案、狀態、發布 / 打包、安全、費用等高風險。
用戶或統籌感覺結論依據不足。

觸發後子 Agent 只做盲審 / 抽檢結論回報，不直接改程式碼、不自動放行。

測試不通過後的返工分流

用戶體驗 App 通過，只代表體驗流程、功能預期和用戶感知可進入專業測試；不代表程式碼品質、異常路徑、打包態、日誌、邊界條件已經通過。測試部若發現 P0/P1/P2 或其他品質問題，先寫審核報告和 [回報] 到統籌部收件箱。統籌部必須先用節點卡向用戶同步結論，然後按問題性質分流：

可自主派開發部返工：純程式碼 bug、異常路徑、錯誤文案、日誌、打包態、worker/UI 出口不一致、測試覆蓋缺口等專業品質問題；這些問題不要求用戶做程式碼判斷。
必須停下等用戶確認：需要改變產品體驗、功能範圍、設計方案、MVP 邊界、資料保留策略、成本、安全、隱私、發布方式，或存在多個修復方案且會犧牲體驗 / 範圍 / 成本 / 速度。

節點卡要寫清楚：測試結論、影響、返工原因、是否涉及用戶取捨、統籌判斷、下一步。自主返工只代表進入修復閉環，不代表最終放行；修復後仍回到用戶體驗 / 測試節點。

收口與 commit 存檔

交班不等於 git commit。部門完成節點時先更新交接班、日誌、收件箱回報和必要產出；commit 是用戶確認正式收口後的版本庫歸檔動作。

測試無 P0/P1/P2 阻斷、風險/成本關無阻斷時，統籌部可以給出放行建議並請求用戶確認正式收口。用戶確認後，統籌部應執行：

運行 git status --short。
若工作區只有本節點相關變更，執行 commit 存檔。
若存在無關變更、用戶未確認變更或無法判斷歸屬，先向用戶說明，不要混提交。
若專案不是 git 倉庫，說明無法 commit，只完成協作層收口記錄。

commit 存檔不代表對外發布；發布、外發、付費、上線仍由用戶拍板。

App 體驗節點

進入「需要用戶體驗 App」的節點時，統籌部預設直接幫用戶打開 App，不先問「要不要打開」。如果當前環境能啟動 / 打開 App，就直接執行；如果啟動失敗，說明失敗原因、已嘗試命令和用戶可手動打開的入口。

體驗卡標準：

入口:
重點:
建議試法:
判斷口徑:

體驗卡要求：

入口：告訴用戶從哪裡進，如「配音/克隆音 → IndexTTS2 情感配音 → 情感強度」。
重點：告訴用戶這次主要看什麼，只放 1-2 個重點。
建議試法：給 2-4 個具體操作，讓用戶不用自己想怎麼測。
判斷口徑：告訴用戶只需要回覆「體驗 OK」或指出哪裡不順。

示例：

入口:配音/克隆音 → IndexTTS2 情感配音 → 情感強度
重點:聽三檔差異是否明顯、自然。
建議試法:
- 試 開心 + 克制 / 標準 / 鮮明。
- 試 活力口播 是否預設帶入 開心 + 鮮明。
- 切到 自然 看是否固定標準並提示。
判斷口徑:你覺得好用就說「體驗 OK」，不順就告訴我具體點。

設計可視化確認節點

凡涉及 UI、互動、視覺呈現、頁面佈局、設計稿、用戶體驗路徑的節點，設計部必須交付用戶可以直接判斷的設計意圖預覽，不能只交文字說明、ASCII 線框、Markdown 表格或抽象結論。設計意圖預覽用於判斷方向、佈局、資訊層級和互動感覺，不得聲稱等同真實 App UI。

真實 UI 驗收必須來自運行中的 App、真實路由、構建產物或打包態截圖。設計部的 OpenDesign / Figma / HTML mock / PNG 只能作為設計意圖依據；開發部實現後必須標註與設計意圖的差異，測試部用真實 App 介面檢查是否偏離。

設計部交付優先級：

優先使用 OpenDesign 等專用設計工具生成可編輯設計產物或 artifact。
如果當前會話未熱載入 OpenDesign MCP、OpenDesign 沒有 active project、權限不足、工具連接失敗，設計部必須在回報裡明確失敗原因。
工具不可用時，必須用本地 HTML + PNG 截圖、Figma、可打開圖片預覽等方式兜底，保證用戶看到設計意圖，但不得承諾這就是最終真實 UI。
如果用戶不想安裝、啟動、授權、註冊或修復 OpenDesign，或不願意為當前會話重載 / 新開會話，設計部不得卡住，應按用戶偏好直接選擇本地 HTML + PNG、Figma 或可打開圖片預覽。

設計部完成回報四件套中的「產出路徑」必須同時包含：

設計說明文件路徑。
設計意圖預覽路徑，如 OpenDesign artifact 連結 / 本地 HTML / PNG 截圖 / Figma 連結 / 可打開圖片。
若使用兜底方案，必須寫清 OpenDesign 當前狀態和後續恢復條件。

OpenDesign 接入規則：

先確認本機 OpenDesign App 是否運行，再確認 daemon 健康狀態。
不要假設預設連接埠一定是 7456；應從 OpenDesign 日誌或本機監聽連接埠確認實際 daemon URL。
確認後將 open-design MCP 註冊到 Codex；當前會話可能無法熱載入新 MCP，必要時提示用戶重載 / 新開會話。
若 OpenDesign artifact 寫入提示沒有 active project，要求用戶在 OpenDesign 內創建或點進專案，或直接使用本地 HTML / PNG 兜底交付，不能卡住節點。
若發現未安裝 / 未運行 OpenDesign、權限不足、連接失敗或 MCP 未熱載入，設計部必須主動詢問用戶是否需要幫忙安裝 / 啟動 / 授權 / 註冊 MCP / 重載或新開會話；用戶不處理時立即走兜底可視化方案。
最小排障順序：查 App 是否運行 → 查監聽連接埠或日誌裡的 daemon URL → 查 MCP 是否已註冊 / 當前會話是否已熱載入 → 查 active project → 查權限 / 連接錯誤；任一步失敗都同時給兜底預覽方案。
OpenDesign 只是增強設計表達和可視化確認能力，不代表自動擴大為完整 UI 重設計、品牌升級或開發實現。

統籌部收到設計回報後：

先展示設計意圖預覽，再給用戶一張簡短節點卡。
節點卡建議結構：成果 / 判斷點 / 建議 / 風險 / 下一步。
不要把長技術說明或設計正文直接丟給用戶判斷。
用戶確認設計視覺或互動方向前，不得派開發部進入正式實現；如果用戶只回饋功能方向 OK 但 UI 未確認，只能推進功能可行性或技術評估。
開發完成後的 UI 通過判斷，不得繼續引用設計意圖預覽代替真實介面；必須回到真實 App / 真實路由 / 構建或打包態截圖。

自主推進停止條件

統籌自主推進不等於無限連續推進。可以連續推進流程性節點，但遇到以下情況必須停下問用戶：

結論有明顯不確定。
部門之間判斷衝突。
需要犧牲體驗、範圍、成本、速度中的任一項。
要新增依賴、雲端、聯網、模型、成本。
要改變用戶之前確認過的產品方向。
要進入可運行功能體驗、UI 視覺確認、發布/打包/外發、大階段收口。

診斷流程

如果用戶已經說清專案類型、交付物和會話創建模式，直接診斷；不要重複問。資訊不足時一次只問一個關鍵問題。

第一問：

這個專案最終要交付的東西是什麼：可運行軟體、內容/課程、運營結果、調研方案、自動化流程、線下交付，還是其他？

第二問：

這次會話部門怎麼創建：由當前 Codex 這類有會話管理工具的 Agent 自動創建，還是你會先手動創建好各部門會話視窗，我只負責生成部門檔案和上崗引導？

第一問沒有答清前，不得推薦 product/design/dev/test 軟體常見盤。第二問沒有答清前，不得聲稱已經創建部門會話。若專案缺少地基檔案，還要先判斷是否已有適用的場景地基 Skill；沒有時再創建通用最小業務地基，不要把所有專案都導向 vibe-project-foundation。

診斷時固定三層，只判斷執行層拆幾個、審核層開幾關：

觸發維度	命中則影響	部門
軟體 / 網際網路產品 / Vibe Coding / 有可運行產物	啟用軟體盤	`product/design/dev/test`
UI/互動/視覺重	強化設計	`design`
資料收集、用戶/市場/競品/事實核驗重	加研究	`research`
方案、流程、排期、資源配置重	加策劃	`planning`
資料採集/清洗/匯入匯出/準確性重	加資料	`data`
批次處理、定時、跨平台自動執行	加自動化	`auto`
文案/圖片/影片/報告持續生產	加內容	`content`
增長、轉化、留存、商業化運營	增長運營	`growth`
帳號、登入、隱私、合規、第三方平台、金鑰、生產配置	開風險關	`security`
預算、成本敏感、付費項	開成本關	`finance`
複雜功能、需要 bug/異常覆蓋	獨立品質關	`test` 或 `review`
都不強烈	通用最小盤	`lead,do,review`

非軟體專案不要硬套產品/設計/開發/測試；先按交付物、驗收標準、過程資源、風險和複核方式判斷。無法歸類時用 lead,do,review，再按風險補 research/planning/content/data/auto/security/finance。

地基選擇

協作層依賴「能讓部門讀懂目標和邊界」的專案地基，但地基不等於固定的軟體目錄。

處理順序：

先看專案裡是否已有可用地基：如 docs/、業務方案、專案說明、交付清單、進度/交接文件、行業專用目錄。已有時按現有地基規劃部門職責和可寫範圍，不要強行改成軟體結構。
若是網際網路產品、軟體、Vibe Coding 或明確有 app/ design/ docs/spec.md 這類產物，才優先建議或使用 vibe-project-foundation。
若是課程、內容、運營、諮詢、線下交付、調研、內部流程等非軟體專案，先找是否有對應專用業務地基 Skill 或現有範本；有就使用它。
若沒有專用地基，不要停在「請先裝某個軟體地基」。先問清目標業務、最終交付物、驗收標準、過程資源、風險/複核方式，然後創建最小業務地基。

最小業務地基只包含能支撐協作的通用文件：

docs/overview.md：專案目標、交付物、服務對象/使用對象、邊界。
docs/progress.md：當前階段、已完成、進行中、下一步。
docs/agent-guide.md：本專案協作規則、文件分工、注意事項。
必要時按業務創建 deliverables/、materials/、research/、operations/、scratch/ 等目錄；不要創建無關的軟體目錄。

推薦團隊時給出：

三層各有哪些部門，以及命中依據。
每個部門的職責、禁止事項、輸入、輸出、可寫範圍、禁止寫入範圍。
跨部門路由：澄清直連還是經統籌。
哪些節點必須用戶確認。
會話創建模式：自動創建會話 或 手動創建會話視窗，以及對應執行步驟。

創建前停下確認：

我建議按以上團隊配置創建 docs/collaboration/，會話模式為【自動創建 / 手動創建】。你確認嗎？

創建協作層

確認後運行腳本。若沒有專用地基且用戶確認由本 Skill 補最小業務地基，加 --create-minimal-foundation --allow-without-foundation。預設通用最小盤：

python3 <skill目錄>/scripts/scaffold_team.py "<目標專案目錄>" \
  --profile "<團隊診斷摘要>" \
  --session-mode "manual"

按診斷展開時顯式傳角色：

python3 <skill目錄>/scripts/scaffold_team.py "<目標專案目錄>" \
  --profile "軟體 + 資料強 + 涉隱私/平台 + 有預算" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

可選角色：

管理層：lead
執行層：do/research/planning/product/design/dev/data/auto/content/growth
審核層：review/test/security/finance

腳本會創建 docs/collaboration/README.md、部門表.md、會話啟動清單.md、讀取路由規則.md、錯題集.md、任務交接範本.md、專項結論/、scripts/agent_team_read.py 和 部門/<部門名>/ 下的 崗位說明.md、上崗引導.md、交接班文件.md、收件箱.md、報告/、日誌/<ISO週>.md；審核層另有相容舊名的 把關報告/（語意為審核報告）。腳本拒絕覆蓋已有協作層，拒絕重複角色，拒絕缺少管理層/執行層/審核層的全新團隊；未傳 --session-mode auto/manual 時會中止，防止繞過會話模式確認。

會話創建模式

自動創建會話（Codex / 有會話管理工具）

用戶確認採用自動模式後：

先運行腳本創建 docs/collaboration/。
用 tool_search 搜尋 create_thread、send_message_to_thread、set_thread_title 三類會話工具；置頂、排序不是必要能力。
工具可用時，為每個部門創建一個會話；標題建議用數字前綴保持順序，如 01 統籌部、02 產品部、03 開發部。
把每個部門的 上崗引導.md 作為初始化訊息發給對應會話，要求該會話先接班，只匯報職責 / 階段 / 進行中 / 收件箱 / 待確認問題，不要立刻做業務任務。
把返回的會話 ID 寫入 docs/collaboration/部門表.md，並把通知模式登記為 自動。若發送工具失敗，本部通知模式改為 人工，並向用戶說明沒有完成自動建會話。
最後向用戶匯報：已創建哪些會話、哪些會話 ID 已登記、哪些需要用戶手動處理。

如果工具不可用或調用失敗，不得說「已創建會話」；改為手動模式收尾。

手動創建會話視窗（其他 Agent / 無會話管理工具）

用戶確認採用手動模式後：

只運行腳本創建 docs/collaboration/ 和各部門文件。
不調用會話工具，不聲稱創建了會話。
輸出手動上崗清單：每個部門對應的 上崗引導.md 路徑、建議視窗名、需要用戶貼給該會話的第一句話。
docs/collaboration/部門表.md 的會話 ID 保持 待登記，通知模式保持 待登記 或按用戶說明改為 人工。
用戶手動創建好視窗後，把各部門 上崗引導.md 發給對應會話；部門會話先運行 docs/collaboration/scripts/agent_team_read.py onboard --dept 【部門名】，再按腳本返回的必讀文件讀取崗位說明、交接班、錯題集、收件箱，之後所有交接都寫對應部門資料夾的 收件箱.md。

創建後檢查：

docs/collaboration/ 結構完整，三層至少各一個部門。
docs/agent-guide.md 已追加多會話協作說明。
docs/collaboration/會話啟動清單.md 已寫明自動/手動模式和每個部門的上崗入口。
自動模式下，部門表.md 已登記實際會話 ID 和通知模式；手動模式下，已明確提示用戶會話尚未創建。
docs/progress.md 記錄協作層創建、團隊配置摘要、下一步。
git status --short；若只有本次協作層相關變更，可單獨提交：

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: 搭建多會話協作層"

若倉庫已有其他未提交變更，不要混提交，向用戶說明。

維護模式

後續可能要新增/合併/刪除部門、替換會話、登記會話 ID、調整邊界、派活或獨立把關。處理原則：

先讀 docs/collaboration/部門表.md，確認現有三層和部門。
判斷是否破壞「三層至少各一個」或職責邊界。
涉及新增/刪除/替換部門、跨會話訊息、放行、返工、狀態升級，先讓用戶確認。
加部門用 scaffold_team.py <專案> --add-roles "<ids>"；腳本只補建缺失部門並追加部門表，仍需人工同步受影響流轉規則。
減/合併部門時，先把在辦事項和歷史交代進日誌，再更新部門表和相關崗位說明；不要直接刪歷史。
通知能力登記只在上崗/接班時做一次：
- 讀 部門表.md 的本部門「通知模式」。若已登記為 自動 或 人工，本會話後續都按該模式執行，不要每次任務完成都重新探測工具。
- 若通知模式是 待登記，有 tool_search 時搜尋 send_message_to_thread 等發送工具；沒有 tool_search 或搜不到發送工具，登記為 人工。
- 自動：後續通知預設直接調用會話發送工具發短喚醒，不再預先做能力檢查。
- 人工：後續通知預設直接給用戶可複製的短喚醒，請用戶手動提醒目標部門。
- 若自動模式實際調用失敗，本次回退為人工提醒，並請用戶通知統籌部更新 部門表.md。
- 若用戶發現 Agent 工具能力變化，讓用戶告知統籌部會話，由統籌部更新 部門表.md 的通知模式。
讀取路由優先：
- 新部門會話或接班優先運行 python3 docs/collaboration/scripts/agent_team_read.py onboard --dept 【部門名】，讓腳本返回本部身份、通知模式、必讀文件和預設讀取邊界。
- 報告、審核報告、專項結論、關鍵決策都用 YAML frontmatter 寫 type / department / target / status / date / related_task / decision / tags / summary；腳本只返回這些人工預寫欄位，不做創造性總結。
- 查證據前優先運行 agent_team_read.py find --type audit_report --status blocked、agent_team_read.py find --type special_conclusion --tag 用戶可見出口 或 agent_team_read.py meta <path>；只有摘要不足、路徑異常、結論衝突、涉及放行/返工/安全/費用/發布/用戶可見品質、用戶要求查證據、當前任務明確依賴正文時，才讀取最小必要正文。

AidenXu-1/agent-team-skill

agent-team-skill 是什麼？

在你喜歡的 AI 中提問

說明文件