我作為一個用了 Codex 接近兩年的用戶。

在工作的過程中，整理了一些值得分享的 Skill。我認為它們很有價值，也很值得公開分享。

這些 Skill 怎麼來？

它們不是一開始就被設計出來的，而是我不斷觀察自己的行為：我如何糾正模型的工作，如何把模型拉回正確軌道，如何把一次次有效的干預提煉成可以重複使用的流程。

對我來說，方法論先存在於工作過程裡。當一個介入方式被反覆驗證有效，它就應該被固定成 Skill，讓模型下次在相似場景裡自動走對的路。

所以我把最近真實使用過的一批 Codex workflow 抽出來，整理成公開 repo：qoli/codex-workflow-skills。這裡不是一包 prompt，而是 6 個可以安裝的 Skill，用來處理上下文恢復、除錯紀律、文字改稿，以及小紅書內容交付。

我怎麼定義一個有效 Skill

我後來用四個問題判斷一個 Skill 是否值得沉澱：

• 觸發條件：什麼情境下應該使用它。
• 觀測順序：執行時應該先看哪些證據，而不是直接猜。
• 安全邊界：哪些行為必須明確禁止，例如洩漏 transcript、提交 .env、自動按下發布。
• 完成驗證：怎樣才算真的做完，而不是只產生一段看似合理的回答。

這樣寫出來的 Skill 就不只是一段 prompt，而是一個可重複執行的工作流。這次公開的 6 個 Skill 都是從實際任務裡留下來的；它們不是為了展示而寫，而是在我反覆遇到同類問題後，被固定成更可靠的流程。

1. 找回上下文：不要讓跨天任務重新開始

第一組是上下文恢復：codex-conversation-lookup 和 codex-session-distill-search。

案例：三天前的任務，不要重新解釋一遍

我給你一段舊 Codex 對話：《修正數據庫 v2 部署辦法》。
先用 codex-conversation-lookup 讀懂這段任務：它在哪個 repo、做到哪一步、
有沒有中斷或未提交變更。不要貼 transcript，給我一張可接續的路線圖。

這就是 codex-conversation-lookup 的典型場景。它的重點不是把舊對話全文貼出來，而是把 thread 轉成一張可接續的路線圖：

• 這段任務在哪個 repo / cwd 發生。