協調完整的 x-工作流程
目前的工作階段是父協調器。在分派任務之前，請先閱讀 references/workflow.md。根據需要閱讀其他三個技能；它們的階段語意和共享合約適用於所有工作人員。請勿因為請求中的名稱拼寫錯誤而執行不相關的 kauto 工作流程。
準備與分配
- 確定請求的結果、約束條件和範圍。找到 Git 根目錄、目前分支/HEAD、適用的說明以及髒/索引狀態。Git 是必需的；如果沒有，請停止而不是默默地初始化它。選擇一個乾淨、專屬的任務檢出。保留不相關的工作；可能時進行隔離，否則請求使用者提供所需的處理方式。當在單獨的分支上工作時，請勿承諾在使用者的原始分支上進行提交。
- 分配任務 ID 和標準的成品路徑。規劃人員可以提議多個有範圍的單元加上共享設計；父協調器集中分配額外的 ID 並保留對完整請求的覆蓋範圍。
- 探索可用的委派工具。優先使用子工作階段；僅在不可用時才使用子代理。遵循主機的委派/生命週期規則。請勿假設工具名稱或在父工作階段中使用另一則訊息偽造全新的上下文。如果兩種機制都不存在，請停止並解釋獨立的協調式工作流程不可用；請勿默默地內聯執行每個角色。
- 繼承模型/框架/努力，除非使用者或適用的說明另有選擇。使用全新的審查人員上下文，而不是包含作者私人推理的分支。審查人員可以查看請求、程式碼、成品和先前的公開發現，但審查人員不是撰寫所審查的規劃/實作的工作人員。
- 使用共享合約捕獲父工作階段的階段來源（session provenance）。在交接時請求每個工作人員的協調器 ID 和原生對話 ID；在清理之前將其保留在工作日誌中，而不僅僅是短暫的工作人員名稱。
分派明確的階段簡報
每個工作人員都會獲得目標、相關的使用者約束條件、技能和呼叫、任務 ID、確切的檢出和起始 HEAD、輸入/輸出路徑、允許的編輯、提交權限、檢查要求以及現有的驗證證據、預期的交接（包括階段來源）和停止條件。 包含結果將在何處使用。提供規劃或請求，而不是工作人員應獨立驗證的假設。
階段在共享檢出中依序進行。預設一次只有一個寫入者；僅當單元的檔案和依賴關係真正獨立且整合/審查所有權明確時，才同時執行獨立的單元。確認每個子項目的實際目錄/HEAD；在下一個階段之前，按照共享合約中的說明，整合隔離工作人員的交接提交。切勿刪除未轉移的結果。
規劃 → 審查規劃
- 使用
xplan <request>啟動規劃人員，且無生產程式碼編輯權限。規劃人員研究棘手的問題，確定工程決策，並返回現成的規劃、微小任務簡報或具體的阻礙。 - 檢查返回的成品和覆蓋範圍。將規劃/共享設計記錄提交為
plan，然後使用xreview plan .agents/plans/ID.md將每個執行規劃發送給獨立的工作人員。將其審查輪次提交為plan-review。 - 對於發現的問題，將具體的修正任務分配返回給規劃人員。提交修訂後的規劃。父協調器根據發現的問題和相關證據檢查修正，記錄其處理方式和最終的規劃/指導（guidance） blob，並在沒有留下重要缺陷時繼續進行。這是父協調器的執行決定，而不是聲明審查人員已批准未見的修訂。請勿將每個修訂都通過另一個完整的規劃審查。額外的獨立評估需要一個特定的、重要的問題，而先前的審查和修正檢查無法解決該問題；請指定該問題並僅請求所需的評估。措辭、元數據和常規修正不足以重新啟動審查。共享設計編輯需要檢查受影響的單元，而不是自動為每個單元安排另一次審查。
- 對於真正微小的工作，保留規劃人員的有範圍簡報供 xwork 使用，並跳過單獨的規劃/審查成品；稍後的工作日誌會記錄原因。請勿透過將大型未解決的任務稱為簡報來繞過標準化。
- 分割的請求在其第一個單元完成後並未結束。在共享設計中追蹤單元依賴關係，依序執行每個請求的單元，並在依賴關係變更時重新檢查共享介面/中間狀態。
工作 → 審查實作
- 使用
xwork .agents/plans/ID.md分派實作人員，或使用明確的微小任務簡報。提供已接受的審查/規劃和連結的指導 blob。僅授權任務所擁有的程式碼和日誌提交。xwork 記錄固定的 Code 基礎，提交已驗證的程式碼，然後使用已知的 Code HEAD 單獨提交其日誌。 - 根據 Git 和記錄的測試輸出檢查交接；子項目的「完成」訊息並非正確樹狀結構、完成檢查或已提交檔案的證據。解析整合映射並在最終日誌中使用任務檢出雜湊值。
- 使用
xreview work .agents/work/ID.md啟動獨立的審查人員。提供請求、規劃/簡報、完整的 Code 基礎..Code HEAD 範圍、工作日誌和相關的儲存庫說明。審查人員閱讀程式碼和測試，而不僅僅是日誌，並撰寫審查，但不修正實作。將其審查提交為work-review。 - 傳遞針對所記錄 Code HEAD 的可檢查檢查結果。要求審查人員首先檢查/重複使用該證據，並在選擇新檢查之前識別任何剩餘的不確定性。對於相同且未更改的程式碼，請勿常規性地要求進行重點重複、完整的套件執行和儲存庫套件再次執行。仍然適用明確的新執行要求。
- 將可操作的發現發送給實作人員。實作人員提交修正和附加的日誌條目，保留原始基礎。將完整的更新變更返回給獨立的審查人員；先前的發現需要解決證據，而不是全新的空白檢查清單。保留所有審查輪次。審查人員可以在獨立於作者的情況下重複使用；任何角色都不能批准其剛剛撰寫的程式碼。
- 如果實作揭露了無效的設計，請在繼續之前將決策路由回規劃人員和父協調器。對受影響的依賴單元應用相同的修正檢查；額外的獨立評估需要特定的重要不確定性，而不僅僅是變更的規劃 blob。請勿讓 xwork 默默地擴大範圍或將困難的選擇留到編碼時。
解決發現的問題並誠實地完成
在沒有常規確認的情況下繼續進行，但當意圖、範圍、權限或重大的權衡取捨確實需要使用者時，請詢問。在必要工具/檢查不可用或存在爭議的決定時停止。在修復取得進展時繼續進行常規修復；如果某輪重複相同的失敗方法、需要使用者決定或超過明確的預算，則停止並報告未解決的證據，而不是產生無限的審查循環。切勿為了完成循環而接受缺陷。
在成功之前，父協調器需驗證：
- 每個請求的執行單元都已實作，所需的檢查確實通過，且其最終程式碼已獲得獨立的已接受工作審查。
- 在單元已審查的 Code HEAD 之後，每一個程式碼/測試/設定變更都包含在稍後單元對整合任務檢出的已接受審查範圍內，或者重新通過驗證和工作審查。已知僅限工作流程記錄的變更不需要重新審查程式碼。說明所有提交/差異，而不僅僅是匹配的路徑名稱。整合衝突修復和先前合約的違反需要重新進行檢查/審查；稍後被接受的單元不會自動免除這些問題。
- 工作日誌包含已接受的規劃/簡報、固定的基礎、最終審查的 HEAD、實際的提交、父/工作人員的原生對話 ID（或明確的不可用原因）、執行/重複使用的驗證證據和審查路徑。將它們設定為
complete並將剩餘的任務所擁有記錄提交為complete。 - 所有任務所擁有的變更和新記錄都已提交到報告的分支上。使用 Git 驗證，保留不相關的工作，並且不要推送到不同的分支或自動合併到其中。原始程式碼 HEAD 不需要等於最終 HEAD，因為後續提交包含記錄或其他獨立接受的單元。
- 在結束會移除其分支/工作樹的工作階段之前，儲存每個子工作階段的階段來源並整合/儲存每個結果。留下可達的已提交結果，並遵循主機的清理規則。失敗的循環報告部分提交和阻礙，而不是成功。
返回簡潔的結果、任務 ID、成品路徑、分支和最終提交 ID、檢查結果、審查裁決以及任何剩餘的限制。父協調器擁有此驗證和最終報告的所有權；請勿僅僅串聯工作人員的摘要。