// Use when reviewing code changes, PRs, diffs, or commits. 触发：审查、review、CR、看看这段代码、检查这个 PR、审一下。
生图 / 生成图片 / 画图 — 用 OpenAI gpt-image-2 生成图像。支持文生图、参考图生图 (img2img)、蒙版修补 (inpainting)。当用户要求用 GPT 画图、OpenAI 生图、gpt-image-2、文+图生图、参考图片生成、img2img、inpainting 时必加载此技能。Auth 自动继承 OPENAI_API_KEY / Codex OAuth (Pi/Codex) / .env / config.yaml。
Remove AI writing patterns from English prose. Covers blog posts, technical docs, social copy, release notes, scientific writing. Trigger: deslop, de-AI, make it sound human, remove AI patterns, fix slop, polish, rewrite, sound natural
去除中文写作中的 AI 腔调，让文本像人写的而非模型生成的。覆盖博客、技术文档、推文、发行说明、科学论文等场景。触发词：去 AI 味、改写、润色、审稿、翻译腔重、像人写的、自然一点。英文去 AI 味见 deslop-en
为任意 coding agent 编写高质量任务目标的指南。当用户提到「设定目标」「goal」「任务目标」「持久目标」「完成标准」、或需要为复杂多轮任务（性能优化、调试、迁移、研究复现等）定义可验证的完成条件和约束时触发。
Control herdr from inside it. Manage workspaces and tabs, split panes, run commands, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).
Jupyter Notebook 创建与格式转换技能。当用户提到以下任何请求时必须使用：新建/创建 notebook、Jupyter notebook、.ipynb、jupytext、py:percent、# %% cell 格式、notebook 版本控制、paired notebook、notebook 转 Python、Python 转 notebook、用纯文本写 notebook。即使用户只说「新建一个 notebook」也应触发此技能——先询问用户选用 .py percent format 还是传统 .ipynb，再按选定格式生成。不用于调试已有 notebook 或写普通 Python 脚本。
| 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;