verification-loop

verification-loop 概覽

verification-loop 是用來做什麼的

verification-loop skill 是給 Claude Code 工作階段使用的驗證流程。它幫你在實作完成後，依序執行 build、type、lint、test、security 和 diff review 等步驟，而不是只靠一句泛泛的「看起來沒問題」提示。若你是在找用於 Verification 的 verification-loop skill，這套流程的目標是先在 PR 前抓出迴歸問題，而不是替功能做前期規劃。

誰適合安裝

如果你經常完成程式變更，並且想替 JavaScript、TypeScript 或 Python 專案建立可重複的品質關卡，verification-loop 很適合你。對於想要在變更後做結構化檢查、而且需要明確停止條件的 agents 與開發者來說，特別有用；尤其當 build 失敗或 type 錯誤應該先阻擋後續步驟時，更能發揮價值。

這個 skill 有什麼不同

verification-loop 的主要價值在於分階段處理：先 build，再 types，接著 lint、tests、security checks，最後做 diff review。這個順序很重要，因為它可以減少不必要的工作，也更容易把失敗原因隔離出來。這個 skill 對輸出內容也有明確立場，例如要求回報測試數量和 coverage，讓它比空泛的驗證提示更有助於決策。

如何使用 verification-loop skill

verification-loop 安裝與設定

先把 verification-loop skill 安裝到你的 Claude Code 環境，然後把 SKILL.md 當作起點開啟。這個 repository 很精簡，沒有額外的 helper scripts 或支援資料夾可以依賴；skill 本身就是唯一的準則來源。對 verification-loop install 來說，實際目標不只是把 skill 加進來，而是確認你目前的專案也具備這個流程預期的 build 和 test 指令。

給 skill 明確的變更脈絡

verification-loop usage 在你清楚描述變更內容、技術堆疊，以及適用的驗證指令時，效果最好。差的輸入會像是：「幫我驗證程式碼。」更好的輸入則是：「驗證這個 TypeScript app 的登入重構。執行 build、tsc --noEmit、lint 和 tests，然後用檔名摘要失敗原因，並判斷這個變更能不能安全合併。」這種具體程度可以幫 skill 判斷要檢查什麼，以及哪些情況算阻擋項。

依照階段順序執行，並遵守停止規則

請依照各階段的順序執行；如果前一關失敗，不要跳過去做後面的步驟。build 失敗就先修 build，再做 type checking；types 出問題，就先解決關鍵錯誤，再進入 lint 或 test review。這正是 verification-loop 指南的核心運作概念：它是一個逐步收斂的工作流程，不是平行勾選清單。

先讀這些檔案

先從 skills/verification-loop/SKILL.md 看起。如果你要把這個 skill 套用到真實 codebase，請把它的指令和你專案現有的 package scripts 以及工具鏈對照。因為這個 repo 沒有其他參考文件，你接下來應該讀的是專案自己的 build、lint 和 test 定義，這樣才能把 skill 對應到真實可執行的命令，而不是想當然地以為 npm、pnpm、ruff 或 pyright 一定可用。

verification-loop skill 常見問題

verification-loop 只適用於 Claude Code 嗎？

它是為 Claude Code sessions 撰寫的，但底層的驗證邏輯作為變更後檢查清單，其實很通用。如果你不在那個生態系統裡，仍然可以手動沿用同樣的順序。安裝 verification-loop 的主要理由，是在 Claude 工作流程中取得便利性與一致性。

一定要是 JavaScript 或 Python 專案嗎？

不一定，但這個 skill 明確點名的就是這些技術堆疊。當你的專案有清楚的 build、type check、lint 和 tests 指令時，verification-loop 的效果最好。如果你的 stack 使用不同工具，仍然可以照這個流程走，只是你得自己把指令翻成對應版本。

什麼情況下不適合用 verification-loop？

如果你只需要針對很小的變更做一次性提示，或是 repository 根本沒有有意義的 build/test gate，就可以跳過它。當 codebase 太客製化，標準驗證指令很難直接套用，而你又不想為了它去改流程時，這個 skill 也不太合適。在這些情況下，自訂提示詞通常比安裝完整的 verification-loop skill 更快。

它和一般 prompt 比起來有什麼差別？

一般 prompt 可以要求「跑 tests」，但 verification-loop 提供的是有順序的驗證迴圈，包含明確的停止邏輯與回報目標。這樣能降低歧義，也更容易判斷變更是否已經準備好。代價是，你仍然需要提供正確的專案指令與限制條件。

如何改進 verification-loop skill

提供專案專屬的指令

最大的品質提升，來自把泛用指令換成你 repository 真正使用的那一組。如果你的專案用的是 pnpm build、npm test、pytest 或自訂 scripts，請一開始就告訴 agent。更好的輸入能減少猜測，讓 verification-loop 比預設指令序列更可靠。

要求失敗摘要，不要只看通過或失敗

當你要求 skill 提供精簡報告，包含失敗步驟、檔名，以及該問題是否阻擋合併時，它會更有用。比如說：「執行 loop 後，先列出 build errors，再列 type issues，接著是 test failures，並標示哪些是 critical。」這樣輸出就會變成可行動的資訊，而不只是二元結果。

注意常見失敗模式

最常見的問題包括：缺少專案指令、type-check 覆蓋不完整，以及 security 掃描對 repository 來說太淺。另一種失敗模式，是在 code 還沒穩定時就要 skill 去驗證變更。verification-loop 最適合在實作完成後使用，等 diff 已經準備好接受判斷時再跑。

第一次跑完後再迭代

如果第一次驗證結果雜訊太多，下一輪就縮小範圍：指定變更過的檔案、說明 package 或 app 目錄，並釐清哪些警告可以接受。如果第一次通過，但你仍然對變更沒信心，就要求針對高風險檔案、邊界情境或 coverage 缺口做 diff review。這就是讓 verification-loop 從一次性的檢查清單，變成可重複使用的驗證流程的方法。