Handoff 是做什麼的？
關閉工作階段，將進度寫入磁碟中的交接檔，讓下一個階段能從中斷處精確恢復。請用此技能取代 /compact，切勿同時使用。
為何不使用 /compact
/compact 為了撰寫摘要會重新讀取整段對話紀錄，然後取代整個歷史記錄。這會改變提示詞前綴，使得已經建立的快取失效，從此之後每個回合都得在一個僅有四十個回合的摘要上重建快取。它並沒有節省成本，只是以效率換取連續性。
交接檔則在三個方面提供相反的好處：
- 成本更低。 檔案僅需數百個 token 進行寫入與讀取，新階段從一個乾淨簡潔的提示詞前綴開始。
- 使用者決定保留哪些資訊。
/compact會自行決定丟棄最有價值的內容——那些已經嘗試過但失敗的路徑。沒有任何自動摘要能保留它們。 - 保留在磁碟上。 針對同一專案的第三個階段能夠知道前兩個階段做了什麼。而
/compact的生命週期僅限於其所在的階段。
操作程序
1. 自行重建資訊，不要詢問你已經看得到的內容。 修改了哪些檔案、嘗試過什麼、為何失敗、做了哪些決定、進度停在何處——這些資訊都存在於對話之中。若在 git 儲存庫中，請加上 git status --short 與 git log --oneline -5。
2. 僅詢問你無法推斷的兩個缺口。 這包括目標（正在建構什麼以及為何建構，而非今天做了什麼）以及期望的下一步，它不一定是顯而易見的那個步驟。如果缺少這些資訊，請用一個問題同時詢問，並在問題中附上你的假設，這樣對方只需回答「是」即可。其餘所有內容無需詢問：如果某個章節沒有內容，就寫「無」並繼續，不要憑空創造不存在的已解決問題。
3. 決定儲存位置。 在程式碼儲存庫中：docs/handoff/{YYYY-MM-DD}-{slug}.md。在筆記儲存庫或資料夾中（例如本專案 il-tuo-os）：在該專案所屬的目錄下建立 handoffs/ 資料夾。{slug} 應為兩到三個關於該工作內容的單詞，而非日期。如果已存在相同 slug 的交接檔，請勿覆蓋：新檔案應遞增 seq 欄位，並將前一個檔案記錄在 prev 中，這樣就可以回溯整個鏈結。
4. 撰寫檔案，包含以下 frontmatter — type: handoff、date、status、seq、prev、tags — 以及以下章節，按此順序排列：
- 目標：正在建構什麼以及為何建構，兩到三行，需包含理由。
- 目前進度：當前的真實狀態。哪些功能正常運作、哪些尚未完成、哪些尚未開始。
- 已嘗試但失敗的方案：這是檔案中最重要的章節。列出每一條被放棄的路徑及其原因，以防止後續階段再次重複嘗試。
- 遇到的問題與解決方式：只記錄那些可能會再次發生的問題。症狀、原因、修正方法。
- 已做出的決策：選擇了什麼以及放棄了什麼，並附上一行說明原因。沒有記錄被放棄選項的決策，一週後會需要從頭討論。
- 修改過的檔案：檔案路徑，以及每個檔案變更內容的一行說明。
- 下一步方向：以祈使句寫出下一步行動。如果已經明確，再寫出後續的步驟。
- 開始工作前須知：陷阱、需要以特定方式執行的命令、看似故障但實則正常的現象。如果沒有任何此類事項，請寫「無」。
5. 結束時在對話中輸出恢復指令，以便在新階段中直接複製貼上：讀取 {檔案路徑} 並從「下一步方向」恢復。。再另起一行說明此時可以執行 /clear，並且恢復時僅需讀取該檔案。
何時不使用
一個永遠都在使用的技能，就是一個被隨意使用的技能。
- 切換任務且無連續性 → 使用
/clear，無需任何交接檔。 - 最後幾步走錯了方向 → 使用
/rewind，回到快取已知的某個點。 - 短時間內恢復且中間無更新 → 使用
/rename加上/resume。 - 工作將在另一天或另一週繼續 → 使用此技能。
此技能不會代替使用者執行 /clear：它只會建議這麼做。