執行工作
在一個源自 develop 的有意義分支上自主執行已同意的。將實作工作委派給位於獨立工作樹中的子代理，然後將它們完成的以快轉方式合併到該協調分支，進行清理，並從完成的協調分支向 develop 建立一個準備好進行審查的 Pull Request。
呼叫此技能即授權建立本地任務分支、工作樹、提交、重新設定尚未發佈的任務分支之基礎、將任務分支快轉合併到協調分支、移除已清理且完全整合的任務工作樹與分支、推送完成的協調分支，並為其向 develop 建立 PR。無需再為這些動作要求確認。遵循使用者的範圍與儲存庫指示，包括明確的僅限本地或無 PR 的覆寫。合併 PR 與部署不在本技能的授權範圍內。維持任何既有的禁止事項。
1. 準備協調分支
讀取已同意的計畫、適用的 AGENTS.md 及所需的專案指引。如果工作已定義，則直接執行，無需再進行一輪設計或核准。僅針對重大缺失的需求提出一個聚焦的問題。
檢查狀態、參考以及既有工作樹。保留不相關的編輯與簽出；請勿重設、暫存或重新利用它們。當有配置的遠端時，從該遠端獲取 develop 並使用該獲取的最新提交。若無法獲取，請揭露此限制並使用既有的本地 develop 參考；若兩者皆不存在，則要求提供基底分支。切勿在未告知的情況下悄悄替換為其他分支。
在建立任何分支或工作樹之前，先擷取 git worktree list --porcelain、本地分支名稱以及必要時的管理式工作樹附件。在工作清單中維護一份由本次執行所擁有的庫存：分支、絕對路徑、擁有者/代理、管理類型與身分、最終提交以及清理狀態。包含為本次執行建立的每個任務、輔助代理、審查者、重試以及後續代理的簽出，即使這些項目已被放棄或未包含任何變更。協調者負責清理整個庫存。保留既有且無關的分支/工作樹；僅憑名稱前綴相符並不構成擁有權的證明。
建立一個專用的協調工作樹與分支。依照 Conventional Branch 風格命名，形式為 <type>/<short-description>，使用小寫與連字號，例如 feat/store-invitation-recovery。選擇適合該工作的類型：feat（新行為）、fix（錯誤修正）、refactor、perf、docs、test、chore（工具或維護）或 ci。若使用者或儲存庫指定了不同的慣例（例如在 AGENTS.md 中），則遵循該慣例。請勿在其名稱中包含 integration。
記錄協調的基底提交。若在恢復的呼叫中，則重複使用本次執行的協調分支/工作樹與庫存，檢查其狀態而非重新開始。
2. 拆分與委派
根據可交付成果與檔案擁有權進行拆分。在可用的代理容量內並行執行獨立任務；安排具有依賴關係或重疊編輯的任務順序。從協調分支的當前最新提交建立每個任務分支/工作樹。在依賴項整合後，從更新後的最新提交開始執行依賴任務。
實際產生子代理，並提供任務需求、相關的計畫章節、絕對工作樹路徑、分支、其擁有的檔案、依賴合約、驗收標準以及所需的檢查。每個代理僅在其指定的簽出目錄中工作，提交其變更，並回報其提交、檢查結果、待辦事項以及其建立的任何額外分支/工作樹。立即將這些資訊註冊到本次執行所擁有的庫存中。協調者獨自負責整合與移除工作樹。子代理不得遞迴呼叫此協調技能或推送其分支。使用明確的工作目錄或 git -C；代理可以共享一個預設目錄。若無法進行委派，請回報此限制，而非在未告知的情況下悄悄改為獨自執行。
3. 審查完成的任務
檢查每個任務的實際差異與提交，對照其驗收標準。將失敗情況告知負責的代理。在整合之前，要求任務簽出目錄乾淨、提交已完成，且相關檢查通過；準確回報既有的或環境性的阻礙。不要僅僅因為代理回報完成就合併其工作。
4. 使用快轉合併進行序列化整合
在重新設定任務分支的基礎之前，停止對已完成任務分支的寫入。對於每個任務，檢查其祖先關係與協調分支的當前最新提交。並行的兄弟分支在第一個合併後會發散：在合併之前，將每個尚未發佈的任務分支重新設定到更新後的協調分支上。根據已同意的需求解決衝突，保留已整合的行為；在重新設定基礎或解決衝突後，重新執行受影響的檢查。
使用記錄的絕對路徑與分支名稱的範例：
git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# 在 task_path 中執行所需的檢查，然後驗證祖先關係。
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"
在繼續之前檢查每個指令的結果。如果快轉失敗，請重新檢查祖先關係並視需要再次重新設定基礎。請勿使用合併提交、squash、cherry-pick、強制推送或重設協調分支來替代。如果安全解決方案需要產品決策，請保留兩個分支並提出詢問。在每次成功的任務整合及其所需的檢查之後，立即為該任務執行下面所述的清理工作。從協調簽出目錄審查合併後的工作；已合併的任務簽出目錄在 PR 審查時並不需要。對已被放棄或取代的、本次執行所擁有的輔助代理套用相同的清理，前提是其工作已處理完畢。
5. 驗證、清理並建立 PR
在最終的協調分支上執行相關的整合檢查，並將結果與整個計畫進行比對。在完成之前修復整合回歸問題。
必要的清理：執行並驗證
清理是可交付成果的一部分，而非留待使用者稍後執行的建議。呼叫已授權移除本次執行中已清理、完全整合的任務/輔助工作樹與分支；無需再次請求進行這些移除。
-
停止擁有該簽出目錄的代理以及任何正在寫入該簽出目錄的背景程序。在重新設定基礎後記錄分支的最終提交，驗證它是當前協調最新提交的祖先，並檢查已追蹤、未追蹤以及被忽略的檔案。對於沒有提交的輔助代理，也請驗證其最新提交已包含在內。與負責人處理未完成的工作：整合必要的變更，並在繼續之前將有價值的本地工件保留在一個保留的位置。可丟棄的、由執行產生的快取或日誌可以透過精確路徑移除；這不構成無限期保留其他已完成的簽出目錄的理由。
-
對於普通的 Git 工作樹，使用記錄的 exact 路徑與名稱執行以下操作，並在繼續之前檢查每個結果：
git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch" git -C "$task_path" status --porcelain --untracked-files=all git -C "$work_path" worktree remove "$task_path" git -C "$work_path" branch -d "$task_branch"工作樹的移除並不會刪除其分支。兩個操作都是必需的。也刪除那些已無對應工作樹的、本次執行所擁有的分支。絕不使用強制移除、
git branch -D、廣泛的目錄刪除或忽略未知的編輯。診斷失敗的指令並在範圍內修正常見的清理問題，而不是在未告知的情況下悄悄跳過它們。 -
對於應用程式管理的工作樹，使用其管理 API 而非直接刪除目錄。在 Codex 中，使用
list_artifacts解析確切的、受管理的任務工作樹身分，然後使用archive_worktree；檢查結果並再次列出以確認它不再活動。之後在其仍存在時，使用git branch -d刪除其受管理的本地分支。存檔快照或應用程式附件不能替代檢查 Git 註冊與分支移除。 -
只有在驗證以下所有條件後，才能將庫存條目標記為已清理：其確切路徑不存在、它不再由
git worktree list --porcelain註冊、其分支已從本地參考中消失，且任何管理的附件不再活動。如果 Git 表示該分支仍被簽出，請檢查其他簽出目錄。不要將成功的移除請求或代理的回報視為證據。 -
在最終回應之前，在 PR 建立或任何後期審查工作之後，重複 Git 分支/工作樹與管理附件的庫存檢查。將其與基準線和本次執行所擁有的庫存進行比較；說明代理報告中遺漏的新條目，但不要刪除不相關的並行工作。協調分支/工作樹必須是唯一剩下的、本次執行所擁有的分支/工作樹。為了 PR 與測試而保留它，同時也保留既有的或不相關的簽出目錄。即使 PR 建立被阻止或跳過，以及在失敗/中斷時，在安全的情況下讓出控制權之前，仍然需要執行此最終審計。
如果清理無法安全完成，請繼續清理其他符合條件的條目，並回報清理受阻，說明每個保留的分支/路徑、確切的失敗操作或有價值/未合併的工作，以及解決該問題所需的最小動作。當仍有本次執行所擁有的臨時分支/工作樹存在時，請勿將整體工作流程回報為完成。持續進行例行清理，而不是在成功的合併、通過測試或 PR 建立時就結束。
推送並建立 PR
保留協調分支/工作樹及其所有已提交的工作，以便進行審查。在整合與必要驗證成功後，檢查最終差異，並僅將協調分支推送到目標儲存庫的遠端。建立一個準備好審查的 PR，以 develop 為基底，協調分支為頭部分支；僅在使用者明確要求時才使用草稿模式。在建立 PR 之前，檢查是否已存在針對此頭部/基底的開放 PR，包括在建立結果不確定之後；重複使用或更新它，而不是建立重複的 PR。
遵循儲存庫的 PR 範本、標題慣例以及工單連結要求。描述最終的行為、檢查及其結果，以及具體的手動測試步驟。這些步驟必須描述如何操作產品和/或檢查持久化狀態，而不是另一份儲存庫測試指令的清單。偏好使用本地 Git 進行推送，並使用可用的儲存庫連接器來建立 PR；必要時使用已驗證的 CLI。驗證 PR 的實際基底、頭部以及已發佈的提交是否與完成的協調分支相符。當工件附件工具可用時，將每個建立的 PR 附加到當前對話。將 PR 保持開放以進行審查。
如果推送或 PR 建立受阻，請保留完成的協調分支/工作樹，並回報確切的阻礙因素以及剩餘的動作。在沒有確認的 URL 的情況下，請勿聲稱 PR 已存在，也請勿透過強制推送來繞過拒絕。
完成報告
最終回應必須以確切的協調分支名稱和絕對工作樹路徑開頭。包含一個指向已確認 PR 的 Markdown 連結，或說明 PR 建立為何受阻或被明確跳過，然後包含：
- 現在可以達成的功能： 已完成的行為以及任何剩餘的範圍。
- 已執行的檢查： 確切的指令與實際結果，標明跳過或受阻的檢查。
- 如何測試： 一個簡短、編號的、使用者可執行的、在協調工作樹中進行的驗證程序。這與自動化檢查分開，不能以重複執行
pnpm test、lint、建置或類似指令來滿足。視情況包含：- 設定：環境/應用程式 URL、登入與角色、服務、種子資料或測試數據、記錄 ID 以及工作目錄；
- 主要產品流程：確切的畫面或端點、真實的輸入與 UI 操作、要觸發的行為以及預期的可見結果；
- 相關的邊界或回歸流程：當這些情況重要時，包含無效、空白、重複、受限或先前已完成的資料；
- 針對會寫入或轉換資料的變更進行持久化狀態驗證：提供一個唯讀的資料庫/API 檢查方式，包含資料表或資源、篩選條件或識別碼、要檢查的欄位/狀態以及預期的結果。將使用者操作與儲存的記錄連結起來，而不僅僅是說「檢查資料庫」。 例如，一個潛在客戶開發的變更應說明為一個命名區域和半徑建立領地掃描、找到一個特定地點、確認其必要屬性、完成審查/外展操作，並在應用程式和相關記錄中驗證產生的審查或外展狀態。對其他產品工作流程使用相同等級的具體性。 將自動化指令保留在已執行的檢查下方。將每個手動步驟標記為已執行或建議；如果應用程式或資料庫不可用，請陳述確切的阻礙因素以及執行它所需的最小設定。資料庫檢查是唯讀的，除非已核准的工作明確授權測試資料的變更。
- 清理與阻礙因素： 驗證已移除或封存的臨時工作樹數量以及已刪除的本地分支數量；最終審計中剩餘的、本次執行所擁有的分支/工作樹（通常只有協調者）。列出每個受阻的臨時分支/路徑及其確切原因；包括任何未完成的推送或 PR 步驟。
保持進度更新簡潔，並以一個可在兩分鐘內完成的具體下一步行動作為結束。