AI Skills
pr-review

pr-review

熱門

審查 PyTorch Pull Request 的程式碼品質、測試涵蓋率、安全性與向後相容性。當需要審查 PR、被要求審查程式碼變更，或是使用者提到「review PR」、「code review」、「check this PR」時使用。

10萬星標
2.9萬分支
更新於 2026/8/3
獲取技能源代碼

相關技能

gifgrep39萬blucli38萬recsys-pipeline-architect24萬
SKILL.md
唯讀
名稱
pr-review
描述

審查 PyTorch Pull Request 的程式碼品質、測試涵蓋率、安全性與向後相容性。當需要審查 PR、被要求審查程式碼變更，或是使用者提到「review PR」、「code review」、「check this PR」時使用。

PyTorch PR Review Skill

審查 PyTorch Pull Request，專注於 CI 無法自動檢查的項目：程式碼品質、測試涵蓋率是否充足、安全性漏洞以及向後相容性。

Usage Modes

No Argument

若使用者呼叫 /pr-review 且未帶任何引數，請勿執行審查。改為詢問使用者想要審查什麼：

你希望我審查什麼？

  • PR 編號或 URL（例如 /pr-review 12345）
  • 本地分支（例如 /pr-review branch）

Local CLI Mode

使用者提供 PR 編號或 URL：

/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345

若需要逐行具體意見的詳細審查：

/pr-review 12345 detailed

使用 gh CLI 擷取 PR 資料：

# 取得 PR 詳細資訊
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits

# 取得 diff 差異
gh pr diff <PR_NUMBER>

# 取得 PR 留言與審查意見
gh pr view <PR_NUMBER> --json comments,reviews

Local Branch Mode

審查當前分支中未併入 main 的變更：

/pr-review branch
/pr-review branch detailed

使用 git 命令取得分支變更：

# 取得目前分支名稱
git branch --show-current

# 取得相較於 main 變更的檔案清單
git diff --name-only main...HEAD

# 取得相較於 main 的完整 diff
git diff main...HEAD

# 取得分支的 commit 紀錄
git log main..HEAD --oneline

# 取得 diff 統計資訊（變更檔案數、新增行數、刪除行數）
git diff --stat main...HEAD

關於本地分支審查：

  • 「Summary」應根據 commit 訊息與 diff，描述該分支變更所實現的內容
  • 審查標頭請使用目前分支名稱，而非 PR 編號
  • 其餘所有審查標準皆與 PR 審查相同

GitHub Actions Mode

當在 GitHub PR 上透過 @claude /pr-review 呼叫時，Action 會預先擷取 PR 的中繼資料（metadata）並注入 prompt 中。可透過 prompt 中是否存在 <formatted_context>、<pr_or_issue_body> 與 <comments> 標籤來判斷此模式。

Prompt 中已包含：

  • PR 中繼資料（標題、作者、分支名稱、新增/刪除行數、變更檔案數）
  • PR 內文/說明
  • 所有留言與審查意見（含檔案/行數參照）
  • 變更檔案清單，附帶路徑與變更類型

使用 git 命令取得 diff 與 commit 歷史。基底分支（base branch）名稱位於 prompt 上下文中（尋找 PR Branch: <head> -> <base> 或 baseBranch 欄位）。

# 取得相較於基底分支的完整 diff
git diff origin/<baseBranch>...HEAD

# 取得 diff 統計資訊
git diff --stat origin/<baseBranch>...HEAD

# 取得此 PR 的 commit 歷史
git log origin/<baseBranch>..HEAD --oneline

# 若基底分支參照不存在，請先拉取
git fetch origin <baseBranch> --depth=1

在此模式下切勿使用 gh CLI 命令——僅能使用 git 命令。
所有 PR 中繼資料、留言與審查意見均已存在於 prompt 上下文中；僅需要透過 git 擷取 diff 與 commit 紀錄。

Review Philosophy

單行程式碼也可能產生深遠的跨模組影響：漏掉 device guard 會在多 GPU 環境下造成隱蔽的資料損毀；漏掉 Composite dispatch key 會破壞所有樹外（out-of-tree）後端；手動做 dtype 檢查而非使用 TensorIterator 會默默跳過型態提升（type promotion）。請將每一行程式碼都視為關鍵承重結構（load-bearing）。

  1. 只回報問題 — 審查輸出必須僅包含問題、疑慮以及可執行的修改建議。切勿提及做得正確的地方，切勿讚揚良好的設計決策，也切勿解釋為什麼某些寫法沒問題。若某個章節沒有問題，請直接完全省略。讀者的時間非常寶貴——每一句話都必須指出需要修正或需要進一步討論之處。
  2. 深入調查，切勿猜測 — 當不確定檢查清單中的項目是否適用時，請衍生子 Agent（sub-agent）去閱讀相關程式碼。猜錯的審查者只會提供負面價值。
  3. 審查架構設計，而不只是實作 — PR 即使實作完全正確，也可能採用了糟糕的設計。請質疑旁路通訊（side-channel communication）、私有開關標記（private flags），並要求元件之間的新合約必須附帶具體的介面文件。
  4. 專注於 CI 無法檢查的內容 — 不要針對排版格式、linting、型別錯誤或 CI 失敗發表意見。請專注於設計品質、介面正確性、執行緒安全性（thread safety）、向後相容性影響、測試充足性以及是否符合設計模式。
  5. 所有問題都是必須修復的重點 — 沒有所謂的「小問題（nits）」。只要值得提出，就值得修復。每一個不一致都會隨著時間推移而損害程式碼庫。
  6. 必須具體且具可執行性 — 標註檔案路徑與行號。明確指出作者應該使用的函式、類別或檔案名稱。
  7. 契合周遭上下文 — 觀察同一個檔案中類似功能是如何實作的。同一檔案內的模式不一致絕對是錯誤的。
  8. 假定作者具備專業能力 — 作者了解 PyTorch；僅需解釋非顯而易見的背景資訊。
  9. 絕不重複 — 每項觀察結果只能出現在審查輸出的其中一個章節中。

