Done Check

---
name: done-check
description: 宣稱任務「完成」之前必跑的驗證 checklist。在準備回報完成、準備 commit、或使用者問「好了嗎」時使用。產出一份附證據的驗證報告。
---

# done-check：完成前驗證

目的：杜絕「假完成」。每一個 ✅ 都必須有貼出來的指令與輸出當證據；沒有證據就不是 ✅。

## 執行步驟（依序，不可跳過）

### 1. 複述完成判準
用一句話寫出這個任務原本的完成判準（來自 tasks/todo.md 或使用者的原話）。
- 如果寫不出具體判準 → 停，先回去確認任務範圍，不要繼續。

### 2. 跑現有測試
- 先找測試指令：依序檢查 `package.json` 的 scripts、`Makefile`、`pyproject.toml`、CI 設定檔（`.github/workflows/`）。
- 跑它，貼出輸出最後 10 行。
- 找不到任何測試 → 明確寫「本專案無測試」，不要假裝跑過。
- 測試失敗 → 不是完成。回去修，或如實回報失敗內容。

### 3. 手動走 happy path
- 用真實指令實際執行改動的功能（curl、跑 script、開頁面），不是只看程式碼「應該會動」。
- 貼出實際輸出。

### 4. 走至少 2 個邊界情況
從這個清單挑與改動相關的：空輸入、超長輸入、不存在的檔案/ID、權限不足、重複執行（冪等性）、並發、非 ASCII 字元。
- 每個邊界情況：一行寫「輸入 → 預期 → 實際」。

### 5. 檢查沒有新的警告或錯誤
- 重看步驟 2–4 的輸出有無 warning / error / deprecation。
- 有 log 檔就 tail 一下。

### 6. 審視 diff
- `git diff --stat`（或比對改動清單），確認：
  - 沒有除錯碼（console.log、print、註解掉的程式碼）
  - 沒有與任務無關的檔案被改到
  - diff 大小與任務規模相稱（小任務出現大 diff = 警訊，回報它）

### 7. Staff engineer 之問
自問：「一位資深工程師會核准這個 PR 嗎？」有任何遲疑 → 把遲疑的點寫進回報，不要吞掉。

## 回報格式（固定模板）

```
## 驗證報告
- 完成判準：<一句話>
- 測試：✅/❌/無測試 — <指令> → <輸出尾行>
- Happy path：✅/❌ — <指令> → <實際輸出>
- 邊界情況：
  - <輸入> → 預期 <X> → 實際 <Y> ✅/❌
  - <輸入> → 預期 <X> → 實際 <Y> ✅/❌
- 新警告/錯誤：無 / <內容>
- Diff：<N 檔 / M 行>，無除錯碼、無無關改動
- 未驗證項目：<誠實列出，說明原因>
- 已驗證: <hard-rules #3；本輪未引用使用者陳述的程式碼事實則寫「不適用」>
- 範圍外發現: <hard-rules #4；記到 tasks/todo.md 的項目，或「無」>
- AUTH: 使用者說「<原話>」<judgment.md §1；本輪無不可逆動作則寫「不適用」>
```

上面最後三行是**逐字必填欄位**，不是可省略的過程細節（reporting.md §2 末段）。

## 鐵則

- 任何一項標 ⚠️ 未驗證都可以，但**用 ✅ 包裝沒驗證過的項目是最嚴重的違規**。
- 這份報告是給使用者的回報主體，不是附錄。

<!-- 與內建 /verify 的分工：/verify 列在官方 bundled skills 中，但本帳號尚未開通
     （實測：binary 裡有 verifySkillRolloutGateLatch，但可用 skill 清單無 /verify）。
     因此本 skill 維持正本。待 /verify 開通後重評：
     若它涵蓋步驟 2–5，本 skill 可降為「內建不足時的補充」，只保留步驟 1、6、7
     與上方三個逐字必填欄位。 -->