審查程式碼 diff、PR、Issue 佇列、發布準備狀態、Commit、Push、發布流程與專案審計。當使用者以任何語言要求程式碼審查（Code Review）、Issue 或 PR 分流（Triage）、發布關卡檢查（Release Gates）、發布後續跟進或專案審計時使用。不適用於除錯根本原因（Root Causes）或一般文章審閱。
Check：發布前的全面審查
請在第一行的開頭行內加上 🥷，不要將其獨立成一個段落。
更新檢查（非阻塞性）。 每次對話執行一次：執行 bash <skill-base-dir>/scripts/check-update.sh（請將 <skill-base-dir> 替換為此 Skill 的基底目錄）；若有印出任何文字請轉述，否則靜默繼續（當指令稿已執行過、遺失或發生錯誤時亦同）。該指令稿每天最多檢查一次，僅讀取公開的版本檔案，且不會傳送任何資料。
附註：
/review是 Anthropic 內建用於 PR 審查的外掛指令。Waza 請改用/check（或別名code-review）。請勿在此 Skill 內部再次觸發/review。
讀取 diff、找出問題、安全地修復可修復的部分，其餘部分提問確認。完成（Done）代表本次工作階段已執行驗證且通過。
成果合約（Outcome Contract）
- 成果（Outcome）：基於目前的 diff、專案上下文及即時證據所產出的審查結論、發布決策或維護者處置動作。
- 完成條件（Done when）：提出的發現、修復、已發布狀態或阻礙因素，均附上能證明其真偽的指令、產出檔案（Artifacts）或遠端狀態。
- 證據來源（Evidence）：工作區（Worktree）狀態、diff、公開的專案文件、Manifest 檔案、CI、套件內容、發布或 Registry 狀態，以及目前的指令輸出結果。
- 輸出格式（Output）：先精簡列出審查發現，適用時再提供驗證與已發布狀態摘要。
工作區安全預檢（Worktree Safety Preflight）
在進行任何審查、分流（Triage）、Ship、發布（Release）或 PR 操作之前，請先使用以下指令讀取目前的工作區：
git status --short --branch -uall
請將已修改（Modified）、已暫存（Staged）及未追蹤（Untracked）的檔案視為使用者的工作成果。你可以讀取並將它們納入審查範圍，但在目前對話輪次中未獲得使用者明確批准前，絕不得移動、隱藏、覆寫、清除或捨棄這些檔案。
切勿將以下指令作為預設的審查或 PR 預備步驟：git switch、git checkout、git reset --hard、git clean、git stash -u、git stash --include-untracked、git stash -a、git stash --all 或 gh pr checkout。若確實需要切換分支或進行清理，請暫停並向使用者請求執行該確切操作。
切勿以「保護」使用者工作為由，將未追蹤檔案、生成的檔案、截圖或本機暫存檔搬移至 /tmp 或其他暫存目錄。將他人的未完成工作（WIP）移出工作區，其干擾性質與執行 stash 完全相同。若生成、打包或驗證過程需要乾淨的目錄樹，請從已知的 Commit 建立獨立的 worktree，並僅將屬於你自己的產出檔案或補丁（Patch）複製回目前的工作區。
在工作區不乾淨或多 Agent 協作的環境中執行 Commit 或 Push 跟進時，請在暫存（Staging）前記錄 git rev-parse HEAD。在 Commit 正要執行前以及 Push 正要執行前，再次讀取 git status --short --branch -uall 與 git rev-parse HEAD。若 HEAD 發生變動、出現未知的 Commit，或工作區在預期變動檔案之外發生了改變，請立即停止並回報不匹配情況，而不是進行 Rebase、重新 Commit 或 Push。
檢查 PR 時，請優先使用不會切換目前工作區的指令：gh pr view、gh pr diff、git fetch origin pull/<n>/head:refs/tmp/pr-<n> 以及 git merge-tree。
模式選擇器（Mode Picker）
請選擇符合使用者意圖的模式，並完整閱讀該章節。模式會疊加在後續的共享審查機制（Scope、Hard Stops、Autofix、Specialist Review、Verification、Sign-off）之上。
| 使用者意圖 | 模式 |
|---|---|
"implement this plan"（執行此計畫）、交接 /think 輸出 |
計畫執行模式（Plan Execution Mode） |
| Diff 或 PR 已就緒、"review"、"看看程式碼"、"合併前" | 預設審查（從 取得 Diff 開始） |
| "look at issues"、"review PRs"、"triage"、"批次處理" | 分流模式（Triage Mode） |
| "is this worth a release"、"值不值得發布版本" | 發布價值分析（Release Worthiness Analysis） |
| "commit"、"push"、"publish"、"release"、"close issue"、"發布表情" | Ship / 發布後續跟進（Ship / Release Follow-through） |
| "audit"、"專案健康檢查"、"專案評分"、"給專案打分"、"深入分析專案程式碼"、"scorecard"、"linus review" | 專案審計模式（Project Audit Mode） |
| 文件、PDF、文章審閱 | 委派給 /write（參閱 文件審閱） |
在進入任何模式前，請先執行 專案上下文擷取，以及（若記憶在作用範圍內）持久上下文預檢。
專案上下文擷取（Project Context Extraction）
這是 Waza 的公開獨立程式碼審查能力。它不應依賴私有機器路徑或未公開的專案指示。
在進行審查前，請先從儲存庫上下文中擷取專案約束條件：
- 讀取 diff 並識別變更的語言、框架、Manifest、生成的產出物、發布檔案與 CI 工作流程。
- 僅在需要時檢查公開的專案檔案：README、AGENTS/CLAUDE 指示（若存在）、套件 Manifest、Lockfile、建置設定、測試設定、工作流程檔案及發布說明（Release Notes）。
- 將發現濃縮為審查上下文：驗證指令、受保護或生成的檔案、發布產物、領域風險及公開回覆規則。
- 當專案上下文與此 Skill 規則重疊時，採用較嚴格的規則。
- 若專案文件或 CI 指定了驗證指令，優先使用該指令而非自動偵測。
關於上下文的結構格式，請參閱 references/project-context.md。
對於發布或維護者工作，還需填寫來自 references/project-context.md 的 Release Gate 2.0 矩陣。它涵蓋審查基準、未乾淨/已暫存/未追蹤狀態、最新 Tag、Origin 同步狀態、版本欄位、生成的產物、套件/封存檔案內容、發布資產、Registry/Appcast/CI 以及公開 Issue/PR 狀態。缺乏矩陣證據將直接阻礙宣稱「已準備好發布（ready to release）」。
持久上下文預檢（Durable Context Preflight）
有關何時讀取持久上下文、讀取順序預算以及記憶類型對映，請參閱 references/durable-context.md。
對於 /check：目前的 diff、CI 與遠端狀態優先於記憶。持久記憶可以解釋使用者的意圖與偏好的後續跟進方式，但公開的專案規則仍須來自 README 檔案、Manifest、CI 工作流程、發布文件以及目前對話串中的明確指示。切勿將私有記憶引用為公開專案的必要需求。
計畫執行模式（Plan Execution Mode）
當使用者的訊息開頭為 "Implement the following plan"、"按計畫實施"、"按照計畫"、"整"、"可以幹"、"直接改" 並附帶計畫主體，或是連結至 /think 的輸出時觸發。
在此模式下，請勿執行程式碼審查。改為執行以下步驟：
- 說明正在執行哪一份計畫（第一行標題或摘要行）。
- 檢查是否有明顯的儲存庫漂移（Repo Drift）：執行
git status --short --branch -uall並瀏覽任何與計畫衝突的變更檔案。若漂移導致執行計畫不安全，請指明具體衝突並停止。 - 逐一將計畫項目視為待辦事項（To-do）執行，完成一項即標記一項。
- 所有項目完成後，執行專案的驗證指令。
- 若專案上下文或目前對話串指示「審查後發布（review-then-ship）」，則自動切換至 Ship 模式。
預設續行（審查後發布 review-then-ship）
當專案的 AGENTS.md 或目前對話串明確要求「審查後 Commit」、「若測試通過則 Ship」或同等意思時，在審查無誤後直接從審查流程切換至 Ship 流程。無需再次詢問。在採取行動前請說明「正在推進至 Ship 流程（proceeding to ship）」。
取得 Diff（Get the Diff）
取得目前分支與基底分支（Base Branch）之間的完整 diff。若已在基底分支上，請詢問要審查哪些 Commit。
分流模式（Triage Mode）
當使用者提及：issue、PR、"review all"、triage、"batch" 或 "批次處理" 時觸發。跳過 diff 流程並改為執行此模式。
行動優先原則（Action-first rule）： 處置方向明確的項目（已修復、重複回報、已發布）應立即處理，無須撰寫分析段落。分析截圖或圖片時，請在一則訊息中說明你所看到的內容與建議的操作。僅在處置方向確實模糊不清時才詢問使用者。
打包需求分類（Bundled request classification）： 當單一 Issue、PR 或支援對話串包含多個要求時，在採取行動前先將其拆分：核心 Bug、既有功能/途徑、外觀喜好及超出範圍的需求。僅修復或關閉經過驗證的核心 Bug；對既有功能提供目前的實現路徑說明；延後或拒絕外觀喜好與超出範圍的需求，切勿將整份報告直接當作待辦清單處理。
狀態回答順序（Status answer order）： 對於 "都解決了嗎"、"is this fixed"、"is this ready" 或類似的狀態檢查，請按以下順序回答：程式碼或 Commit 狀態、分支或 CI 狀態、發布產物或 Registry 狀態，最後才是公開 Issue 或 PR 狀態。請勿將「已在 main 修復」、「在預覽版中可用」、「下個穩定版本發布」與「已經發布」混為一談。
流程（Flow）： 首先從公開上下文中識別專案的 Issue/PR 代管平台。對於 GitHub 專案，使用 gh issue list -R <repo> --state open --limit 20 及 gh pr list -R <repo> --state open 拉取開啟中的項目。對於非 GitHub 專案，使用專案文件或使用者要求指名的平台 CLI/API；若不存在，請停止並回報缺乏整合，切勿假裝 GitHub 指令適用。對每個項目，參照專案的發布邊界檢查目前狀態：最新公開發布版、main 分支、preview/nightly/beta 管道、registry/appcast，以及目標 Issue/PR 狀態。若修復已在目前的公開發布版或有紀錄的預覽管道中，附上確切升級路徑並關閉 Issue。若已在 main 上修復但尚未發布，請回覆 "已修復，等下一個版本 release"，且僅在專案慣例或目前使用者要求允許「main 修復即關閉」時才予以關閉；否則請保持開啟並附上標註下個版本發布的說明。若尚無修復，請進行分析並採取行動。若可行請立即修復（使用 fix: closes #N Commit）；對於有效但尚未發布的項目，確認接收並保持開啟；對於無效項目，給出 1-2 句話的原因說明並關閉。
在即時佇列（Live queue）給出最終結論前，請再次重新整理 Issue/PR 清單，並重新閱讀在執行過程中發生過變動的項目。若證據不完整，請保留該項目而不要憑猜測關閉。
PR 處理（PR handling）： 若 PR 的方向被接受但補丁需要修改，優先將維護者的修復推送到貢獻者的 PR 分支並合併該 PR。在 Push 前請先檢查 maintainerCanModify，並在正要 Push 前確認 Push Remote、目標分支及目前的 HEAD，避免覆寫貢獻者的工作成果或將維護者的修復推送到錯誤的儲存庫。若不允許編輯分支，請要求貢獻者開啟維護者編輯權限或推送所需的修訂版本；僅在時效性或發布安全性有極高要求時，才退回使用獨立的維護者 Commit，並在 PR 中說明原因。僅在方向被拒絕、不安全、不再需要或明確超出專案範圍時，才進行不合併直接關閉（Close without merging）。切勿靜默地將已接受的 PR 吸收合併至 main 後直接將其關閉。
公開回覆格式（Public reply shape）： 請載入 references/public-reply.md 以取得完整範本（包含標記提及、單次致謝、事實段落、下個版本發布步驟、編輯規則、關閉條件）。Ship 模式使用相同的範本；該檔案為唯一的單一事實來源。
簽核行（附加於標準 Sign-off 後）：
triage: N reviewed, N closed, N deferred
發布價值分析（Release Worthiness Analysis）
當使用者詢問 "深入分析 X 是不是值得發新版本"、"is this worth a new release"、"值不值得發版" 或類似問題時觸發。
