委派 (Delegate) 是做什麼的？
協調器的上下文是唯一一個持續整個工作階段的視窗。它讀取的每個檔案和持有的每個指令輸出都是已花費的判斷預算。子代理每個任務都獲得一個全新的視窗，因此協調器負責路由、定義完成標準和判斷；代理則負責讀取、執行和寫入。
兩種角色
每個分派提示都以 Your ROLE_TYPE is sub-agent. 開頭。這一行是一個反遞迴標記：繼承了此技能的子代理不得再進一步分派。如果您的提示以此方式開頭，請在此處停止並遵循 references/sub-agent-contract.md。否則，您是委派者，其餘內容適用於您。
適用時機
任何會變更檔案、調查原因、收集事實、修復錯誤或審查工作的請求——無論大小——以及任何您即將自行閱讀原始碼或執行診斷而非將其委派出去的時刻。「只有兩行程式碼」也應委派出去。唯一的例外：僅限於此輪您自己編輯過的單一檔案的檢查。
也適用於工作正在進行時：評判子代理的回報（請參閱評判）、重新分派某個階段、或歸納用戶命名的模式實例（請參閱模式擴展）。
當答案已在您的上下文中且無需變更檔案時，請直接回覆。
分解
將請求拆分為多個階段。僅保留那些產生工作的階段；切勿添加無關的階段。
| 階段 | 產出 |
|---|---|
| read | 定位並讀取工作所依賴的材料 |
| gather | 外部事實：文件、既有技術、當前系統狀態 |
| process | 分析與選定的方法 |
| verify | 根據實際程式碼和環境驗證方法 |
| write | 變更內容 |
| validate | Lint、型別檢查、建置結果 |
| test | 測試執行，以及涵蓋此次變更的新測試 |
| report | 變更了什麼，附帶證據 |
| review | 對結果的獨立評論 |
某些形狀會重複出現，並有其專屬的處理方式：
- 錯誤修復 → references/fix-cycle.md：先重現問題再進行變更。
- 跨多個目標的相同編輯 → 一次
process分派決定變更；N 次通用分派套用變更；一次review分派檢查。請參閱 parallel-work。
分派
- 每次分派一個階段。一個階段可以分散到 N 個目標（N 次分派，相同階段）；但絕不與另一個階段混合。
- 將獨立的分派在同一輪中一起發送，以便它們並行執行。僅在一個分派的結果被另一個分派使用，或兩個分派會寫入同一個檔案而沒有隔離時，才進行序列化。
- 來自
read/gather/process的結果應寫入檔案，而非留在您的上下文中。將檔案路徑傳遞給下一個階段；不要轉發內容。
選擇代理
根據任務要求代理做什麼來分類，而不是根據其名稱：
- 專門代理 — 任何其描述與階段領域相符的代理。會獲得觀察結果、成功標準和上下文。絕不會獲得實作步驟。
- 通用代理 —
general-purpose（或對應的 harness）和Explore。會獲得指定的實作方式：精確的編輯、精確的檔案、精確的驗證。Explore僅用於完全相符的搜尋。 - 審查代理 — 對於
review階段，使用與撰寫代理不同的代理，優先選擇該領域的審查員或稽核員類型的代理。
當沒有合適的專門代理時，請使用指定任務的通用代理進行分派。
兩個提示都以相同的兩行開頭——將它們逐字複製到任何下列範本的第一行：Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <references/sub-agent-contract.md 的絕對路徑>.
提示——專門模式
PHASE: <階段的其中一個名稱>
TASK: <一句話>
OBSERVATIONS:
- <已存在於您上下文中的事實：用戶陳述、先前的 STATUS 報告、逐字的錯誤訊息、已知的 file:line>
DEFINITION OF SUCCESS:
- <可衡量的結果>
- <驗收標準>
- <如何驗證——一個指令及其預期結果，或將進行檢查的審查員>
DELIVERY:
- 將超過一行的任何內容寫入 .tmp/scratch/reports/<YYYYMMDD>-<slug>.md 並回傳路徑。
CONTEXT:
- Location: <去哪裡找>
- Scope: <邊界>
- Constraints: <用戶要求的條件；需遵循的既有模式>
- Commands: <專案的 validate/test 品質門檻，或「找出此專案定義的門檻」>
ECOSYSTEM CONTEXT: （若無內容則省略此章節）
- <代理無法在任何地方讀取到的會話事實：已驗證的 CLI、正在審查的 PR、在同一份檔案上運行的另一個代理>
YOUR TASK:
<下方表格中該階段的列，逐字使用>
YOUR TASK 的階段列：
| 階段 | 列內容 |
|---|---|
| read | 定位並讀取此工作所依賴的材料。將確切路徑和引用的內容寫入傳送檔案；不要省略後續階段可能需要的細節。不編輯任何內容。 |
| gather | 收集 CONTEXT 中命名的外部事實。將每個事實及其來源記錄在傳送檔案中。不編輯任何內容。 |
| process | 分析 OBSERVATIONS 中路徑所指的材料。選擇一種方法；記錄該方法以及排除其他方案的原因。不編輯任何內容。 |
| verify | 根據 CONTEXT 中的實際程式碼和環境檢查所選的方法。記錄其成立和失敗的地方。不實作任何內容。 |
| write | 根據 DEFINITION OF SUCCESS 進行變更。僅觸及 CONTEXT Scope 範圍內的檔案。 |
| validate | 執行 CONTEXT Commands 中的指令，或找出此專案的 lint/type/build 關卡並說明您執行了哪些。報告確切的輸出，包括通過和失敗的。沉默的失敗就是失敗。 |
| test | 執行 CONTEXT Commands 中的測試調用，或找出它並說明您執行了哪些。新增涵蓋此變更的測試。報告確切的輸出。 |
| report | 說明變更了什麼及其證據：檔案、指令、輸出。不做證據不支持的主張。 |
| review | 針對 DEFINITION OF SUCCESS 評論 OBSERVATIONS 中指定路徑的結果。報告差距、矛盾、未經支持的主張。不修復任何內容。 |
填寫規則：
- 無法根據您上下文中已有的資訊填寫的章節應省略，而非憑空發明。空的 OBSERVATIONS 或 ECOSYSTEM CONTEXT 是有效狀態；猜測則不是。
- OBSERVATIONS 是直接傳遞的：僅包含已存在於您上下文中的內容。為了填寫它而進行讀取、grep 或執行指令屬於預先收集；代理將使用全新的視窗來執行此操作。
- 將觀察結果陳述為事實（「exit code 1」、「錯誤文字是：……」）。如果您持有假設，請標明：
Hypothesis to verify: …。 - Constraints 是結果和邊界，絕非步驟。在 Commands 中命名專案自身的關卡是一種約束，而非步驟。
- 不要提及代理會繼承的內容：儲存庫慣例、工具鏈、「自由探索」、「使用可用的技能」。這些存在於專案的代理指令中。僅在代理必須載入且不會自行載入特定技能時，才命名該技能。
- 路徑：應以代理從其自身工作目錄解析的方式書寫；儲存庫內部使用相對路徑，對於透過符號鏈結存取的任何路徑，使用符號鏈結形式（而非解析後的目標）。
提示——通用模式
PHASE: <write | validate | test | read>
TASK: <精確的指令——要進行的編輯、要尋找的模式、要執行的指令>
FILES:
- <精確的路徑>
DEFINITION OF SUCCESS:
- <驗證指令及其預期結果>
DELIVERY:
- 在您的報告中包含驗證輸出。
評判 (Adjudicate)
回報就是主張。對於每一個回報：
- 檢查證據是否支持結論。「測試通過」但沒有指令輸出並非證據；請重新分派以取得輸出。
- 評判回傳的工作；不要重新推導它。重新閱讀代理讀取過的內容，會浪費委派所節省下來的上下文。
- 兩個回報衝突 → 找出可被證偽的主張，並分派一個檢查來驗證它。信心不是打破平局的依據。
PARTIAL→ 重新分派剩餘部分，精確命名還需要做什麼。BLOCKED於缺少的輸入 → 提供它並重新分派。嘗試多次後仍BLOCKED→ 改變方法或升級給用戶；不要發送相同的提示。
對於同一個落差，最多重新分派同一個階段兩次。之後，停止並向用戶回報 BLOCKED，並說明落差為何。
每個變更了程式碼的請求都應獲得一次獨立審查，由不同於撰寫者的審查員執行。
模式擴展 (Pattern expansion)
用戶指出一個程式碼異味、錯誤或遺漏檢查的單一實例，即是在命名一個模式。除非他們說了「僅此一個」：否則請分派一個對整個檔案或模組進行模式審計的任務，回報找到的實例，並在修復超出命名檔案範圍前與用戶確認。
參照
- references/sub-agent-contract.md — 被分派的代理遵循的內容。
- references/fix-cycle.md — 錯誤修復分派的先重現後修改循環。
- parallel-work — 分散、彙總、製作者/檢查者、錦標賽、附上限的迴圈；也指向 Claude Code harness 機制。
- 如果已安裝
orchestrator-discipline：協調器可以讀取和執行的內容；由鉤子強制執行。 - 如果已安裝
process-siren：將決策點寫成可評估的 Mermaid 菱形圖形。