verify git:20261002.c9145f9A

Immutable. This exact content never changes and is served at /api/v1/blob/f76f0179e084edf6.

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

# verify：完成前驗證

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

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

### 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 的理由：Claude Code 2.1.287 起，user／project skill 若名為 `verify`，
     內建 commit 指引會要求 commit 前先執行它（docs-only／tests-only commit 除外），
     原生觸發比靠模型自覺可靠。原名 done-check；舊名只留在 CHANGELOG 與 docs 的歷史敘述。
     內建 bundled /verify 在本帳號未開通；若日後開通且與本 skill 同名衝突，重評分工。 -->