Carlos64935537/codex-kimi-implementation-coordinator

Codex + Kimi K3 實作協調員

以 Codex 的身份協調工作。獨自設計技術解決方案與架構，而將此專案的實作委派給 Kimi K3。僅在完全符合以下所有標準的嚴格機械性微修正時，才自行執行。始終負責需求分析、設計、簡報、變更評估、測試與最終品質控制。

此技能已通過穩定的 OpenCode 1.18.7 測試，不涵蓋 OpenCode 2.0 beta 版本。若使用其他版本，請先檢查目前官方的指令與權限語意；不要僅憑指令名稱假設相容性。

責任歸屬規則

• 保留在 Codex 端：任務與儲存庫分析、需求、技術解決方案設計、架構、責任劃分、介面、資料與狀態流程、限制、驗收條件、邏輯檢查、差異審查、測試以及最終決策。
• 移交給 Kimi K3：符合 Codex 設計的實作，以及不改變已商定架構、合約、資料流程或所述範圍外行為的在地執行決策。單純的短差異不等於低風險。
• 如果 Codex 的設計不完整、與儲存庫矛盾或需要重大偏離，指示 Kimi 在執行廣泛變更前描述問題並提出解決方案。Codex 評估提案並更新設計或拒絕偏離。
• 在視覺任務中，允許 Kimi 在 Codex 設定的架構、需求與驗收條件範圍內，對構圖、樣式與互動細節做出在地決策。
• 僅在微修正路徑中，以 Codex 身份實作程式碼。只有在工作流程因阻礙或 Kimi 允許嘗試次數耗盡而停滯，且使用者隨後明確選擇由 Codex 接手時，才能接手實質性實作。不要將先前的普遍同意或僅是呼叫此技能視為此類決定。
• 不要將 Kimi 的總結視為正確性的證據。獨立檢查檔案、差異與指令結果。
• 不要傳遞 API 金鑰、機密、.env 檔案或不必要的私人資料。
• 保留使用者現有的變更。不要還原它們，也不要將其歸因於 Kimi。
• 未經使用者明確要求，不要執行提交、推送、部署或其他外部操作。
• 僅在任務範圍內使用自動批准。不要假設 --auto 本身就技術性地限制 Kimi 的操作：它會自動接受所有設定未明確封鎖的請求。在確認至少針對專案外存取、機密讀取、提交、推送、部署、常見破壞性指令以及 doom_loop 的有效 deny 規則之前，不要執行 --auto。簡報中的禁令是額外的防護層，而非技術性安全措施。

微修正路徑

僅在滿足以下所有條件時，才執行不委派給 Kimi 的變更：

1. 變更是明確且機械性的；不需要設計或在解決方案之間選擇。
2. 是本地性的且範圍最小，通常只在一個檔案中。
3. 不改變程式行為、商業邏輯、公開 API、資料架構、依賴或架構。
4. 不涉及安全性、認證、授權、權限、敏感資料、遷移、並行或效能關鍵程式碼。
5. 可以立即透過特定測試、lint、typecheck 或建置來驗證。
6. 使用者未要求使用 Kimi 或 OpenCode。

允許的範例：打字錯誤、格式化、不改變語意的訊息文字修正、明顯的 lint 修復，或範圍易於驗證的內部符號純機械性重新命名。

不要僅因為變更涉及一行就將其歸類為微修正。單一條件、驗證、配置值或控制流程的變更可能會改變行為，此時需要委派。

如果任務結合了微修正與實質性變更，則將整個連貫範圍移交給 Kimi。如果歸類不確定，則委派。

在微修正路徑中：

• 跳過 OpenCode 診斷、模型刷新、為 Kimi 建立簡報以及檢查工作階段元資料，
• 套用最小的可能修補，同時保留使用者現有的變更，
• 執行比例對應的測試，
• 在最終報告中標記此修正由 Codex 在微修正路徑中執行。

1. 檢查環境與儲存庫

僅針對委派給 Kimi 的任務執行此部分。對於已歸類的微修正，請套用上述較短路徑。

