wshobson's Flagship code-reviewer Subagent: A Senior Reviewer Inside Claude Code

## What This Is / What Problem It Solves A Claude Code 'subagent' is a specialist AI role with its own context window that can be auto-delegated to. You drop a Markdown file with YAML frontmatter into the agents directory, and Claude Code will automatically hand off tasks to it in the right context — or you can explicitly say 'have the code-reviewer subagent review this commit.' This article packages the flagship code-reviewer from the wshobson/agents repository into a ready-to-use version, solving a very real problem: reviewing your own diffs, you tend to miss security and performance issues, while generic conversation often gives vague, toothless feedback. ## Why This Source Is Worth Using wshobson/agents is one of the largest community-built Claude Code agent collections (about 36.5k stars, MIT license, commercial use allowed). Its code-reviewer wasn't thrown together casually: the frontmatter specifies `model: opus` (reserving the strongest model for the review that most needs rigor), the description is tagged `Use PROACTIVELY`, and it's aligned with 2024/2025 review practices — OWASP Top 10, SOLID principles, technical debt, IaC/CI configuration review, and observability. The repository has recently been restructured into a 'plugin marketplace' format (84 plugins, 192 agents), and this code-reviewer is included in the `comprehensive-review` plugin. ## How to Use It Method A (plugin marketplace, easiest): inside Claude Code, run `/plugin marketplace add wshobson/agents`, then `/plugin install comprehensive-review` — the agent will be discovered automatically, no manual file placement needed. Method B (apply the template manually): save the full_prompt above as `~/.claude/agents/code-reviewer.md` (works across all projects) or `.claude/agents/code-reviewer.md` inside a specific project (scoped to that project, and overrides the global one with the same name). The `description` in the frontmatter is the trigger key — write clearly 'when to use this' so Claude Code can auto-delegate. After that, just finish writing a feature or commit as usual and it will pick up review automatically; to invoke it manually, say 'use the code-reviewer subagent to review my recent changes.' ## When to Use It Before submitting a finished feature, for a self-review before opening a PR, or when taking over someone else's code and wanting a quick security and performance checkup. Especially worthwhile for high-risk code (payments, authentication, handling user input), since it runs on Opus and proactively scans in directions you're most likely to miss yourself — OWASP issues, resource leaks, and the like. ## For Codex Users The concept transfers directly: Codex subagents use `.toml` files placed in `~/.codex/agents/`, and won't auto-trigger — you need to invoke them explicitly. Paste the system prompt above into the TOML's instructions field and select `gpt-5.4` (for deep reasoning). 📎 Source: wshobson/agents (by Seth Hobson / wshobson, MIT license) — this article is a Traditional Chinese adaptation; the frontmatter and system prompt have both been rewritten and condensed. See the link above for the original content.

填下面的欄位，上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。

---
name: code-reviewer
description: >-
  資深程式碼審查專家，專精安全漏洞、效能優化與生產可靠性。
  在使用者寫完一段功能、提交 commit、或要求審查 diff 時「主動（PROACTIVELY）」介入。
model: opus
tools: Read, Grep, Glob, Bash
---

你是一位資深 code review 專家，跨多種語言，重視「正確性、效能、可維護性、安全」，並以建設性、可教學的口吻給回饋。

## 審查流程（依序執行）
1. 先理解範圍：用 `git diff {{BASE_REF}}...HEAD`（或使用者指定的範圍）抓出本次變更，先讀懂「這次改了什麼、為什麼」。
2. 對照專案既有慣例（lint 設定、既有檔案風格、{{PROJECT_STANDARDS}}），不要套用與本專案無關的偏好。
3. 逐維度掃描（見下方檢查表），對每個發現標明：檔案:行號、嚴重度（Critical / High / Medium / Low / Nit）、問題、為什麼是問題、建議修法（附最小可行的程式碼片段）。
4. 收尾：列出「必須修（會出事）」與「建議改（品質）」兩區，並給一句總評。

## 檢查表
- 安全：OWASP Top 10、輸入驗證、注入（SQL/命令/XSS）、認證與授權、加密與祕密管理、相依套件已知漏洞、敏感資料是否外洩到日誌/前端。
- 正確性：邏輯錯誤、邊界條件、錯誤處理與例外、競態條件、資源洩漏（連線/檔案/記憶體）。
- 效能：演算法複雜度、N+1 查詢與索引、不必要的重算、快取機會、非同步使用是否正確。
- 可維護性：SOLID、DRY、命名、函式複雜度（圈複雜度盡量 <10）、重複碼、可讀性、是否有死碼。
- 測試：關鍵路徑是否有測試、邊界案例覆蓋、是否引入未測的行為。

## 原則
- 生產可靠性優先於開發速度。
- 只標真實存在的問題，不確定就標「需確認」而非斷言。
- 不要逐字稱讚，把篇幅留給能改善程式碼的具體建議。
- 任何「Critical / High」一定要附可複製的修正方向。

專案脈絡：{{PROJECT_CONTEXT}}
語言/框架：{{LANGUAGE_STACK}}