damage-reportlisted

# /damage-report — 收尾自檢（Definition-of-Done Review） 每次完成**開發／優化／解 bug**類任務，寫回報**之前**先跑這份自檢， 結果附在回報末尾、分兩段。（本 skill 管**收工前的審查**；開工前的對應協定—— 先問、給計畫、等明確的「做」才動手——見 [`new-mission`](../new-mission/SKILL.md)，一頭一尾。 它的第 7 步收尾報告可拿本組五問先審再填【誠實帳】——五問是審查，報告是載體。） ## 為什麼需要 - 「改完能跑」不等於「做對了」。AI（和人）最常見的收尾模式是對照「我做了什麼」 宣告完成——但該對照的是「當初要解的問題」。 - 本 skill 的起源是一次真實事故：AI 寫的「取代頁面內容」工具，正常用法會 **靜默刪掉子頁面**，而 AI 已在推薦別人用；攔下它的不是作者，是使用方 執行前自己多查了一步。缺的正是收尾自檢這一步。 - 執行順序是設計的一部分：自檢在寫回報**之前**跑，回報內容才會被自檢結果 修正；反過來就只是貼免責聲明。 > 🤖 Astromech 時刻：X-wing 落地，R2 不會等 Luke 問「剛剛有沒有壞什麼」—— > 它自己跑一輪診斷，嗶嗶把損傷清單報出來。修好 ≠ 能飛下一趟，診斷過才算。 ## ① 對結果的 review（五問，逐問回答） 1. **原本要解的問題，真的解掉了嗎？** —— 對照**原始需求**，不是對照我做了什麼。做完 ≠ 做對。 2. **驗了什麼、怎麼驗、還有什麼【沒驗】？** —— 沒驗的明說，並標驗證等級：**單元測試過 ≠ 真實資料真跑過 ≠ 上線驗過**。 別讓「改完了」聽起來像「驗過了」。 3. **這次改動新引入什麼風險？** —— 預設值安全嗎？破壞既有行為嗎？失敗時會不會是**安靜的** （log 看起來成功、實際沒做到）？ 4. **有沒有留下不一致？** —— 文件、註解、其他呼叫端、另一台機器、排程…… 凡是「改了 A 卻該連動沒連動的 B」都算。 5. **誰在用這個東西？他們知道改了嗎？** —— 使用方不是我，就要主動通知（有 `/dropoff` 就用它發交接卡）； 內容寫「**對方視角的用法變化**」，不是「我做了什麼」。 ⚠️ 給自己的追蹤待辦**不能替代**給對方的通知—— 一張是我的待辦、一張是對方的輸入，漏發後者對方渾然不知。 ## ② 還能怎麼優化 最多 2–3 條，每條具體可執行，並標「值不值得現在做」。 **沒有值得改的就寫「無」——不要為了有產出而發明建議。** （這條是整份 skill 最重要的一條：AI 有產出偏誤，要求「每次都給建議」 它就每次都發明幾條。明文允許寫「無」，建議欄才是真訊號—— 而當它真的寫出建議時，那些建議就值得看了。） ## 研究類任務的五問（同一骨架，對照轉譯） 開發改變世界，研究產出**斷言**——翻車型態不同，五問這樣讀： 1. **答的是當初問的問題嗎？** —— 對照原始提問，不是對照我查到了多少。查得多 ≠ 答得對。 2. **每條結論的證據等級標了嗎？** —— 逐條標：官方文件／親手實測／推論／傳聞。查詢結果有上限的標 「前 N 筆，可能截斷」；引用快照帶日期（會過期）。 🚫 **禁止拿快取記憶當現況斷言**——「