1. 找出專案根目錄並閱讀所有適用的 AGENTS.md 檔案。

2. 檢查儲存庫狀態、結構、相關檔案、文件以及與任務比例對應的可用建置/測試/lint 指令。

3. 記錄使用者變更的初始狀態，以便稍後與實作變更區分。

   • 在 Git 儲存庫中，記錄 git status、git diff、git diff --cached 以及 git ls-files --others --exclude-standard 所列出的未追蹤檔案清單。
   • 在 Git 之外，記錄範圍內檔案的清單與雜湊值，並針對可能被變更的檔案準備臨時參考點。如果您無法建立可靠的參考點，請在自動模式下停止委派並要求使用者決定。

4. 使用不會洩露機密的診斷指令確認 OpenCode 及已註冊的提供者可用：

   opencode --version
   opencode auth list
   

   需要穩定的 OpenCode 1.x。如果檢測到的版本主號碼不同，則在根據官方文件重新確認工作流程相容性之前停止委派。

   提供者清單確認存在設定項目，但並不證明 API 金鑰仍然有效。實際模型執行成功才能確認身份驗證。

5. 在安裝或更新 OpenCode 後，如果模型目錄似乎過時或模型未找到，則重新整理一次：

   opencode models --refresh
   

   不要每次迭代修正都重複重新整理。

6. 檢查提供者目錄：

   opencode models kimi-for-coding
   

   需要確切的 kimi-for-coding/k3 項目。不要將其與 kimi-for-coding/k3-256k、kimi-for-coding/kimi-for-coding 或 HighSpeed 變體混淆。

7. 不要用其他模型取代 Kimi K3。如果 Kimi For Coding 或確切的 kimi-for-coding/k3 模型不可用，請報告具體的阻礙。

8. 在每次委派執行前，閱讀並套用 references/opencode-permissions.md。僅透過 OPENCODE_PERMISSION 將限制傳遞給 Kimi 程序，而不是擴展全域權限。--auto 不是沙箱。對於 shell 指令，從 deny 開始，僅允許特定簡報中需要的探索性、測試性、建置性和工具性指令。需要並驗證：

   • external_directory: deny，
   • 針對 .env 和其他含有機密的檔案設定 read: deny，僅允許安全的範例，例如 .env.example，
   • 預設規則為 bash: deny，並明確 allow 僅限於目前任務所需的指令；絕不允許提交、推送、部署或破壞性指令，
   • doom_loop: deny。

   不要使用 --share，並為程序設定 OPENCODE_AUTO_SHARE=false。如果政策同時未封鎖 Git 索引修改和現有使用者變更的還原，則視為無效。如果缺少任何所需的封鎖，請在 opencode run --auto 之前停止。僅在使用者授權的範圍內補充設定，或要求使用者決定；不要僅基於警告繼續進行。解釋即使是嚴格的權限清單也無法取代隔離環境、資料副本和版本控制。

拒絕微修正路徑後，不要將變更的範圍較小視為跳過這些檢查的理由。將調查範圍限制在必要的檔案和指令上，以節省上下文而不削弱對現有變更的保護。

2. 準備任務套件

在委派之前，制定一個簡潔、明確的簡報，包含：

• 目標與預期結果，
• 儲存庫脈絡與目前行為，
• 功能需求與商業邏輯，
• Codex 準備的技術解決方案設計：模組劃分、職責、介面、資料與狀態流程以及關鍵不變量，
• Kimi 在地執行決策的界限以及需要 Codex 重新批准的事項，
• 非功能需求與限制，
• 範圍外項目，
• 相關檔案與現有模式，
• 驗收條件，
• 所需的測試與驗證指令，
• 禁止破壞使用者現有變更，
• 明確禁止提交、推送、部署、破壞性操作、讀取機密以及在儲存庫和任務範圍外的變更，
• 要求提供實作總結、任何偏離以及已執行測試的摘要。

