PR 審查
審查 PR 的程序。審查的規則（語氣、意見分類、決策流程、不該做的事）存在於 Playbook 的「PR Reviews」之下；此技能是如何進行審查。請勿在此重述規則，只需應用它們。Playbook 的「共享標準」適用於整個流程（簡潔、無 AI 廢話、驗證而非斷言、絕不虛構）。
審查前
- 先索取工單。 根據 Playbook 的強制第一步，在取得工單前，請勿擷取 diff 或分析任何內容。工單設定工作類型（功能 vs. 後續修正 vs. 調查）與驗收標準，這些會改變審查方式。
- 確認 PR：如果未提供，請索取 PR 編號/URL。
收集背景資訊
- 使用 GitHub CLI 擷取 diff 與中繼資料：
gh pr view <pr>和gh pr diff <pr>。 - 對於調查型 PR，也請檢查
docs/investigations/以了解預期格式。 - 當行為依賴周圍程式碼時，請完整閱讀變更的檔案，而不僅僅是 diff hunk。
審查
逐檔案瀏覽 diff。應用 Playbook 的「PR Reviews」章節：
- 執行 Playbook 檢查清單（驗收標準、編譯/測試失敗、呼叫者已更新、測試覆蓋率、調查的證據）。
- 根據 Playbook，將每個發現分類為阻塞、小問題或問題。
- 使用 Playbook 的決策流程判斷每個觀察是否值得留言。
- 範圍規則因工單類型而異（後續修正：在此解決所有問題；功能：重構是有效的）。從工單確認類型。
- 根據 Playbook 的「驗證，而非斷言」：在重複陳述之前，先自行檢查主張。執行
gh pr checks <pr>檢查 CI，在 repo 中 grep 已移除的符號。PR 描述是作者的聲明，而非證據。 - 根據 Playbook 的「不應默默移除現有行為」：未經確認的行為回歸是阻塞性發現，即使作者已在描述中標記。
輸出
遵循 Playbook 的「PR Reviews > 格式」。直接在聊天中輸出審查結果（除非使用者要求，否則不要輸出成檔案），格式為一行裁決後接發現。這不是一篇散文、對話記錄，或「已收集背景資訊」/「初步審查」之類的章節。每個發現的格式為：一個位置+程式碼參考行、註解放在可複製的 fenced block 中、然後說明原因。具體來說，一個發現看起來像這樣：
### 阻塞
`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```
註解（貼到 PR 中）：
這會遺失這些寫入所依賴的最終一致性重試機制。Core 與 Users 之間的延遲會以 NotFound 的形式浮現，而新的僅暫時性錯誤政策不會重試此類錯誤，因此寫入會立即失敗。
原因：驗收標準 #3 要求確認沒有路徑依賴於重試應用層級錯誤；此路徑確實依賴於此，而 diff 移除了它，但未確認該時間窗已消失。
````
每個發現重複一個這樣的區塊，分組在 `### 阻塞` / `### 小問題` / `### 問題` 之下（省略空白組別）。「註解」後的 fenced block 是使用者唯一會複製到 GitHub 的內容；其他所有內容僅供導航使用。如果一切良好，只需輸出裁決行。
## 張貼（僅在使用者要求時）
如果使用者希望直接張貼留言而非在聊天中草擬，請先確認，然後使用 `gh pr review` / `gh pr comment`。預設為在聊天中草擬。