Craft Codex Prompts
目標
將不完整的上下文轉換為一個任務套件，讓另一個 Codex 對話可以執行，而不將衍生的解釋視為事實。優化目標：來源忠誠度、權限邊界、可測試完成度以及低提示詞負擔。
選擇操作
- 起草 (Draft)：從檔案、專案上下文或粗略請求建立提示詞。
- 審查 (Review)：診斷現有提示詞的缺點，然後產出修訂版本。
- 交接 (Handoff)：將先前的工作、結果和未解決問題轉換為下一個可執行的提示詞。
- 知識循環 (Knowledge loop)：產出可供知識庫使用的當前狀態、決策、待解決問題和交接更新。
如果使用者只要求一個提示詞，則僅回傳提示詞加上必要的假設。如果他們要求可重複使用的工作流程，則回傳完整的任務套件。
工作流程
1. 建立來源與權限
在授權且有幫助的情況下，於起草前以唯讀方式檢查使用者提供的檔案和可存取的專案素材。在僅準備提示詞時，請勿修改來源專案。
分類輸入：
- 一級事實 (Primary facts)：當前檔案、儲存庫狀態、明確的使用者陳述、權威專案文件。
- 衍生上下文 (Derived context)：摘要、先前的助手結論、報告以及複製的對話。
- 未知項 (Unknowns)：遺失的檔案、未驗證的運行時狀態、未解決的選擇以及外部依賴。
將衍生上下文視為線索，而非證據。明確說明執行中的對話必須根據一級來源進行驗證。
不要假設附加到一個對話中的檔案在另一個對話中也可用。指定執行對話必須接收的每個檔案或確切的工作區。
2. 識別任務類型
選擇最接近的任務類型：
- 回答或解釋；
- 檢查或審查；
- 診斷；
- 變更或建置；
- 研究或比較；
- 建立一個成品；
- 執行一個外部動作。
保留匹配的權限邊界。分析或診斷的請求不授權編輯。變更或建置的請求通常授權範圍內的實作與驗證，但不授權不相關的重構、發布、訊息傳遞、提交、推送或破壞性動作。
請參閱 任務藍圖 以了解匹配的任務模式。
3. 分離穩定規則與任務差異
將持久的專案規則放入專案合約中，例如 AGENTS.md、PROJECT_BRIEF.md 或 CODEX_TASK_CONTRACT.md。讓當前的提示詞專注於本次變更的內容。
僅在此規則關乎安全或很可能被遺漏時，才在任務提示詞中重複穩定的規則。
4. 按比例解決模糊性
僅當答案會實質改變範圍、來源選擇、不可逆行為、外部影響或驗收標準時，才提出澄清問題。否則，選擇最安全的合理假設並標明其為假設。
切勿將遺失的來源、不支援的功能或外部阻礙隱藏在自信的措辭中。
5. 組成任務套件
在相關時建立以下章節：
- 結果 (Outcome)：一個具體的最終狀態。
- 真相來源 (Source of truth)：確切的檔案、路徑、資料或使用者決策。
- 當前狀態 (Current state)：僅限已驗證或明確歸因的事實。
- 範圍 (Scope)：允許的讀取、編輯、系統和成品。
- 非目標 (Non-goals)：可能但未授權的擴展。
- 鄰近檢查 (Adjacent checks)：可能暴露相同缺陷的下游表面。
- 執行指引 (Execution guidance)：影響正確性的限制，而非揣測的實作細節。
- 驗收標準 (Acceptance)：可觀察的檢查和預期的證據。
- 阻礙與停止條件 (Blockers and stop conditions)：需要回報而非猜測的條件。
- 交付 (Delivery)：變更的檔案、成品、證據、限制以及下一次交接。
當涉及實作時，使用 L1-L4 驗證階梯：
- L1：語法、匯入、結構或靜態驗證；
- L2：單元測試、服務測試或聚焦的回歸測試；
- L3：真實檔案或端到端資料路徑驗證；
- L4：實際 UI、封裝運行時、裝置、類生產環境或人工驗收。
不要將較低層級的驗證呈現為較高層級的證明。
包含此來源忠誠度條款，並根據任務進行調整：
將此提示詞視為執行簡報，而非儲存庫狀態的證明。請根據當前工作區和一級檔案驗證其宣稱。如果發生衝突，請保留來源素材、回報衝突，並遵循一級來源，除非使用者另有決定。
6. 保持提示詞可執行
- 以結果開頭。
- 使用直接的指令和具體的名詞。
- 偏好檔案名稱、路徑、計數和預期成品，而非形容詞。
- 除非確切的措辭本身就是證據，否則避免複製原始對話。
- 除非使用者已確定該選擇，否則避免在檢查之前規定架構。
- 將禁止事項限制在實際可能發生的失敗模式。
- 說明 Codex 應該僅回報、診斷、實作、還是實作並驗證。
- 以緊湊的完成格式結尾。
7. 交付前審計
根據六項檢查對提示詞進行內部評分：
- 忠誠度 (Fidelity)：每個事實性宣稱是否可以追溯到來源？
- 權限 (Authority)：讀取、編輯、外部動作和禁止動作是否明確？
- 完整性 (Completeness)：是否涵蓋了可能的相鄰使用者和失敗路徑？
- 可測試性 (Testability)：能否透過可觀察的證據證明完成？
- 可行性 (Feasibility)：是否揭露了不可用的工具、運行時限制和人類依賴？
- 簡潔性 (Brevity)：每個指令是否都會改變執行或驗證結果？
回傳一個狀態：
READY：可在現有上下文中執行；READY_WITH_ASSUMPTIONS：在列出有限假設後可執行；NEEDS_INPUT：缺少一個或多個重大選擇；BLOCKED_SOURCE_MISSING：所需的一級素材不可用。
不要為了讓提示詞看起來更嚴謹而將其膨脹。
8. 關閉知識循環
當使用者將工作歸檔到 Obsidian 或其他知識庫時，請閱讀 obsidian-loop.md。將不可變的原始對話與當前的專案真相分開保存。執行後，更新當前狀態、決策、未解決問題以及交接事項，而不是僅依賴對話記錄。
預設輸出
除非使用者要求其他格式，否則回傳：
## TASK_BRIEF
[已驗證的事實、假設、未知項、來源]
## MAIN_PROMPT
[可供複製的提示詞]
## PROMPT_STATUS
[READY, READY_WITH_ASSUMPTIONS, NEEDS_INPUT, 或 BLOCKED_SOURCE_MISSING]
[簡短說明及任何必要的附件]
對於提示詞審查，請在 MAIN_PROMPT 之前加上簡短的 KEY_GAPS 章節。請勿暴露私密的思考鏈；請提供簡潔、與決策相關的理由。