委派
節省父 Codex 代理的 Token 與脈絡，同時維持品質。優先考慮有用的委派和已驗證的結果，而非單純縮短經過時間。任務所有權、關鍵決策、整合與最終驗證由父代理負責。
預設在當前代理中處理工作。只有在獲得使用者明確授權，並先就代理數量、提供者、模型與推理努力達成共識後，才能啟動額外工作者。該核准僅涵蓋該次委派；額外代理或更高的設定需要重新核准。在此範圍內，使用以下「原子化脈絡」政策來選擇有用的任務，並提出有價值的 Pro 諮詢。此技能不凌駕使用者或儲存庫對委派、範疇或外部資料存取的限制。
依原子化脈絡組織工作
偏好使用較少的代理，並提供完整且相關的脈絡。一個原子化脈絡是所需假設、證據與後果需共同推理的最小連貫問題或工作流程。它可能橫跨多個模組或儲存庫。一個檔案、模組、階段或個別發現，並非自動成為一個有用的委派邊界。
- 將相關的調查、重現、修正與後續追蹤交由同一個脈絡持有者。提供相關的合約、呼叫者、資料流、共享假設與證據。當連續性有幫助時，恢復該工作者；當獨立審查能增加價值時，使用全新脈絡。檔案所有權控制寫入權限，而非代理理解所需證據的範圍。
- 在有益時提議增加代理。當有足夠的獨立脈絡、充足的配額以及整合其結果的能力時，大型批次可能很有用；在啟動前先就數量與設定達成共識。偏好較少代理是對連貫性工作的偏好，而非平行處理的人為上限。
- 在新增工作者之前，先找出它將解決的明確結果或不確定性。權衡已驗證的覆蓋率、品質以及所節省的父代理 Token，與重複閱讀、交接與整合工作，以及消耗的配額。當委派帶來的額外開銷超過其價值時，直接或使用確定性工具處理小型工作。
- 避免生產力表演：代理數量、Token 量、複雜工作流程或消耗即將到期的配額，都不是成功的衡量標準。不要機械化地為每個模組或發現建立一個代理、重複整個儲存庫的探索，或在沒有特定理由的情況下進行冗餘審查。對於大型稽核，在擴大審查者範圍之前，先合併重疊的發現與相關驗證；將專門的獨立審查保留給後果重大或有爭議的結論。
對於大量批次，應根據當前配額與觀察到的消耗（包括驗證、綜合與整合結果的能力）進行規劃。根據後續波次的有用性來擴展或縮減。保留一份增量報告或可用的成果，以便限制不會讓所有價值都擱淺在未完成的調查中。Claude 配額機制詳見 claude-code.md。Codex 執行與帳戶限制是分開的；僅在進行 Codex 工作時閱讀 codex-cli.md。
選擇關係與目標
| 目標 | 關係 | 合適的工作 |
|---|---|---|
| ChatGPT 網頁 · Extra High | 委託製作一個或多個資訊圖表 | 模組、套件、演算法及相關技術系統的詳細說明。優先提供所有要傳達的資訊，然後才是美學方向。絕不要對此路線使用 Pro。 |
| ChatGPT Pro | 諮詢教授或專家同事 | 困難的數學或演算法問題、文獻綜合、對抗性推理、最佳化、重新思考方法，以及透過持續調查與測試從頭實作的極困難模組。 |
| Codex 原生子代理 | 在此對話中給予綁定工作 | 當已選擇 Codex 且當前協作工具適用時使用；保留原生工作階段限制與執行政策。 |
| Codex CLI 工作者 | 執行獨立的持久本機工作階段 | 當請求或授權使用獨立的 Codex CLI 工作者時使用；固定所選的模型/推理努力與 ChatGPT 登入狀態，擁有獨立的擁有權與精確的恢復能力。 |
| Claude Opus 5.5 | 給予一個有能力的工作者綁定任務 | 預設用於大型實作、可重現的錯誤調查、UI 檢查、長期稽核、文件編寫、重構以及例行獨立審查。 |
| Claude Fable 5.1 | 請求要求嚴謹的獨立審查 | 數學假設、架構、反例，以及對父代理或工作者輸出的細微正確性審查。在需要時直接使用；Opus 審查不是先決條件。 |
| Claude Sonnet 5 | 分配指定的獨立批次 | 測試、轉接器遷移、檢視稽核以及具有明確範疇與可承受檢查的文件調和。 |
| Claude Haiku 4.5 | 處理指定明確的批次 | 使用評分標準與棄權選項的初階影像/文字註解、結構化提取、庫存清單與記錄標準化。當足夠時，使用確定性程式碼。 |
路由反映使用者的工作偏好，而非通用的能力排名。Pro 諮詢不一定要在 Claude 嘗試失敗後進行。Fable 對於專注且嚴謹的獨立審查仍有價值；當開放式探究或異常深入的持續工作是重點時，選擇 Pro。
僅閱讀相關的操作指南：
- Claude 執行或使用方式： claude-code.md。它連結到模型證據/範例與詳細的運作疑難排解。
scripts/worker.py和scripts/usage.py僅操作 Claude 工作者。 - Codex 原生或 CLI 工作者： codex-cli.md，涵蓋提供者選擇、相容的 CLI/認證、有效的模型/推理努力、獨立工作階段、持久的呼叫記錄、精確的恢復、核准處理與會計。
scripts/codex_worker.py執行歸屬的 Codex CLI 呼叫。 - ChatGPT Pro 諮詢： chatgpt-pro.md，涵蓋問題建構、原生應用程式傳訊、瀏覽器設定/備援、GitHub/雲端硬碟、提交核准與使用者觸發的檢索。
- ChatGPT 對話存取或 CLI/應用程式互通性： chatgpt-app-tools.md，涵蓋舊有與封存對話的檢索、原生清單/讀取/傳送、模型選擇、建立/刪除邊界、Markdown 匯出、過時讀取以及受保護的桌面橋接。
- 技術資訊圖表： chatgpt-infographics.md，涵蓋使用 Extra High 模式的 ChatGPT 網頁、內容優先的圖片簡報、協調的圖片系列以及視覺驗證。這是當詳細的資訊圖表適合任務時，使用者偏好的選項。
除非使用者或任務選擇 Codex，否則 Claude 是預設的工作者提供者。保留明確的提供者選擇。Codex CLI 是在獲得授權時可用的獨立工作階段路線；它不豁免帳戶、沙箱、資料或支出限制。助手會停用遞迴委派；一個單獨授權的 CLI 協調器需要其自己的綁定政策。
不要將 Pro 諮詢透過 Claude 執行器路由，不要以 API 呼叫取代使用者的 ChatGPT 訂閱，也不要建立使用者擁有的 Codex 對話來執行 Claude 工作者。Claude 工作者是外部的 CLI 程序。不要無聲無息地以原生 Codex 子代理取代指定的提供者；這會消耗此工作流程旨在節省的 Codex 容量。
對於已選取 Pro 的現有 ChatGPT 對話，偏好使用原生 mcp__codex_app__send_message_to_thread 而非瀏覽器提交；在使用者表示準備就緒後，使用 read_thread 檢索文字。瀏覽器互動是設定或備援路線，並非詢問 Pro 問題的先決條件。必須為該特定對話建立 ChatGPT 模型選擇：傳訊工具的 model 和 thinking 覆寫僅適用於 Codex。請閱讀連結指南以了解功能與時效性限制。
結束回合並在必要時繼續
Codex 應用程式可以透過 mcp__codex_app__automation_update 搭配 kind: "heartbeat"，在同一個對話中安排後續追蹤。首先檢查當前脈絡中提供的工具；這是一個可用的編排選項，並非每次等待時都需要重新發現。當一個已授權的工作流程正在等待長時間的 Claude 或 Codex 任務，或等待配額重置，且沒有有用的獨立工作可做時，使用排程繼續可以節省父代理的注意力和使用量。短暫等待可以保持在活躍回合中。
- 儲存一個持久的檢查點：目標、相關路徑與修訂版本、歸屬的工作者執行目錄、已完成的工作、要檢查的條件以及確切的下一步行動。確認任何正在執行的任務在回合結束後仍然存活；僅儲存狀態檔案並不能確保程序的持續性。恢復的工作使用屆時可用的權限，而非假設回合範圍的授權會持續。
- 使用當前對話的心跳，在已有相符的後續追蹤時重複使用。選擇一個有用的節奏或已知的重置時間，而非頻繁的猜測性檢查。在結束回合前確認排程成功，並告訴使用者什麼會讓工作繼續進行。如果工具不可用或失敗，不要聲稱已安排自動返回。遵循工具的當前架構；不要發明自動化指令，或以獨立的 cron 任務取代對話的後續追蹤。
- 儲存的提示應檢查實際的工作者狀態或已更新的配額，僅在條件滿足時繼續，否則保持靜默，除非出現失敗或需要使用者操作。完成或取消時，移除或停用後續追蹤。這些是排程檢查，而非任意的即時事件觸發器；每次執行都會消耗使用量。本地繼續需要機器與應用程式保持可用。
Pro 仍然是例外： 只有當使用者說準備好時，才會檢索其答案。不要透過此通用繼續政策來排程 Pro 檢查，或改變其核准與發射後不理協定。
維持區別
Claude： 定義目標、輸入、擁有的檔案、限制條件，以及一個附帶可負擔驗證步驟的具體輸出。UI 檢查與長期稽核應返回由本地證據支援的簡潔發現，避免第二次詳盡的父代理檢查。
Codex： 定義相同的具體工作者合約，保留所選的模型與推理努力。對於合適的當前對話子任務，偏好使用原生子代理；當請求或需要其生命週期時，使用已授權的獨立 CLI 工作階段。驗證有效的原生記錄、實際的歸屬程序以及精確的工作階段連續性。單獨的配置限制、零退出碼或已儲存的狀態檔案，不能證明接納、持久性或正確性。
資訊圖表： 使用 Extra High 模式的 ChatGPT 網頁，絕不使用 Pro。明確要求它生成一個或一系列連貫的影像。在美學細節之前提供完整的技術內容；對照原始來源檢查渲染結果。Pro 特殊的提交關卡與發射後不理協定是 Pro 特有的，不會自動適用於此路線。
Pro： 從一個真正困難且未解決的問題，以及其答案將影響的關鍵選擇開始。父代理有責任提出尖銳、具體的問題，超越常規建議。成品格式是次要的，回答問題才是主要的。提供已知事實、競爭方法、假設與限制，同時保留挑戰問題框架的空間。對於一個連貫的研究問題，準備一份初始簡報，賦予 Pro 完整調查的擁有權，以及完成調查所需的授權證據。遵循 chatgpt-pro.md 中的問題品質指南與實際範例；不要將諮詢變成工作者的檢查清單或預先決定的結論。
對於真正的獨立審查，使用全新的脈絡。提供需求、成品、相關假設與基本理由，但不附帶預期結論或實作者的自評。在協作式的 Pro 諮詢中，分享我們暫定的推理與不確定性是有幫助的；不要將此對話與盲審混淆。
Pro 核准與發射後不理協定
使用者明確要求在每次提交 Pro 前（包括後續問題）進行核准。廣泛的委派授權不豁免此特定規則。首先準備實際問題與成品連結，解釋你提議詢問的內容，並讓使用者批准該具體提交。未經核准，不得重新提交或將已核准的問題替換為有實質差異的問題。對於已核准確切問題與材料的同一提交，不要再次請求。
核准後，在可用時透過原生應用程式工具傳送一次，確認提交已被接受，保留對話 ID/URL 與輸入快照，並告知使用者已傳送。接受不等於回應完成。絕對不要等待 Pro 的回答、輪詢完成、排程監控或發送進度提示。 繼續進行授權的獨立工作或返回控制權。使用者會在答案準備好時告訴你；那才是觸發檢索與審查的時機，最好透過原生閱讀器。任何後續傳送給 Pro 的訊息都需要自己的核准。如果使用者日後明確更改此協定，則遵循其指示。
此核准是用戶指令，而非推斷的技能預防措施。請求核准時，請引用規則「每次提交 Pro 前需核准」，命名並連結此技能，並簡短說明其來源；例如：「根據您的要求，在將此問題傳送給 Pro 之前，我需要您的核准。」請求許可應使用可用的提問工具或放在最終回應中，而非中介步驟。