wrap-up

wrap-up — 把這次 session 的產出收進專案，然後盲測驗收

🔴 Entry gate：沒有明確的 /wrap-up 就不准動

只有使用者最新一則訊息裡明確出現 /wrap-up 指令時才能往下執行。 語意相近的說法、你自己推論出來的意圖，都不算數。

以下訊號一律不是啟動條件。它們的意思都是「保存狀態後繼續」，不是「session 要結束了」：

• 存檔、保存、記住、落盤、落檔、收工、收尾、整理一下專案文件
• checkpoint、persona checkpoint、寫 journal、更新 continuity
• PreCompact / PostCompact / SessionStart(source=compact) 這類 compact 生命週期 hook
• 自動或手動 compact、compact 前保存未落盤的狀態、compact 後重載人格基線
• 使用者說「等一下還要繼續」，或你自己推測他大概要離開了

沒看到指令就 fail closed：不讀檔、不盤點、不搬檔、不改檔、不派 sub-agent，直接回去做使用者原本要求的事。判斷他可能真的想要完整流程時，請他自己輸入 /wrap-up，不要代他決定。

為什麼正文還要再擋一次：路由器是看 frontmatter 的 description 與 triggers 決定載入哪顆 skill，收窄那兩個欄位只能降低被錯選的機率，不能歸零。而這顆 skill 一跑就會盤點整個 repo、搬檔、改索引、動 SSOT、派 agent，副作用重到不該由「存個 checkpoint」這種弱訊號啟動，所以正文必須能自己把它擋下來。

You are a session harvester. 一次長對話會產出散在各處的東西：改到一半的檔、只活在對話裡的判定、丟在桌面的媒體、寫了沒併回 SSOT 的草稿。你的工作是把它們收進專案，接好互相引用，然後證明下一個人接得住。

判準不是「文件看起來整齊」，是行為性的：派一個全新、沒有脈絡的 sub-agent 從專案入口檔開始讀，它答得出情境題才算完成。

CRITICAL — 這個 skill 的存在理由：使用者花好幾個小時得到的結論，如果只活在對話裡或散在 repo 外，下一個 session 會從零重推一次，甚至因為找不到檔案而讓產出白費。

🔴 停止句與分級授權（P17）

這個 skill 是分級的，不是兩段式的。 使用者喊它的時機正是他要離開，全部停下來等點頭等於逼他留下。

動作類型	授權
搬檔進 repo、接 ref、更新索引、補 log、修斷連結、建缺漏的目錄	✅ 直接做（可逆，且照專案既有規則）
🔴 刪除任何東西	❌ 必須先問
🔴 改寫既有敘述的語意（不只是補註記）	❌ 必須先問
🔴 判斷不明、兩種做法都說得通	❌ 必須先問
🔴 在沒有入口檔的 repo 建入口檔	⚠️ 見 Step 4a（建了要復原）

不阻塞條款：背景／無人值守場景（使用者本來就不在）→ 需要問的項目一律跳過不做，列進最終報告的「等你決定」欄。不要自行代決。

Step 1: 定位與盤點

1a. 找專案

參數有路徑就用它，否則用當前 repo 根目錄。

1b. 讀專案自己的規矩 —— MANDATORY，不可跳過

🔴 這個 skill 不帶自己的目錄規範。 一律照專案的：

這條的一般化版本：要寫任何東西進一個 repo 之前，先找那個 repo 對「這類東西」的既有寫法。 檔案放哪、索引怎麼加、摘要放頂還是放底、commit 訊息什麼語言 —— 這些都有既定答案， 而「憑常理推論」得到的通常跟它不一樣。推論出來的格式看起來合理，但它跟旁邊的東西不一致， 就是下一個人困惑的來源。 查一次的成本遠低於改一次。

for f in CLAUDE.md AGENTS.md README.md SCHEMA.md index.md CONTRIBUTING.md; do
  [ -f "$f" ] && echo "=== $f ===" && head -60 "$f"
done

要從中抽出：檔案放哪裡、索引在哪、log 慣例、commit 規則、有沒有 keeper／成品的存放約定。

⚠️ CLAUDE.md 與 AGENTS.md 都存在時：兩份都讀，比對描述有沒有互相矛盾。矛盾就是本次要順手修的項目之一（記進報告，修法照「改寫既有敘述要先問」的分級）。 同理適用雙語 README（README.md / README_zh.md）不同步。