安裝
npx skills add tw93/Waza -a claude-code codex cursor -g -y適合誰
如果你已經會做功能計畫和修缺陷，只是希望智慧體按同一套習慣跑，而不是臨場發揮，這個技能對得上。官方把它寫成：把你已經熟悉的工程習慣，變成智慧體可以執行的技能。
安裝後會得到一組斜線技能，頁面點名 /think、/check、/hunt。Claude Code 裡直接打斜線命令；Codex 裡按已安裝技能的名字呼叫，並走同一套步驟。頁面還寫到 Cursor、Gemini CLI、Copilot、Amp、Kimi Code CLI，以及會讀取同一共享目錄的其他智慧體也能撿起這八個技能。這是目錄讀取關係，不是一份互斥名單。
更合適的人是：手頭有一個可開啟的目標儲存庫，想先做唯讀計畫或檢查，而不是一上來讓智慧體 implement。官方說明見
https://github.com/tw93/waza
3 分鐘完成第一次嘗試
只走這一條官方安裝路徑：
npx skills add tw93/Waza -a claude-code codex cursor -g -y
命令會把一份副本落到 ~/.agents/skills 這個共享技能目錄。Claude Code 以符號連結接入；Codex、Cursor 以及其他會讀該目錄的智慧體再把技能識別成 /check、/think 等名字。頁面沒有另給第二套安裝器作為主路徑。
前置：本機已能執行上述 npx 命令，並且至少開啟了一個會讀取 ~/.agents/skills 的智慧體。安裝位置就是這個共享目錄，不要再手工複製到別的資料夾。
第一次任務選可逆、偏分析的動作。在 Claude Code 開啟目標儲存庫後輸入 /check，或先輸入 /think 只做計畫；在 Codex 則按技能名呼叫同一套檢查或計畫。不要在第一次就說 implement。成功訊號：技能以 /check、/think 等名字出現，並且 /check 能基於儲存庫公開上下文給出檢查結果，而不是提示技能未安裝。
使用案例
案例一：先計畫功能，再決定是否實現。
官方把規劃功能寫成：/think，得到計畫後批准，再說 implement X，然後 /check，最後才 merge。第一次只跑到 /think 並閱讀計畫；證據沒有寫批准按鈕長什麼樣，也沒有寫 merge 的具體命令，能確認的是這條順序，以及實現應發生在計畫被接受之後。
案例二：先查根因，再改程式碼。
官方把修缺陷寫成：/hunt，再修復，再 /check，然後才做後續跟進。頁面把跟進寫成 release/publish/push/issue follow-through，但沒有展開這些跟進步驟。第一次只跑 /hunt，確認根因描述對得上現象後，再動手改。/hunt 被寫成用來確認根因，而不是直接開改。
兩次都建立在同一條安裝路徑上。/check 可以接在計畫或修復後面，但第一次仍應單獨跑檢查，確認它讀到的是公開上下文。
使用邊界
Waza 只提供通用工程習慣。/check 會在執行時讀取目標儲存庫的公開上下文，包括 README、套件清單、Makefile、持續整合工作流程，以及你這次任務的約束；它不會讀取私有路徑、憑證或權杖。頁面沒有寫它可以存取私有設定或金鑰。
安裝命令裡帶了 claude-code、codex、cursor 三個目標，副本落在 ~/.agents/skills。其他會讀該目錄的智慧體也能撿起技能，但頁面沒有為每一個名字單獨給觸發示例。除 Claude Code 的斜線和 Codex 的按名呼叫外，其餘環境能確認的只有「讀到共享目錄就會出現這八個技能」。
頁面沒有寫語言範圍、配額或必須在哪個儲存庫類型上使用。缺少目標儲存庫的公開上下文時，/check 能做到哪一步，官方沒有另給失敗樣例。