check

check skill 總覽

check skill 的用途

check skill 是一套用來審查與把關程式碼 diff、PR、issue 分流、發版準備、push 內容，以及專案稽核的工作流程。它特別適合想快速但有紀律地回答這類問題的使用者：「這樣能安全上線嗎、哪裡有問題、合併前我該先修什麼？」

這個 check skill 最適合什麼情境

當你需要針對一組具體變更做 code review 時，就適合用 check skill，包括合併前、發版前，或是驗證生成產物與後續執行是否一致的時候。它尤其適合希望 agent 先檢查 worktree、避免忽略本機隱藏變更，並把可修正問題與需要人工確認的事項分開處理的情境。

check skill 的差異在哪裡

check skill 不是一個泛用的「幫我看看這段 code」提示詞。它對髒 worktree 或未追蹤檔案有明確的安全門檻，採用先審查、後處理的清楚流程；當牽涉到架構或安全風險時，也會導向專業審查。這讓它比一次性的 check for Code Review 提示更有力，因為它降低了何時要檢查、要檢查什麼，以及何時該停止的猜測成本。

如何使用 check skill

安裝並啟動 check

用以下指令安裝：

npx skills add tw93/Waza --skill check

接著，在你有明確審查目標時呼叫它：例如 diff、branch、PR、release candidate、commit 範圍，或 repo audit 需求。若要看 check usage，請給 agent 明確範圍，例如「檢查最近 3 個 commit」、「合併前 review 這個 PR」，或「依照相依套件更新後，稽核發版準備狀態」。

提供正確的輸入

check 最強的輸入不是「這樣好嗎？」而是一個有邊界、帶上下文的任務。好的例子包括：

• 「在合併前檢查這個 PR 是否有安全性與架構回歸。」
• 「檢查目前的 worktree，告訴我哪些問題會阻礙發版。」
• 「稽核生成檔案，看看它們是否和原始碼變更一致。」

請補上 branch、commit 範圍、預計發版，以及像「不要修改檔案」或「只檢查公開 repo 上下文」這類限制。這能幫助 skill 避免變成範圍過大、結果空泛的審查。

先讀這些檔案

先從 SKILL.md 看起，再查看 references/project-context.md 和 references/persona-catalog.md，以理解審查深度、專家分流方式，以及發版期待。當 diff 會碰到信任邊界、API、imports 或模組結構時，請搭配 agents/reviewer-security.md 和 agents/reviewer-architecture.md。如果流程包含 issue 或 PR 的維護者後續回覆，references/public-reply.md 也很重要。

實用的工作流程建議

在審查前，這個 skill 預期先做 worktree 安全檢查：git status --short --branch -uall。這很重要，因為髒檔或未追蹤變更會改變審查的語意。如果你想讓 check guide 的結果更好，請直接告訴 agent 它是只回報發現、是否可以修安全的問題，以及變更後要用哪個驗證指令。

check skill 常見問題

check 只用在 code review 嗎？

不是。check skill 也涵蓋發版準備、push 內容、已發佈產物、issue 與 PR 分流，以及整個專案的稽核。當任務不只是讀 code，還包含「能不能上線」的判斷時，它會比一般提示更適合。

什麼情況不適合用 check？

不要把 check 用在開放式想法探索、根因除錯，或文章／文案編修。這個 skill 是為具體 diff 與操作性審查設計的，不是用來腦力激盪或提供敘事型回饋。

check 適合新手嗎？

可以，只要你能說清楚目標與結果。新手只要明確說出改了什麼、希望檢查什麼，以及是只看問題還是也要安全修正，通常效果最好。若沒有這些資訊，check install 雖然容易，但 check usage 會變得太寬泛，不夠可靠。

它和一般提示詞有什麼不同？

一般提示詞多半是在請求主觀式 review；check 則加入更有紀律的流程：先做安全預檢、控制範圍、設定驗證期待，並在安全或架構問題上做專家分流。這讓它比臨時性的 review 請求更適合用於 check for Code Review。

如何改進 check skill

提供更精準的審查簡報

最有價值的輸入包括：改了什麼、為什麼改、哪些地方不能壞，以及你要哪一種審查。例如「只 review authentication 路徑」、「聚焦發版產物」，或「確認這個 refactor 是否改動 public APIs」。這會縮小搜尋範圍，也能提高訊號品質。

把硬性限制講清楚

請告訴 skill 打包規則、生成檔案、受保護路徑，以及必要的驗證指令。如果 repo 有 build 或 release 的唯一依據，也請一開始就說明。這能減少過度樂觀的判斷，並幫助 check skill 找出漂移、缺漏產物，或不安全的後續動作。

從發現開始迭代，不要從稱讚開始

第一輪之後，請直接回覆你要重新檢查的具體問題，或你已套用的 patch。當你一次只針對一個風險面向做第二輪檢查時，效果最好，例如安全性、架構，或發版準備。如果輸出看起來太廣，就縮小範圍，不要只要求「更詳細」。