メニュー
Use when reviewing code changes, PRs, diffs, or commits. 触发：审查、review、CR、看看这段代码、检查这个 PR、审一下。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ninehills/skills --skill review-codeコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | review-code |
| description | Use when reviewing code changes, PRs, diffs, or commits. 触发：审查、review、CR、看看这段代码、检查这个 PR、审一下。 |
| version | 1.1.0 |
| author | Hermes Agent |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["code-review","代码审查","review","quality","中文"],"related_skills":["requesting-code-review","github-code-review","code-review"]}} |
基于 Google 工程实践整理的代码审查指南。首要目的：确保代码库的整体代码健康状况随时间推移而改善。 不存在"完美"代码，只有更好的代码——追求持续改善，而非追求完美。
评审者应在 CL 明确改善系统代码健康状态时予以通过，即使 CL 并不完美。
三大原则：
使用场景：
requesting-code-review 审查阶段的参考标准不适用：
与 requesting-code-review 的区别： 本技能定义审查标准和方法（审查什么、怎么看）。requesting-code-review 定义提交前的自动化流水线（安全扫描、基线对比、auto-fix 循环）。
审查应覆盖以下维度：
| 维度 | 核心问题 |
|---|---|
| 设计 | 代码设计是否合理、与系统适配？ |
| 功能 | 行为是否符合作者意图？对用户是否有益？ |
| 复杂度 | 能否更简单？未来其他开发者能否轻松理解和修改？ |
| 测试 | 是否有正确、设计良好的自动化测试？ |
| 命名 | 变量、类、方法等命名是否清晰？ |
| 注释 | 注释是否清晰有用？注释应解释为什么而非是什么。 |
| 风格 | 是否遵循风格指南？ |
| 文档 | 是否同步更新了相关文档？ |
| 每一行 | 人工编写的每行代码都要看。数据文件、生成代码可略过。 |
| 上下文 | 在更广阔上下文中审视——整个文件、整个系统。不接受降低代码健康状态的 CL。 |
第一步：整体视角
第二步：审查核心部分
第三步：按合理顺序审查其余部分
逐级检查：单行 → 函数 → 类是否过于复杂？
"过于复杂" = 代码读者无法快速理解、调用或修改时容易引入 bug。
特别警惕过度工程：代码做得比需要的更通用，或添加了当前系统不需要的功能。解决现在已知的问题，而非猜测未来可能需要解决的问题。
好名字足够长以完全传达该项是什么/做什么，但不至于长到难以阅读。
| 标签 | 含义 |
|---|---|
| Nit | 小事，技术上应该做但影响不大 |
| Optional / Consider | 可能是个好主意，但不严格要求 |
| FYI | 不期望在本 CL 中修改，但未来可考虑 |
使用标签让审查意图明确，帮助作者确定优先级。
如果要求开发者解释一段代码，通常结果应该是他们重写代码使其更清晰。偶尔添加代码注释也是合适的回应（前提是不是仅仅解释过于复杂的代码）。审查工具中写的解释对未来代码读者没有帮助。
开发者常表示会在后续 CL 中清理——经验表明，除非在立即写清理 CL，否则很少真正发生。
CL 描述应传达：做了什么变更？ + 为什么做这些变更？
第一行规则： 简短摘要（祈使句），独立存在让未来搜索代码历史的人能快速理解。第一行后空一行。
坏的描述： "Fix bug." / "Fix build." / "Add patch." / "Phase 1."
好的描述：
RPC: 移除 RPC 服务器消息空闲列表的大小限制。
像 FizzBuzz 这样的服务器有非常大的消息，能从复用中受益。
增大空闲列表，并添加一个 goroutine 随时间缓慢释放空闲列表条目，
使空闲服务器最终释放所有空闲列表条目。
一个 CL = 一个自包含的变更，只解决一件事。通常 100 行合理，1000 行太大。文件分散程度也影响"大小"——一个文件中的 200 行可能 OK，散在 50 个文件中通常太大。
拆分策略：
git diff --cached
# 如果为空
git diff HEAD~1 HEAD
## 审查总结
[1-2 句整体评估]
## 设计层面
- [设计相关评论]
## 关键问题（必须修复）
- 问题 1：[描述 + 建议修复方案]
- 问题 2：...
## 建议（可选）
- 建议 1：[描述]
## 好的实践（肯定）
- [开发者做得好的地方]
## 问题
- [需要开发者澄清的问题]
Python
# 差: SQL 注入风险
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
# 好: 参数化查询
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
# 差: Shell 注入
os.system(f"ls {user_input}")
# 好: 安全子进程
subprocess.run(["ls", user_input], check=True)
# 差: 危险 eval/exec
eval(user_input)
# 好: 使用安全的解析方式
JavaScript
// 差: XSS 风险
element.innerHTML = userInput;
// 好: 安全文本内容
element.textContent = userInput;