Using sub-agents

審查檢查清單非常龐大，你不可能把每個基礎架構系統的完整上下文都記在腦中。請衍生子 Agent 來調查檢查清單項目是否適用：閱讀周圍程式碼、PR 應該使用的基礎設施、或是應該存在但未寫的測試。針對獨立領域，請平行衍生子 Agent。中等規模的 PR 通常會衍生 3 到 8 個子 Agent。

Review Workflow

Step 1: Understand Context

在進行審查前，先建立對 PR 改動內容與原因的理解：

  1. 從標題、說明或 issue 中確認變更的目的
  2. 按類型對變更進行分組（新程式碼、測試、設定檔、文件）
  3. 注意變更的範圍（受影響的檔案、變更的行數）
  4. 衍生子 Agent 閱讀每個重大變更檔案周圍未修改的程式碼，以理解現有的模式與基礎架構

Step 2: Deep Review

逐一檢查 diff 中的每一行變更，並根據 review-checklist.md 中的審查檢查清單進行評估。

Step 3: Check Backward Compatibility

根據 bc-guidelines.md 評估向後相容性影響。對於複雜的向後相容性疑慮，請衍生子 Agent 搜尋被修改 API 的現有呼叫者。

Step 4: Formulate Review

整理審查架構，依類別組織可執行的反饋。每項發現都應該要能追溯至 diff 中的特定程式碼行。

Step 5: Fact-Check

起草審查意見後，針對回報的每個問題（平行）衍生子 Agent，透過重新閱讀相關程式碼與周圍上下文來獨立驗證論點。每個子 Agent 會回傳 valid（有效）、invalid（無效）或 needs rewording（需重新措辭）。請剔除無效的問題，並修改其餘問題的措辭。若不確定，請保留該問題，並向作者附註此項信心程度較低。

Output Format

請按以下結構組織你的審查意見。若某個章節沒有問題需要回報，請直接省略——大多數審查應該只有少數幾個章節。請勿撰寫「沒有疑慮」、「看起來很好」或任何肯定性的評語。審查意見中的每一句話都必須指出問題或要求變更。

摘要（Summary）章節是唯一的例外：它應該簡短說明 PR 的作用（1 句話），然後說明發現的問題，或者明確指出未發現任何問題。

## PR Review: #<number>
<!-- 或針對本地分支審查： -->
## Branch Review: <branch-name> (vs main)

### Summary
PR 的作用（1 句話），接著是整體審查結論。

### Code Quality
[僅列出問題]

### Infrastructure
[僅列出問題 — 標註違反的檢查清單項目]

### Testing
[僅列出問題 — 缺失的測試、錯誤的模式、涵蓋率不足]

### API Design
[僅列出問題]

### Security
[僅列出問題]

### Thread Safety
[僅列出問題]

### Backward Compatibility
[僅列出問題]

### Performance
[僅列出問題]

### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**

缺失測試（新功能無測試、bug 修正無迴歸測試）一律代表 **Request Changes**。

[簡短理由 — 著重說明阻礙批准的原因（若有）]

Specific Comments (Detailed Review Only)

僅在使用者要求「詳細（detailed）」或「深入（in depth）」審查時才包含此章節。

切勿重複已在其他章節中提出的觀察結果。 此章節用於提供不適合歸入上述分門別類章節的特定檔案補充反饋。

當收到要求時，新增帶有行數參照的檔案特定反饋：

### Specific Comments
- `src/module.py:42` - 建議將此邏輯擷取至具名函式中以提升清晰度
- `test/test_feature.py:100-105` - 缺少輸入為 None 時的錯誤狀況測試
- `torch/nn/modules/linear.py:78` - 此配置可移至迴圈外部

Files to Reference

進行審查時，請查閱這些專案檔案以取得上下文背景——請閱讀它們而非依賴記憶，因為這些檔案會頻繁變動：

  • CLAUDE.md - 程式碼風格哲學與測試模式
  • CONTRIBUTING.md - PR 要求與審查流程
  • torch/testing/_internal/common_utils.py - 測試模式與工具函式
  • torch/testing/_internal/opinfo/core.py - OpInfo 測試框架
  • aten/src/ATen/native/native_functions.yaml - 運算子宣告（用於檢查標籤、dispatch keys、結構化 kernel）
  • tools/autograd/derivatives.yaml - 反向傳播公式（用於檢查 op 是否應在此註冊）
  • aten/src/ATen/native/tags.yaml - 運算子語意標籤