PR 審查
這些規則適用於任何審查者，無論是人類還是代理（Copilot code review、Claude 等）。
姊妹技能 github 涵蓋了作者方面的內容：修復評論、回覆及請求下一次審查。
若倉庫本身的審查規則（AGENTS.md、CONTRIBUTING.md、風格指南）與此技能衝突，則以倉庫規則為準。
審查的目標是讓一個正確的 PR 被合併。不是為了找到可以說的話。 「未發現問題」也是良好的結果。
提出發現的標準
只有在能描述出真實的失敗場景時，才提出發現：一個真實的調用者、輸入或設定，以及它產生的錯誤結果。如果你不能用一兩句話寫出這個場景，就不要提出。
| 嚴重性 | 適用情況 |
|---|---|
| 阻塞性 | 常見路徑上的錯誤結果、安全漏洞、資料遺失、損壞的建置或測試、對公開 API 的破壞性變更，或明顯違反倉庫中書面規則的狀況 |
| 應修復 | 較不常見路徑上的真實錯誤、缺少新行為的測試、或會導致讀者在正常情況下做錯事的文件或說明 |
| 小問題 | 命名、措辭或小幅清晰度修正。可選，非強制。每輪審查最多三條，且僅限第一輪 |
不要提出：
- 需要不切實際輸入、配置錯誤環境，或攻擊者已擁有攻擊本應賦予的權限的假設性問題。
- 針對沒有任何調用者能達到的情況的防禦性程式碼（例如「考慮添加空值檢查」）。
- 任何倉庫中的格式化工具、linter 或類型檢查器已強制執行的內容。
- 兩種合理方法之間的個人偏好。
- 沒有熱路徑或測量依據的性能問題。
- 要求擴大 PR 範圍：PR 未計畫進行的功能、重構或清理。
- 未被 PR 修改的程式碼中的問題，除非 PR 使其惡化。如果其中存在嚴重狀況，可標記一次，註明預先存在，不阻塞。
對於文件、技能和其他說明，問一個問題：按照此文字操作的讀者是否會在正常情況下做錯事？針對罕見設定的遺漏最多是小問題。不要要求窮舉所有邊緣情況。
在審查輪次中收斂
一個 PR 應隨著每次審查而更加安靜，而不是更加嘈雜。
- 第 1 輪（首次審查）：完整的 diff，所有嚴重性等級，小問題數量按上述上限。
- 第 2 輪及之後（自上次審查以來的新提交）：
- 僅審查自上次審查以來變更的部分，並檢查你的先前發現是否已被修復。
- 不要對你已審查過且未變更的程式碼提出新的發現。如果你在那裡遺漏了某件事，只有當它是阻塞性時才提出。
- 不提出小問題。
- 如果作者已回覆理由，不要重新提出該發現，除非你有新的證據證明該理由是錯誤的。僅有分歧不足以構成新證據。
- 如果沒有符合標準的發現，用一行說明即可停止。不要為了湊數而審查。
撰寫發現
- 每條評論一個問題，並錨定到它所涉及的程式碼行。
- 以嚴重性開頭：
Blocking:、Should fix:或Nit:。 - 然後用一兩句話描述失敗場景，接著給出最小可行修復方案。
- 每輪審查最多 5 條發現，按嚴重性從高到低排列。如果還有更多，將其餘內容簡短列出在總結中。將重複的發現合併為一條評論，列出所有位置。
- 具體且中立。不要使用讚美填充，不要使用模糊的「你可能需要考慮」。
總結
以簡短總結結尾：
- 判決：Approve、Approve with nits 或 Changes requested（僅在至少有一條阻塞性發現時）。
- 按嚴重性統計數量。
- 在第 2 輪或之後：說明哪些先前的發現現已修復，哪些仍未解決。
在循環中以代理身份審查
當另一個代理正在修復你的發現並請求你進行下一次審查時：
- 將作者的回覆視為審查的一部分。「已在 abc1234 中修復」表示檢查該提交。「保持不變，因為……。」表示該發現已關閉，除非理由是錯誤的。
- 在三輪之後，僅提出阻塞性發現，並說明剩餘項目由作者自行決定。