recap

# 收工盤點 四個問題，照順序回答：**做了什麼 → 使用者差在哪 → 該同步的同步了沒 → 進版控了沒**， 最後收斂成一段**結論**（寫在最後面，見 §4）。 **第四個是動手不是回答**：跑 `/recap` 就是授權 commit，不必再問一次（§3.5）。 `git push` 不在裡面——這是個公開 repo，推上去就是公開發表，那是使用者的決定。 這份 skill 的讀者是自己人。目的是讓「兩週後的自己」和「接手的人」看得懂發生過什麼， 而不是讓人覺得這段工作很厲害。**寫得像對帳單，不要寫得像捷報。** **這個 repo 的特殊處境：worktree 是平行 session 共用的。** 隨時可能有另一個 agent 在同一棵樹上改別的功能。§0 和 §3.5 有一半的篇幅在處理這件事。 --- ## 記號表（跨段落統一，一行只掛一個，掛在最前面） 盤點最常見的失敗是**每一條看起來都一樣可信**——「驗過的」「做好了但還沒生效」 「我猜的」混在同一串項目符號裡，讀的人只能逐句判斷。記號的用途是把那個判斷 **前置到行首**。 **狀態記號**——用在 §2 效益、§3 同步、§3.5 版控、「還沒做的」： | 記號 | 意思 | 掛上去的條件 | |---|---|---| | ✅ | 做完且驗過 | **後面必須跟著證據**：數字、實測輸出、log 片段、截圖 | | ⚠️ | 做完，但有已知限制或風險 | 限制要寫出來，不能只掛記號 | | ⏳ | 做好了但還沒生效 | 要寫**卡在哪**（要重 build／要重開 app／等對方收尾） | | 🔮 | 推測，沒有實測 | 「這樣應該會比較快」這類話一律掛這個 | | ❌ | 缺口：該做／該同步但沒做 | §3 最重要的記號——那一節的讀者只在找這個 | | ⚪ | 檢查過，確認不用動 | **要附一句為什麼不用動**，否則跟沒查一樣 | | 🚫 | 不是這次的範圍／不是我動的 | 共用 worktree 常態：平行 session 的改動 | **種類記號**——只用在 §1 做了什麼： | 記號 | 種類 | |---|---| | ✨ | 新功能／新畫面 | | 🔧 | 改既有行為 | | 🎨 | **看得到的東西**：版面、動畫、顏色、吉祥物、瀏海 | | ⚡ | 效能 | | 🌐 | 介面文字與翻譯 | | 🧪 | 測試 | | 🧹 | 順手修掉的 | ### 五條紀律 1. **✅ 後面沒有證據就不是 ✅。** 這個 repo 的證據通常是三種：`./test.sh` 的數字、 `~/Library/Logs/Clawdline.log` 的一行、離螢幕算出來的 PNG。拿不出來就降級成 🔮， 或者老實寫「沒測」。**用記號取代證據，等於把宣稱偽裝成事實。** 2. **只承載「狀態」與「種類」，不承載重要性與情緒。** 禁用 🎉🔥🚀👍‼️⭐。 3. **沒有分類價值就不掛。** 標題不掛記號；散文段落、單句結論也不掛。 4. **一行只掛一個。** 5. **§4 結論整段不掛記號。** 那一段是判斷不是清單。 --- ## 0. 先蒐證，再下筆 不要憑對話印象總結——印象會把「打算做」記成「做了」。動筆前先取事實： ```bash git log --oneline -15 # 這段工作的 commit git status --short ...