review

review 技能概覽

review 技能是做什麼的

review 是一個在合併前使用的 PR review 技能，用來在程式碼進入 base branch 之前檢查 diff。它不是只給泛用提示詞，而是特別針對需要具體結構風險判讀的 reviewer 設計，例如 SQL 安全、信任邊界違規、條件式副作用、shell injection，以及 enum 是否完整。

誰適合使用它

當你準備把程式碼送進主分支、回覆「請幫我 review 這個 PR」，或想在多個 repo 之間維持一致的 review for PR Review 工作流程時，就適合用這個 review 技能。它特別適合需要快速揪出真正缺陷、同時避免被大量只談風格的雜訊干擾的 agents。

它有什麼不同

這個技能對 review 順序與嚴重性是有明確立場的。它會先推最關鍵的安全檢查，再處理較低嚴重度的問題，並且支援針對測試、安全、效能、可維護性等面向的專家 review 路徑。這讓 review guide 比起單純的「掃描 diff」提示詞更可執行、更有行動性。

適用範圍與限制

它最擅長的是有清楚 git diff、且 base branch 具備明確意義的程式碼變更。若是高層設計評語、產品文案編修，或使用者只是想要稱讚或摘要，它就沒那麼適合。若你要的是輕量的意見，而不是先修正問題的 review，那一般提示詞就可能已經夠用。

如何使用 review 技能

安裝並觸發它

使用 npx skills add garrytan/gstack --skill review 安裝。這個技能設計上會在像是「review this PR」、「code review」、「check my diff」和「pre-landing review」這類語句下觸發，所以輸入時盡量把變更內容與比較基準點名出來。

給 review 技能一個真正的 review 目標

好的 review usage 不是模糊地請它看一看，而是一開始就提供能感知 diff 的請求。實用的輸入應該包含 repo、branch 和目的：

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

先讀這些檔案

如果要實際驗證 review install 的運作，先看 SKILL.md，再看 checklist.md、design-checklist.md 和 greptile-triage.md。如果你要調整這個工作流程，也請進一步檢查 TODOS-format.md 與 specialists/ 資料夾，了解哪些問題會被分派給子代理，哪些則由主 checklist 處理。

用這個技能預期的工作流程

這個 repo 的設計核心是雙階段 review：先做關鍵安全檢查，再處理資訊性問題。有效的提示應該要求可執行的輸出，包含 file/line 參照與修正建議，而不只是「找 bug」。如果你知道變更範圍，也要一併寫上，這樣技能才能優先走對應的專家路徑。

review 技能 FAQ

review 比一般提示詞更好嗎？

是，當你需要可重複、可一致執行的 PR review 行為時尤其如此。一般提示詞可能會漏掉範圍規則、升級順序或專家分流。review 技能把這些直接內建到工作流程裡，讓你比較不需要猜先該檢查什麼。

review 技能適合新手嗎？

大致上適合，只要使用者能描述 branch 或 PR。新手會受益於引導式 checklist，但仍需要提供真實 diff 與足夠脈絡，才能分辨哪些是預期行為、哪些是 regression。

什麼情況不該用 review？

不適合沒有程式碼的問題、腦力激盪，或沒有具體變更集的抽象架構討論。如果你只是想做快速 sanity check，而且不需要逐行發現，那它也不是最合適的選擇。

對 review for PR Review 會有什麼期待？

你可以期待簡潔、以修正為導向、並且有嚴重性優先順序的評論。這個技能的目標是找出阻礙合併的問題，而不是重述整個 repo 或產出一段慶祝式摘要。

如何改進 review 技能

提供更精準的輸入

最強的 review skill 輸入，會明確寫出 base branch、風險最高的子系統，以及你希望遵守的標準。不要只說「review my PR」，而是改成「review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients.」

補上會影響判斷的脈絡

如果這次變更本來就帶有風險，要直接說明。若某種模式在專案政策下是允許的，也要先講清楚。這樣可以減少誤判，並讓 review 聚焦在真正的取捨，而不是反覆爭論已經定案的選擇。

請求你需要的輸出格式

如果你要的是以上線為導向的輸出，就要求 findings 具備 file:line、severity，以及具體修正方式。如果你只想看阻擋項，也要直接說。如果你需要專家覆蓋範圍，就明確提出來，避免 review 停在第一輪就結束。

在第一輪之後再迭代

先用第一輪 review 修掉明顯問題，再對更新後的 diff 重新跑 review。最大的品質提升通常來自三件事：把範圍講清楚、把比較 branch 收窄、以及把你最在意的風險區域明確餵給技能。