name: wrap-up\ndescription: \"Use ONLY when the user's latest message explicitly contains the /wrap-up command. Harvests everything a long session produced into the project following that project's own rules — moves stray media in, wires two-way refs, updates indexes, merges drafts into SSOT — then dispatches a context-free sub-agent to blind-test the docs from the project's entry file. NEVER load on inferred intent. Explicitly NOT for: save / checkpoint / persona-continuity requests, memory or journal updates, compact lifecycle hooks (PreCompact, PostCompact, SessionStart(source=compact)), automatic or manual compaction, or any guess that the session is ending — those all mean 'save state and keep going', while this skill has heavy side effects (moves files, rewrites indexes, edits SSOT, spawns sub-agents). If the user seems to want the full flow, ask them to type /wrap-up instead of assuming. NOT a documentation linter (that is llm-wiki-lint / memory-lint) and NOT for tidying a project you did not just work on.\"\nversion: 0.2.0\nstatus: experimental\ntriggers:
/wrap-up 就不准動只有使用者最新一則訊息裡明確出現 /wrap-up 指令時才能往下執行。 語意相近的說法、你自己推論出來的意圖，都不算數。
以下訊號一律不是啟動條件。它們的意思都是「保存狀態後繼續」，不是「session 要結束了」：
\nPreCompact / PostCompact / SessionStart(source=compact) 這類 compact 生命週期 hook沒看到指令就 fail closed：不讀檔、不盤點、不搬檔、不改檔、不派 sub-agent，直接回去做使用者原本要求的事。判斷他可能真的想要完整流程時，請他自己輸入 /wrap-up，不要代他決定。
\n\n為什麼正文還要再擋一次：路由器是看 frontmatter 的
\ndescription與triggers決定載入哪顆 skill，收窄那兩個欄位只能降低被錯選的機率，不能歸零。而這顆 skill 一跑就會盤點整個 repo、搬檔、改索引、動 SSOT、派 agent，副作用重到不該由「存個 checkpoint」這種弱訊號啟動，所以正文必須能自己把它擋下來。
You are a session harvester. 一次長對話會產出散在各處的東西：改到一半的檔、只活在對話裡的判定、丟在桌面的媒體、寫了沒併回 SSOT 的草稿。你的工作是把它們收進專案，接好互相引用，然後證明下一個人接得住。
\n判準不是「文件看起來整齊」，是行為性的：派一個全新、沒有脈絡的 sub-agent 從專案入口檔開始讀，它答得出情境題才算完成。
\nCRITICAL — 這個 skill 的存在理由：使用者花好幾個小時得到的結論，如果只活在對話裡或散在 repo 外，下一個 session 會從零重推一次，甚至因為找不到檔案而讓產出白費。
\n這個 skill 是分級的，不是兩段式的。 使用者喊它的時機正是他要離開，全部停下來等點頭等於逼他留下。
\n| 動作類型 | \n授權 | \n
|---|---|
| 搬檔進 repo、接 ref、更新索引、補 log、修斷連結、建缺漏的目錄 | \n✅ 直接做（可逆，且照專案既有規則） | \n
| \uD83D\uDD34 刪除任何東西 | \n❌ 必須先問 | \n
| \uD83D\uDD34 改寫既有敘述的語意（不只是補註記） | \n❌ 必須先問 | \n
| \uD83D\uDD34 判斷不明、兩種做法都說得通 | \n❌ 必須先問 | \n
| \uD83D\uDD34 在沒有入口檔的 repo 建入口檔 | \n⚠️ 見 Step 4a（建了要復原） | \n
不阻塞條款：背景／無人值守場景（使用者本來就不在）→ 需要問的項目一律跳過不做，列進最終報告的「等你決定」欄。不要自行代決。
\n參數有路徑就用它，否則用當前 repo 根目錄。
\n\uD83D\uDD34 這個 skill 不帶自己的目錄規範。 一律照專案的：
\n\n\n這條的一般化版本：要寫任何東西進一個 repo 之前，先找那個 repo 對「這類東西」的既有寫法。\n檔案放哪、索引怎麼加、摘要放頂還是放底、commit 訊息什麼語言 —— 這些都有既定答案，\n而「憑常理推論」得到的通常跟它不一樣。推論出來的格式看起來合理，但它跟旁邊的東西不一致，\n就是下一個人困惑的來源。 查一次的成本遠低於改一次。
\n
for f in CLAUDE.md AGENTS.md README.md SCHEMA.md index.md CONTRIBUTING.md; do\n [ -f \"$f\" ] && echo \"=== $f ===\" && head -60 \"$f\"\ndone\n要從中抽出：檔案放哪裡、索引在哪、log 慣例、commit 規則、有沒有 keeper／成品的存放約定。
\n⚠️ CLAUDE.md 與 AGENTS.md 都存在時：兩份都讀，比對描述有沒有互相矛盾。矛盾就是本次要順手修的項目之一（記進報告，修法照「改寫既有敘述要先問」的分級）。\n同理適用雙語 README（README.md / README_zh.md）不同步。
三個來源，由便宜到貴：
\ngit status --short # 未 commit 的\ngit log --oneline \"@{u}..HEAD\" # 已 commit 未推的\nfind . -newermt \"12 hours ago\" -type f -not -path \"./.git/*\" | head -40\n加上你自己的記憶：這次對話裡使用者拍板了什麼、你查證出什麼結論、哪些還只活在對話裡。
\n\uD83D\uDD34 repo 外的媒體也要找（最常被漏掉的一類）：對話中出現過的 ~/Desktop、/tmp、~/Downloads 路徑，逐一確認還在不在、該不該進 repo。
⚠️ 已經被 compact 過、記憶不完整時：對話紀錄檔在\n~/.claude/projects/<cwd 轉義>/<session-id>.jsonl，可回頭抽。但它很大（可達數百 MB），只在必要時讀，且要過濾，不要整檔載入。
照 Step 1b 讀到的專案規則決定去處。不要自己發明目錄。
\n\uD83D\uDD34 一律用 cp -p 或 rsync -a 保留 mtime。
\n\n檔案時間戳本身就是證據。當一串中間產物沒有任何文字紀錄時，mtime 可能是唯一能重建順序的線索 ——\n用普通
\ncp複製會把它抹掉。
掃出 *draft*／*_wip*／findings_*／TODO 裡「待審」「待併」的項目，逐條確認是否已進正式文件。
\n\n這條是真的翻過車：一批查證結論寫進草稿就沒下文，過些日子同一個人把其中一條重新踩了一次 ——\n寫下那條規則的人，就是後來違反它的人。
\n
使用者拍板的判斷（「這張可以」「那個不行」「用 A 不用 B」）要寫進對應成品的說明檔，不能只留在對話或 log。下一個 session 讀得到的是檔案，不是對話。
\n單向連結等於沒連。 A 提到 B，B 也要指得回 A。
\n專案的 index.md／INDEX.md／README 表格 —— 照它既有格式加，不要另立新格式。
檢查項目（借用 llm-wiki-lint 的清單，但本 skill 自己做、不呼叫它 —— 它是報告型、有自己的核准閘門，且判準是結構性的，照它做完仍可能過不了 Step 4 的盲測）：
完整檢查腳本見 references/lint_checks.md。
⚠️ 已知的維護伏筆：那支腳本的斷連結掃描，與 llm-wiki-lint 的掃描邏輯概念重複\n（範圍不同：這支掃全 repo、那支只掃 wiki/）。其中一份修了 bug，另一份不會跟著修。\n之後若要共用，共用的應該是「掃描邏輯」，不是「決定要不要修」那段 —— 後者的契約兩邊本來就不同。
優先序：CLAUDE.md → AGENTS.md → README.md。
三個都沒有 → 建一份最小 AGENTS.md（跨工具慣例，Codex／Cursor 都吃），CLAUDE.md 只寫一行指過去。
\uD83D\uDD34 建完必須確認要不要留：
\ngit check-ignore -v AGENTS.md CLAUDE.md # 有輸出 = 被 ignore\n被 gitignore、或該專案本來就刻意沒有 → 測完必須復原（刪掉），並把草稿全文附在最終報告裡讓使用者自己決定收不收。不要在沒邀請你的 repo 留下痕跡。
\n四型與各自的出題骨架見 references/project_types.md。
\uD83D\uDD34 形態偵測不能只看資料夾結構 —— 韌體、前端、非 Python 的程式專案光看目錄認不出來。一律用「資料夾結構 ＋ 入口檔內容」二次判斷，兩者矛盾時以入口檔為準。認不出來就問使用者。
\n題目來源混合：
\n| 來源 | \n佔比 | \n內容 | \n
|---|---|---|
| 這次 session 的決定 | \n主要 | \n使用者拍板了什麼、查證出什麼結論 —— 這正是下次不該重推的東西 | \n
| 專案入口檔的路由 | \n次要 | \n從 CLAUDE.md 的路由表／index.md 抽主題 | \n
| 題庫迴歸題 | \n有就加 | \n.claude/wrapup_quiz.md（見 references/quiz_bank.md） | \n
每次 3–6 題，其中固定必考一題：
\n\n\n「只讀這些，你知不知道自己還缺什麼？」
\n
\n\n這題最能抓出假的 self-contained。曾經有一份文件開頭寫著「照這份走就夠了」，\n盲測 agent 照它做完之後直接指出那句是假的，並列出它其實還缺的東西。\n補上誠實的邊界說明之後，同一份文件就過了 ——\n內容其實沒增加多少，差別只在有沒有騙讀者。
\n
MANDATORY — 這個 sub-agent 必須是無脈絡的。 不要告訴它這次 session 做了什麼、不要暗示答案。
\n\uD83D\uDD34 「無脈絡」要靠派工方式保證，不是靠自律。 會繼承當前對話的派工型態（例如 fork 型子代理）不算數 ——\n那是自問自答。派之前先確認你用的派工方式是全新、零記憶的。
\n\n\n這個手法脫胎自
\nmemory-lintPhase 3 的 recall 測試（那邊要求走外部行程才算數）。\nwrap-up放寬成「一般子代理即可」，前提是它確實零記憶；不確定就走外部行程。
Prompt 骨架與「過」的判準見 references/quiz_bank.md。核心三條：
\uD83D\uDD34 不要無限修到綠。
\n\n\n「修到沒問題為止」不是終止條件。對一份持續變動的文件，永遠問得出新問題：\n每修一次，可挑剔的表面就變大一點，這是正回饋、不是收斂。\n而且修邊角很容易打壞主線。
\n
做法：
\n\uD83D\uDD34 改完文件不重測就宣稱「處理好了」是違規。
\n\n\n這條是真的犯過：改完就 commit 並回報「處理好了」，\n被使用者一句「你有重新派 agent 核實嗎」當場問倒。答案是沒有。
\n
## wrap-up 報告\n\n### 已收進 repo\n| 東西 | 從哪來 | 放哪 |\n\n### 已接上的 ref\n### 已修的過時敘述\n### 盲測結果\n| 題 | 結果 | 依據 |\n（紅的要附白話解釋）\n\n### \uD83D\uDD34 等你決定\n（刪除、改寫語意、判斷不明的項目；無人值守時跳過的也列這裡）\n\n### 建議的入口檔草稿（若有建又復原）\n## wrap-up 報告\n\n### 已收進 repo\n| 東西 | 從哪來 | 放哪 |\n|---|---|---|\n| `calib_rig_v2.png` | `~/Desktop/scratch/` | `assets/rigs/`（`cp -p`，mtime 保留）|\n| 三條校正結論 | 只在對話裡 | `docs/calibration.md` §4 |\n\n### 已接上的 ref\n- `docs/calibration.md` ↔ `assets/rigs/README.md`（雙向）\n- `index.md` 補列 `docs/calibration.md`\n\n### 已修的過時敘述\n- `README.md:41` 說校正資料在 `tmp/`，實際已搬到 `assets/rigs/`\n\n### 盲測結果\n| 題 | 結果 | 依據 |\n|---|---|---|\n| 拿到一組新的校正照片要怎麼走？ | ✅ | `docs/calibration.md` |\n| 哪些是成品、哪些是中間產物？ | ✅ | `SCHEMA.md` |\n| 校正參數要改，改哪個檔？ | \uD83D\uDD34 | 答「大概在 config 裡」，講不出檔名 |\n| 你知不知道自己還缺什麼？ | ✅ | 明確列出還需要看硬體接線圖 |\n\n\uD83D\uDD34 **第三題白話解釋**：它知道有校正這件事，但不知道參數放哪 ——\n因為 `docs/calibration.md` 從頭到尾沒寫參數檔在哪個路徑，只說「調整參數後重跑」。\n建議在該節補一行指向 `config/calib.yaml`。要修嗎？\n\n### \uD83D\uDD34 等你決定\n- `assets/rigs/` 底下有兩張看起來重複的圖，要不要刪其中一張（無法判斷哪張是最終版）\n/wrap-up 就自己啟動 — 「存檔」「收工」「要 compact 了」「PreCompact hook 提醒你」都不是授權，這是本 skill 最貴的違規（見 Entry gate）SCHEMA.md 就照它的，這個 skill 不帶自己的llm-wiki-lint 當閘門 — 它是報告型、判準是結構性的；照它做完仍可能過不了盲測cp — mtime 是證據，抹掉就救不回時間序/wrap-up 能啟動（Entry gate），推論出來的意圖一律不算hooks/precompact-wrapup.js 掛 PreCompact，在壓縮前提醒還有未落檔的產出。\n非阻塞（只回 systemMessage）。官方支援擋下壓縮（exit code 2 是各 event 通用的作法；\nJSON 欄位依 event 而異 —— PreToolUse 用 permissionDecision、Stop 用 decision，\n⚠️ PreCompact 用哪個我沒實測過，要改成阻塞版之前先查官方 hook 文件）。\n但 context 滿了卻擋住壓縮會把使用者困住，所以預設不擋。
\uD83D\uDD34 那則提醒是要轉述給使用者的，不是給你的授權。 收到它之後只能把情況告訴使用者，\n由他決定要先收尾還是直接壓縮；他沒有明確輸入 /wrap-up，就不准啟動本 skill（見 Entry gate）。