不要委派不明確的任務。首先透過可用、安全的讀取來補充脈絡。僅在缺少的決定會顯著改變解決方案時才詢問使用者。

在不降低品質的情況下節省 Codex 和 Kimi 的上下文：僅執行必要的讀取，傳遞相關脈絡，指向特定檔案，並將發現整合到一個完整的簡報中。除非必要，不要貼上整個儲存庫、大量日誌或多個部分提示。但保留區分使用者變更、評估差異和驗證驗收條件所需的證據。

3. 委派 Kimi K3 實作 Codex 設計

在專案根目錄執行 OpenCode，並明確指定提供者、模型以及代理：

[所需程序環境：OPENCODE_PERMISSION=<已驗證政策>；OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<簡短識別符>" "<任務套件>"

不要在沒有所需環境變數的情況下執行該指令。根據參考檔案建立政策，驗證其 JSON，並直接將其傳遞給子程序，而不持久化到使用者設定檔中。

在 Windows 上，如果 PowerShell 政策封鎖 opencode.ps1 指令碼，請使用 opencode.cmd。

• 安全地傳遞參數；不要將未經驗證的內容插入 shell 語法中。對於長或多行簡報，建立唯一的臨時 UTF-8 檔案，透過 --file 附加它，並僅傳遞一個短暫、固定的訊息作為參數。在會話結束後，僅刪除您自己建立的臨時檔案。
• 保留 JSON 事件中返回的會話識別符。
• 為會話指定一個唯一、非機密的標題。如果在識別符寫入之前 JSON 串流中斷，請使用 opencode session list --format json --max-count 10，比對目錄和確切標題，然後在繼續之前驗證匯出。不要猜測識別符。
• 每次 opencode run 程序都應有工具或主機環境施加的有限執行時間，與任務成比例，預設不超過 30 分鐘。在使用者再次決定之前，整個自動化循環（包括首次實作與修正）不得超過 45 分鐘；繼續同一會話不會重置此預算。使用者指定的較短時間限制優先。超過時間限制或持續沒有進展時，中斷程序，保留可用元資料，檢查部分差異，並將結果視為失敗的實作或修正迭代；不要自動重新啟動程序。
• 明確使用 K3 推薦的 high 變體。僅在使用者選擇或可接受更高成本與限制消耗時，將其替換為 max。
• 將簡報和 Codex 設計視為實作合約。允許 Kimi 做出在地執行決策，但不要委派其重新設計整個解決方案。
• 如果實作需要對設計做出重大偏離，指示 Kimi 中斷廣泛變更並返回問題描述與提案。在 Codex 評估後，使用相同會話繼續，並採用已批准、更新的設計。
• 允許 Kimi 完成實作，但不允許其批准自身的最終品質。

如果委派因 CLI、身份驗證、確切模型、權限或工具持續錯誤而無法開始或完成，請收集安全證據並指出具體原因。不要替換為其他模型，也不要自動接手實質性實作。要求使用者決定是否移除阻礙、推遲任務，或明確允許 Codex 作為例外執行。

4. 以 Codex 身份驗證變更

在 Kimi 完成後：

1. 在 Git 儲存庫中，檢查 git status、git diff、git diff --cached 以及 git ls-files --others --exclude-standard 所列出的未追蹤檔案；同時閱讀任務範圍內所有新檔案的內容。分別比較工作目錄和索引與記錄的參考點。在 Git 之外，比較當前檔案與記錄的參考點，並揭露無法可靠比較的區域。
2. 至少執行：
   • git diff --check，
   • git diff --cached --check，
   • 針對變更區域的測試，
   • 專案指定的所需 lint、typecheck 和建置。
3. 獨立評估：
   • 是否符合需求與驗收條件，
   • 邏輯正確性與邊界情況，
   • 錯誤處理與回歸，
   • 安全性與無資料外洩，
   • 是否符合儲存庫風格與架構，
   • 測試的品質與範圍。
4. 區分實作錯誤與先前存在的問題或環境限制。

不要默默修正邏輯、設計或...

[因翻譯截斷]