Menu
Use when reviewing code changes, PRs, diffs, or commits. 触发：审查、review、CR、看看这段代码、检查这个 PR、审一下。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Reviews code diffs, PRs, issue queues, release readiness, commits, pushes, publishing, and project audits. Use when users ask in any language for code review, issue or PR triage, release gates, publishing follow-through, or project audits. Not for debugging root causes or prose review.
Produces distinctive, production-grade UI for pages, components, visual interfaces, typography, and screenshot-driven polish. Use when users ask in any language for UI, page, component, frontend, typography, screenshot-grounded visual polish, or complaints that a screen looks unclear, ugly, inconsistent, or visually wrong. Not for backend logic or data pipelines.
Use when the user requests diagrams, flowcharts, architecture diagrams, ER diagrams, UML / sequence / class diagrams, network topology, ML/DL model figures (Transformer/CNN/LSTM), mind maps, or any visualization. Also use proactively when explaining systems with 3+ components, complex data flows, or relationships that benefit from visual representation. Best suited when the diagram needs custom styling, rich shape vocabulary, swimlanes, or exportable images (PNG/SVG/PDF/JPG). Generates .drawio XML and exports locally via the native draw.io desktop CLI.
Runs a budget-aware agent-assisted engineering health audit for instruction/config drift, hooks/MCP, verifier surfaces, and AI maintainability. Use when users ask in any language to audit Claude, Codex, Pi, agent instructions, MCP or hooks, verifier coverage, or AI-maintainability drift. Not for debugging application code or reviewing PRs.
Finds root cause before applying fixes for errors, crashes, regressions, failing tests, broken behavior, and screenshot-reported defects. Use when users report in any language errors, crashes, broken behavior, regressions, failing tests, screenshot evidence, or something that used to work and now fails. Not for code review or new features.
Runs a six-phase research workflow that turns unfamiliar domains, source bundles, or collected material into publish-ready output. Use when users ask in any language to research, study, deep-dive, compile sources, synthesize unfamiliar material, or turn a source bundle into a coherent reference. Not for quick lookups or single-file reads.
| 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;