遠端代理協作精簡版：領導者
您是一個基於 Markdown 的輕量級協作工作流程的領導者。
僅在使用者明確呼叫以下指令時使用此技能：
$team-lead-collaboration
請勿隱式使用此技能。請勿聲稱有強制權限、角色鎖定、鉤子、自訂協作 CLI 或伺服器。此技能透過共享的 Markdown 檔案來協調人員與代理。
當使用者希望您僅作為任務執行者、模組工作者或一般貢獻者時，請勿使用此技能。在這種情況下，請改用成員技能。
語言政策
- 預設的對話回覆應使用使用者當前提示的語言。
- 如果使用者明確要求某種對話語言，則使用該語言進行回覆。
- 如果使用者明確要求不同的文件語言，則按照要求的文件語言撰寫或編輯專案文件。
- 如果對話語言與文件語言不同，請保持兩者分離。
- 不要因為此技能的英文原文而強制輸出英文。
- 如果使用者的語言要求不明確，在撰寫長篇使用者可見文字或專案文件前，請先詢問。
目的
協助一位專案擁有者、維護者或協調執行緒，在同一個倉庫中組織多個人類或 AI 貢獻者。
您需要維護：
AGENTS.md：用於記錄專案規則與參與者註冊表。COLLAB_LOG.md：用於記錄活動工作鎖定、當前快照、更新、阻礙、決策與公開交接。TEAM_TASKS.md：僅在啟用任務指派模式時維護。MODULE_OWNERSHIP.md：僅在啟用模組所有權模式時維護。
自包含的範本檔案存放在此技能旁的 references/ 目錄中：
references/AGENTS.template.mdreferences/COLLAB_LOG.template.mdreferences/TEAM_TASKS.template.mdreferences/MODULE_OWNERSHIP.template.md
當僅安裝了這兩個技能資料夾時，請使用這些範本。倉庫根目錄的 templates/ 資料夾是給人類瀏覽的入口，內容與上述相同。
從這裡開始
-
在撰寫任何內容前，先檢查當前專案。
-
檢查這是否是一個 Git 倉庫：
git rev-parse --is-inside-work-tree -
如果不是 Git 倉庫，告知使用者，詢問是否需要初始化 Git，如果不需要 Git 則繼續進行 Markdown 協作設定，且不要執行
git fetch。 -
如果是 Git 倉庫，則執行：
git status --short --branch git branch -vv -
僅在存在遠端倉庫時執行
git fetch --all --prune。如果遠端或網路獲取失敗，如實報告，不要假裝同步成功。 -
判斷這是一個空白專案還是現有專案。
-
若存在，請閱讀現有的
README.md、AGENTS.md、專案設定檔與文件。 -
尊重現有的專案規則與架構。
-
僅建立或更新必要的協作檔案。
協作模式
選擇並記錄當前工作的模式：
- 共享工作區模式：多個代理使用同一個工作目錄。
- 遠端 Git 模式：不同機器、克隆或工作樹透過 Git 遠端進行協調。
不要混合不同模式的假設。共享工作區模式可以在同一個工作目錄中使用本地的 Markdown 狀態。遠端 Git 模式必須假設另一個參與者可以在兩次本地命令之間從不同的克隆推送變更。
遠端 Git 模式使用低衝突的 Markdown 狀態：
| 路徑 | 類型 | 規則 |
|---|---|---|
.collab/locks/<actor-id>.md | 權威狀態 | 一個參與者擁有其鎖定檔案。 |
.collab/tasks/<task-id>.md | 權威狀態 | 一個任務擁有其任務檔案。 |
.collab/events/<timestamp>-<actor-id>.md | 僅追加的事件 | 每個事件一個檔案。 |
.collab/snapshots/COLLAB_LOG.md | 衍生的快照 | 領導者可從鎖定、任務和事件中重建。 |
COLLAB_LOG.md | 衍生的快照 | 領導者可將其重建為人類可讀的彙總。 |
在遠端 Git 模式下，必要時初始化 .collab/ 目錄，並將根目錄的 COLLAB_LOG.md 和 TEAM_TASKS.md 視為可讀取的彙總資料，而非唯一的真相來源。
參與者身分啟動
領導者技能固定：
- 協作角色：領導者
請勿再次詢問該參與者是領導者還是成員。
在撰寫協作狀態前，先建立領導者的參與者身分：
- 人類擁有者：
- 代理平台：
- 協作角色：
- 功能角色：
- 實例：
- 參與者 ID：
- 顯示名稱：
規則：
- 如果人類擁有者未知，請詢問使用者。
- 如果無法可靠地確定代理平台，請詢問使用者。
- 如果功能角色不明確，請詢問使用者。
- 僅在使用者表示不需要細分功能角色時，才使用
全端開發者。 - 不要使用任務名稱作為參與者身分。
- 一旦寫入，請保持
actor_id穩定。 - 不要自動建立諸如通用設定參與者或基於任務的工作者等身分。
建議的 ID 格式：
human_owner: Gary
agent_platform: Codex
collaboration_role: Lead
functional_role: Project Coordinator
instance: 01
actor_id: gary-codex-lead-coordinator-01
display_name: Gary's Codex #01 (Lead - Project Coordinator)
在 AGENTS.md 的參與者註冊表中註冊領導者。當使用者提供身分詳細資訊時，領導者也可以註冊並維護團隊參與者。
參與者狀態語意
active：該參與者可以接受工作，並取得、重新整理、暫停、恢復和釋放鎖定。paused：該參與者暫時無法處理新的範圍。現有鎖定必須在參與者停止前釋放或標記為paused。retired：該參與者不再接受新工作，且不得持有活動鎖定。保留歷史記錄不變。- 允許的轉換：active -> paused -> active，active -> retired，paused -> retired。
- 成員只能更新其在參與者註冊表中的條目。
上次看到在參與者開始工作、取得鎖定、重新整理鎖定、暫停、恢復、釋放、變更任務狀態、建立交接或回應交接時更新。當前範圍在參與者取得、暫停、恢復或釋放鎖定時，或指派的任務範圍變更時更新。
必問問題：協作團隊模型
在初始化期間，詢問：
您是否已有現有的協作團隊模型？
如果是，則詢問：
- 有多少人類參與？
- 每個人類操作多少個 AI 子代理或 AI 執行緒？
- 每個人類或 AI 子代理負責什麼？
- 應該存在哪些成員參與者，以及每個成員應使用什麼功能角色、範圍和報告關係？
如果使用者已有模型，請提出後續問題，直到人類擁有者、AI 子代理、角色、範圍和報告關係都明確為止。
如果使用者沒有模型，詢問是否需要您提出建議的協作模型。在使用者要求之前，不要產生建議模型。
在理解或提出協作團隊模型後，為對話中的每個成員產生一個初始化提示。每個提示必須告訴該成員：
- 明確以
$team-member-collaboration開始； - 閱讀
AGENTS.md、COLLAB_LOG.md、可選的TEAM_TASKS.md和可選的MODULE_OWNERSHIP.md； - 理解專案與協作機制；
- 保留使用者的對話與文件語言要求；
- 使用約定的人類擁有者、功能角色、實例和範圍來確認或建立其參與者身分；
- 在編輯前檢查活動工作鎖定；
- 完成成員初始化並報告參與者 ID、指派範圍和準備就緒狀態。
將約定的模型記錄在 AGENTS.md 參與者註冊表中，並在啟用任務或模組模式時，使 TEAM_TASKS.md 和 MODULE_OWNERSHIP.md 與該模型對齊。
空白專案
當沒有明顯的專案結構（例如 README、原始碼、文件、應用程式、設定、套件、測試或腳本），或者使用者表示這是一個新專案時，將該資料夾視為空白專案。
對於空白專案，您可以建立：
AGENTS.mdCOLLAB_LOG.md
您可以建議一個輕量級的資料夾結構，但除非使用者要求，否則不要建立厚重的架構。
詢問或推斷：
- 專案名稱。
- 專案目標。
- 技術棧。
- 是否需要任務指派模式。
- 是否需要模組所有權模式。
- 是否需要起始目錄佈局。
現有專案
對於現有專案，檢查並保留當前結構。至少檢查：
README.md。- 現有的
AGENTS.md（如果有）。 package.json、pyproject.toml、Cargo.toml、go.mod或類似的技術棧檔案。src、app、lib、docs、tests、frontend、backend或類似的目錄。- 現有的貢獻或專案規則檔案。
- Git 狀態。
如果 AGENTS.md 已存在，請仔細閱讀並合併。不要覆蓋它。
如果類似的協作日誌已存在，請詢問是繼續使用它還是採用 COLLAB_LOG.md。
如果現有專案規則與精簡版預設值衝突，請停止並詢問：
現有專案規則與預設的協作工作流程存在衝突。您希望優先考慮現有專案規則，還是採用建議的精簡版規則？
預設建議：以現有專案規則為準。
必問問題：任務指派模式
詢問使用者：
您是否要啟用任務指派模式？
簡短說明：
如果啟用，領導者將：
- 建立並維護
TEAM_TASKS.md。 - 將工作拆分為任務。
- 指派任務擁有者。
- 記錄任務狀態。
- 定義範圍、目標和驗收說明。
- 必要時審查成員的輸出。
- 更新下一步計畫。
如果未啟用，則使用隨意協調模式：
- 僅維護
AGENTS.md和COLLAB_LOG.md。 - 成員根據當前使用者指示工作。
- 每個人在編輯前檢查活動工作鎖定。
- 每個人在完成後寫一個簡短更新。
- 不需要任務表格或審查流程。
僅在使用者選擇任務模式後才建立 TEAM_TASKS.md。
當任務指派模式啟用時，詢問一個簡短的後續問題：
誰可以將任務標記為完成？
允許的完成政策：
- 領導者審查
- 使用者審查
- 成員自行完成
- 按任務決定
將選定的完成政策寫入 AGENTS.md。除非使用者選擇，否則不要將每個專案的預設值設為領導者審查。
必問問題：模組所有權模式
詢問使用者：
您現在是否要定義模組邊界和擁有者？
如果是，則建立或更新 MODULE_OWNERSHIP.md。
如果否，則不要建立它。成員仍然可以透過 AGENTS.md 和 COLLAB_LOG.md 進行協調。
軟鎖定規則
軟鎖定是協作備註，而非安全鎖定。
COLLAB_LOG.md 必須將「活動工作鎖定」部分保持在接近頂部的位置。
快速閱讀 AGENTS.md、COLLAB_LOG.md 和任務檔案不需要鎖定。較大的研究或分析可以使用 reading 鎖定。
共享工作區模式使用本地雙重檢查：讀取鎖定，寫入您的鎖定，然後在編輯業務檔案前，在寫入自己的鎖定後再次檢查活動工作鎖定。
衝突語意：
- reading 與 reading 預設不衝突。
- writing 與重疊的 writing 是衝突。
- reading 與重疊的 writing 需要警告。
- 如果 reading 僅為觀察，則可以繼續。
- 如果 reading 可能很快轉為編輯，則先詢問或切換範圍。
- paused 仍保留範圍。
- 過時閾值：2 小時，除非
AGENTS.md有覆蓋。 - 未經使用者或領導者確認，請勿移除其他參與者的過時鎖定。
在進行較大的讀取/寫入工作前：
- 讀取最新的
COLLAB_LOG.md。 - 檢查重疊鎖定。
- 如果沒有重疊，為您自己的工作添加鎖定。
- 在寫入自己的鎖定後，再次檢查活動工作鎖定。
- 如果另一個參與者同時建立了重疊鎖定，請不要編輯業務檔案。解釋衝突並等待決定。
將以下情況視為可能的重疊：
- 相同的檔案路徑。
- 相同的資料夾或模組。
- 包含請求檔案路徑的廣泛模組鎖定。
- 兩個任務都可能修改的共享介面或合約。
使用相對於倉庫根目錄的路徑作為範圍。優先使用具體的檔案或目錄。不要記錄本機的絕對路徑。
範圍標準化
- 僅使用相對於倉庫根目錄的路徑。
- 使用
/作為分隔符。 - 移除開頭的
./。 - 折疊重複的
/字元。 - 移除結尾的
/，除非是倉庫根目錄。 - 使用
;分隔多個路徑。 - 修剪每個路徑周圍的空白。
- 拒絕絕對路徑。
- 拒絕包含
..的路徑段。 - 當任何標準化路徑相等、存在父子關係，或共享已聲明的模組/介面邊界時，視為範圍重疊。
使用以下鎖定格式：
- 參與者 ID：
顯示名稱：
協作角色：領導者 | 成員
功能角色：
狀態：reading | writing | paused
範圍：
任務：
開始時間：
最後更新：
預計完成：
備註：
當工作完成時，移除您的鎖定，並在「最新更新」下添加一個簡短條目。
遠端 Git 模式鎖定協議
在遠端 Git 模式下修改業務檔案前：
- 獲取最新的遠端狀態。
- 重新讀取
.collab/locks/*.md和.collab/tasks/*.md。 - 檢查現有鎖定是否存在範圍重疊。
- 在
.collab/locks/<actor-id>.md中建立一個候選鎖定記錄。 - 僅提交該候選鎖定。
- 將候選鎖定推送到協作分支。
- 如果推送報告非快進，則獲取、變基或重新應用候選鎖定，重新讀取所有鎖定，並重新評估範圍重疊。
- 不要盲目重複推送。
- 不要強制推送。
- 僅在候選鎖定已發布並在最新的遠端狀態上重新檢查後，才編輯業務檔案。
如果兩個參與者競爭相同範圍，則只有一個可以繼續。失敗的參與者必須撤回候選鎖定並在業務編輯之前停止。
鎖定生命週期：
- acquire：發布候選鎖定，重新檢查最新的遠端狀態，然後繼續。
- refresh：在繼續長時間工作前更新
最後更新。 - pause：在暫時停止時保留範圍。
- resume：同一參與者返回並在編輯前重新整理鎖定。
- release：移除或標記鎖定為已釋放，並提交結果。確保業務檔案的變更也已被提交。