# Damage Report

> 「開發／優化／修 bug／研究查證」類任務收尾的自檢協定。寫回報之前先跑五問（開發問「改變」、研究問「斷言」,同一骨架兩組對照），把結果附在回報末尾，再加一段「還能怎麼優化」（沒有就寫無）。當使用者說「收尾自檢」「自我 review」「跑五問」「self-review」時觸發；也適合寫進全域指令讓它在每次工具類任務收尾自動執行。 English triggers: "damage report", "self-review", "wrap-up check", "definition of done review".

- Skill: `tingyulu/damage-report` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tingyulu/damage-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tingyulu/damage-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: tingyulu (https://skillmd.com/u/tingyulu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tingyulu/damage-report

---


# /damage-report — 收尾自檢（Definition-of-Done Review）

每次完成**開發／優化／解 bug**類任務，寫回報**之前**先跑這份自檢，
結果附在回報末尾、分兩段。（本 skill 管**收工前的審查**；開工前的對應協定——
先問、給計畫、等明確的「做」才動手——見 [`new-mission`](../new-mission/SKILL.md)，一頭一尾。
它的第 7 步收尾報告可拿本組五問先審再填【誠實帳】——五問是審查，報告是載體。）

## 為什麼需要

- 「改完能跑」不等於「做對了」。AI（和人）最常見的收尾模式是對照「我做了什麼」
  宣告完成——但該對照的是「當初要解的問題」。
- 本 skill 的起源是一次真實事故：AI 寫的「取代頁面內容」工具，正常用法會
  **靜默刪掉子頁面**，而 AI 已在推薦別人用；攔下它的不是作者，是使用方
  執行前自己多查了一步。缺的正是收尾自檢這一步。
- 執行順序是設計的一部分：自檢在寫回報**之前**跑，回報內容才會被自檢結果
  修正；反過來就只是貼免責聲明。

> 🤖 R2-D2 時刻：X-wing 落地，R2 不會等 Luke 問「剛剛有沒有壞什麼」——
> 它自己跑一輪診斷，嗶嗶把損傷清單報出來。修好 ≠ 能飛下一趟，診斷過才算。

## ① 對結果的 review（五問，逐問回答）

1. **原本要解的問題，真的解掉了嗎？**
   —— 對照**原始需求**，不是對照我做了什麼。做完 ≠ 做對。
2. **驗了什麼、怎麼驗、還有什麼【沒驗】？**
   —— 沒驗的明說，並標驗證等級：**單元測試過 ≠ 真實資料真跑過 ≠ 上線驗過**。
      別讓「改完了」聽起來像「驗過了」。
3. **這次改動新引入什麼風險？**
   —— 預設值安全嗎？破壞既有行為嗎？失敗時會不會是**安靜的**
      （log 看起來成功、實際沒做到）？
4. **有沒有留下不一致？**
   —— 文件、註解、其他呼叫端、另一台機器、排程……
      凡是「改了 A 卻該連動沒連動的 B」都算。
5. **誰在用這個東西？他們知道改了嗎？**
   —— 使用方不是我，就要主動通知（有 `/dropoff` 就用它發交接卡）；
      內容寫「**對方視角的用法變化**」，不是「我做了什麼」。
      ⚠️ 給自己的追蹤待辦**不能替代**給對方的通知——
      一張是我的待辦、一張是對方的輸入，漏發後者對方渾然不知。

## ② 還能怎麼優化

最多 2–3 條，每條具體可執行，並標「值不值得現在做」。
**沒有值得改的就寫「無」——不要為了有產出而發明建議。**

（這條是整份 skill 最重要的一條：AI 有產出偏誤，要求「每次都給建議」
它就每次都發明幾條。明文允許寫「無」，建議欄才是真訊號——
而當它真的寫出建議時，那些建議就值得看了。）

## 研究類任務的五問（同一骨架，對照轉譯）

開發改變世界，研究產出**斷言**——翻車型態不同，五問這樣讀：

1. **答的是當初問的問題嗎？**
   —— 對照原始提問，不是對照我查到了多少。查得多 ≠ 答得對。
2. **每條結論的證據等級標了嗎？**
   —— 逐條標：官方文件／親手實測／推論／傳聞。查詢結果有上限的標
      「前 N 筆，可能截斷」；引用快照帶日期（會過期）。
      🚫 **禁止拿快取記憶當現況斷言**——「清單上沒看到」只證明當時沒有，
      不證明現在沒有。
3. **哪條結論錯了傷害最大？**
   —— 對那一條做**反面查證**（主動找反例），別只收集支持自己的證據。
4. **跟既有記錄打架嗎？**
   —— 與先前研究／文件／記憶矛盾的地方明著指出並更新舊記錄，
      不讓兩版真相並存。
5. **結論落地了嗎？交付給誰？**
   —— 只活在對話裡的研究＝沒發生：落檔＋同步到共用處；
      要人拍板的，收斂成**編號選項**，不是散文。

②「還能怎麼優化」的研究版＝ **openQuestions**：誠實列出沒查完／查不到的
2–3 條，沒有就寫「無」。

開發與研究混合的任務（大多數真實任務都是）：兩組都掃一遍，重疊的答一次。

## 五問對應的翻車型態（設計說明）

| 問 | 開發版攔的 | 研究版攔的 |
|---|---|---|
| 1 | **假完成**——程式能跑了，原始問題還在 | **答非所問**——查了一堆，原始問題沒被回答 |
| 2 | **假驗證**——單元測試全過、真實資料首輪就炸 | **假證據**——快取當現況、截斷當全貌、快照不標日期 |
| 3 | **危險預設／安靜失敗**——正常用法就毀資料 | **單方查證**——只收集支持自己的證據，沒找過反例 |
| 4 | **半套改動**——碼改了文件沒改；這台改了那台沒改 | **雙重真相**——新結論與舊記錄矛盾卻並存，各說各話 |
| 5 | **沉默升級**——工具修好了，用的人渾然不知 | **蒸發的研究**——結論只活在對話裡，沒落檔沒交付 |

## 進階：自審＋異質視角（接上 `ai-review`）

自審有結構性上限：**判準是自己定的，推理自洽就過關**。
若環境裡有 [`ai-review`](../ai-review/SKILL.md)，把順序改成：

1. 先寫五問**草稿**（不是最終回報）。
2. 連同產出物送二審 —— **用完整路徑呼叫**，別打裸命令名：
   `<ai-review skill 目錄>/scripts/ai-review.sh <產出物> --rubric code|copy|research --context "<要解什麼>"`
3. 看回傳的最後一行 `AI_REVIEW_STATUS:` ——
   `ok` 就把意見**消化進**五問（哪幾條採納、哪幾條不採納與理由），
   `skipped_*`／`failed_*` 就在回報裡**明講「本次僅自審」**。
4. 消化完才寫最終回報。

⚠️ 照實帶走這三個已知漏洞，別只輸出好處：
① **無收據** —— 沒有機制證明某次工作真的送審過；
② **TOCTOU** —— 送審後又改了東西，審的是舊版；
③ **「本次不送」是無限制 bypass** —— 想跳過隨時能跳過。
所以這是 **best-effort 流程，不是強制機制**：觸發器只是文字，忘記跑不會有人發現。
要強制得在 CI／hook 這種工具層做。

## 鐵律

- ✅ 五問**逐問回答**，不可整段帶過；「沒驗」「不知道」都是合法答案，跳過不是。
- 🔁 **沒送二審就明講「僅自審」** —— 有接 `ai-review` 而這次沒跑到（沒裝／失敗），
  在回報裡說出來，不要讓讀者以為看過兩雙眼睛。
- 🚫 建議欄**禁止湊數**——寧可寫「無」。
- 📝 自檢在寫回報之前跑，不是回報寫完再補。