對拉取請求進行程式碼審查
Automated PR code review using multiple AI agents to check for CLAUDE.md violations and critical errors. Use when you need a thorough, high-signal review that filters out false positives and only reports objective issues.
/plugin marketplace add DennisLiuCk/claude-plugin-marketplace/plugin install code-review@claude-plugin-marketplace-zh-tw為給定的拉取請求提供程式碼審查。
要執行此操作，請精確遵循以下步驟：
啟動一個 Haiku 代理檢查以下任一條件是否為真：
如果任何條件為真，請停止且不要繼續。
備註：仍需審查 Claude 生成的 PR。
啟動一個 Haiku 代理返回所有相關 CLAUDE.md 文件的文件路徑列表（不是內容），包括：
啟動一個 Sonnet 代理查看拉取請求並返回變更摘要
並行啟動 4 個代理獨立審查變更。每個代理應返回問題列表，其中每個問題包含描述和標記原因（例如「CLAUDE.md 遵守情況」、「錯誤」）。代理應執行以下操作：
代理 1 + 2：CLAUDE.md 合規性 Sonnet 代理 並行審計變更以確保符合 CLAUDE.md。注意：評估文件的 CLAUDE.md 合規性時，您應該只考慮與該文件或其父目錄共享路徑的 CLAUDE.md 文件。
代理 3：Opus 錯誤代理（與代理 4 並行的子代理） 掃描明顯的錯誤。僅關注差異本身，不要閱讀額外的上下文。只標記重大錯誤；忽略吹毛求疵和可能的誤報。不要標記您無法在 git diff 範圍外驗證的問題。
代理 4：Opus 錯誤代理（與代理 3 並行的子代理） 尋找引入程式碼中存在的問題。這可能是安全問題、不正確的邏輯等。只尋找變更程式碼範圍內的問題。
關鍵：我們只需要高信號問題。 這意味著：
我們不需要：
如果您不確定某個問題是否真實，請不要標記它。誤報會削弱信任並浪費審查者的時間。
除上述外，每個子代理都應被告知 PR 標題和描述。這將有助於提供關於作者意圖的上下文。
對於上一步中代理 3 和 4 發現的每個問題，啟動並行子代理來驗證該問題。這些子代理應獲得 PR 標題和描述以及問題描述。代理的工作是審查問題以高置信度驗證所述問題確實是問題。例如，如果標記了「變數未定義」這樣的問題，子代理的工作是驗證程式碼中確實如此。另一個例子是 CLAUDE.md 問題。代理應驗證被違反的 CLAUDE.md 規則適用於此文件且確實被違反。對於錯誤和邏輯問題使用 Opus 子代理，對於 CLAUDE.md 違規使用 Sonnet 代理。
過濾掉步驟 5 中未被驗證的任何問題。此步驟將為我們的審查提供高信號問題列表。
最後，在拉取請求上發表評論。 編寫評論時，請遵循以下準則： a. 保持輸出簡潔 b. 避免使用表情符號 c. 為每個問題連結並引用相關程式碼、文件和 URL d. 引用 CLAUDE.md 違規時，您必須引用被違反的 CLAUDE.md 確切文字（例如，CLAUDE.md 說：「使用 snake_case 作為變數名稱」）
在步驟 4 和 5 中評估問題時使用此列表（這些是誤報，不要標記）：
注意事項：
發現 3 個問題：
<連結到帶有完整 sha1 + 上下文行範圍的文件和行，例如 https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
<連結到帶有完整 sha1 + 上下文行範圍的文件和行>
<連結到帶有完整 sha1 + 上下文行範圍的文件和行>
未發現問題。已檢查錯誤和 CLAUDE.md 合規性。
https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar 這樣的命令將不起作用，因為您的評論將直接在 Markdown 中渲染。L4-7）