{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Github Code Review

通过 gh 或 REST 审查 PR：差异对比、行内评论。

Skill 元数据


来源	内置（默认安装）
路径	`skills/github/github-code-review`
版本	`1.1.0`
作者	Hermes Agent
许可证	MIT
平台	linux, macos, windows
标签	`GitHub`, `Code-Review`, `Pull-Requests`, `Git`, `Quality`
相关 skill	`github-auth`, `github-pr-workflow`

参考：完整 SKILL.md

信息

以下是 Hermes 在触发此 skill 时加载的完整 skill 定义。这是 agent 在 skill 激活时所看到的指令内容。

GitHub Code Review

在推送前对本地变更执行代码审查，或审查 GitHub 上的开放 PR。此 skill 大部分功能使用纯 git 命令——gh/curl 的区别仅在 PR 级别的交互中才有意义。

前置条件

已通过 GitHub 身份验证（参见 github-auth skill）

位于 git 仓库内部

设置（用于 PR 交互）

1. 审查本地变更（推送前）

此部分为纯 git 操作——适用于所有环境，无需 API。

获取差异

审查策略

先了解全局：

逐文件审查——使用 read_file 查看已变更文件的完整上下文，并通过差异了解具体改动：

检查常见问题：

向用户呈现结构化反馈。

审查输出格式

审查本地变更时，按以下结构呈现结果：

## Code Review Summary

### Critical
- **src/auth.py:45** — SQL injection: user input passed directly to query.
  Suggestion: Use parameterized queries.

### Warnings
- **src/models/user.py:23** — Password stored in plaintext. Use bcrypt or argon2.
- **src/api/routes.py:112** — No rate limiting on login endpoint.

### Suggestions
- **src/utils/helpers.py:8** — Duplicates logic in `src/core/utils.py:34`. Consolidate.
- **tests/test_auth.py** — Missing edge case: expired token test.

### Looks Good
- Clean separation of concerns in the middleware layer
- Good test coverage for the happy path

2. 审查 GitHub 上的 Pull Request

查看 PR 详情

使用 gh：

使用 git + curl：

在本地检出 PR 进行完整审查

此操作使用纯 git——无需 gh：

使用 gh（快捷方式）：

在 PR 上留下评论

通用 PR 评论——使用 gh：

通用 PR 评论——使用 curl：

留下行内审查评论

单条行内评论——使用 gh（通过 API）：

单条行内评论——使用 curl：

提交正式审查（批准 / 请求变更）

使用 gh：

使用 curl——原子性提交包含多条评论的审查：

事件值："APPROVE"、"REQUEST_CHANGES"、"COMMENT"

line 字段指文件新版本中的行号。对于已删除的行，使用 "side": "LEFT"。

3. 审查清单

执行代码审查（本地或 PR）时，系统性地检查以下内容：

正确性

代码是否实现了其声称的功能？

边界情况是否已处理（空输入、null、大数据、并发访问）？

错误路径是否优雅处理？

安全性

无硬编码的密钥、凭据或 API key

对用户输入进行验证

无 SQL 注入、XSS 或路径遍历

在需要的地方进行身份验证/授权检查

代码质量

命名清晰（变量、函数、类）

无不必要的复杂性或过早抽象

DRY——无应提取的重复逻辑

函数职责单一

测试

新代码路径是否已测试？

正常路径和错误情况是否已覆盖？

测试是否可读且可维护？

性能

无 N+1 查询或不必要的循环

在适当位置使用缓存

异步代码路径中无阻塞操作

文档

公共 API 已文档化

非显而易见的逻辑有注释说明"为什么"

若行为发生变化，README 已更新

4. 推送前审查工作流

当用户要求"审查代码"或"推送前检查"时：

git diff main...HEAD --stat——了解变更范围

git diff main...HEAD——阅读完整差异

对每个已变更的文件，如需更多上下文则使用 read_file

应用上述审查清单

按结构化格式呈现结果（Critical / Warnings / Suggestions / Looks Good）

若发现严重问题，在用户推送前主动提出修复

5. PR 审查工作流（端到端）

当用户要求"审查 PR #N"、"查看这个 PR"，或提供 PR URL 时，按以下步骤执行：

第一步：设置环境

第二步：收集 PR 上下文

获取 PR 元数据、描述和已变更文件列表，在深入代码之前了解变更范围。

使用 gh：

使用 curl：

第三步：在本地检出 PR

这样可以完整使用 read_file、search_files，以及运行测试的能力。

第四步：阅读差异并理解变更

对每个已变更的文件，使用 read_file 查看变更周围的完整上下文——仅凭差异可能遗漏只有在周围代码中才能发现的问题。

第五步：在本地运行自动化检查（如适用）

第六步：应用审查清单（第 3 节）

逐一检查每个类别：正确性、安全性、代码质量、测试、性能、文档。

第七步：将审查结果发布到 GitHub

汇总结果并以正式审查形式提交，附带行内评论。

使用 gh：

使用 curl——原子性提交包含多条行内评论的审查：

第八步：同时发布摘要评论

除行内评论外，还需留下顶层摘要，让 PR 作者一目了然地了解全貌。使用 references/review-output-template.md 中的审查输出格式。

使用 gh：

第九步：清理

决策：批准 vs 请求变更 vs 评论

批准（Approve）——无严重或警告级别的问题，仅有次要建议或完全通过

请求变更（Request Changes）——存在任何在合并前应修复的严重或警告级别问题

评论（Comment）——有观察和建议，但无阻塞性问题（在不确定或 PR 为草稿时使用）

"Github Code Review — 通过 gh 或 REST 审查 PR：差异对比、行内评论"

Github Code Review#

Skill 元数据#

参考：完整 SKILL.md#

GitHub Code Review#

前置条件#

设置（用于 PR 交互）#

1. 审查本地变更（推送前）#

获取差异#

审查策略#

审查输出格式#

2. 审查 GitHub 上的 Pull Request#

查看 PR 详情#

在本地检出 PR 进行完整审查#

在 PR 上留下评论#

留下行内审查评论#

提交正式审查（批准 / 请求变更）#

3. 审查清单#

正确性#

安全性#

代码质量#

测试#

性能#

文档#

4. 推送前审查工作流#

5. PR 审查工作流（端到端）#

第一步：设置环境#

第二步：收集 PR 上下文#

第三步：在本地检出 PR#

第四步：阅读差异并理解变更#

第五步：在本地运行自动化检查（如适用）#

第六步：应用审查清单（第 3 节）#

第七步：将审查结果发布到 GitHub#

第八步：同时发布摘要评论#

第九步：清理#

决策：批准 vs 请求变更 vs 评论#

Github Code Review

Skill 元数据

参考：完整 SKILL.md

GitHub Code Review

前置条件

设置（用于 PR 交互）

1. 审查本地变更（推送前）

获取差异

审查策略

审查输出格式

2. 审查 GitHub 上的 Pull Request

查看 PR 详情

在本地检出 PR 进行完整审查

在 PR 上留下评论

留下行内审查评论

提交正式审查（批准 / 请求变更）

3. 审查清单

正确性

安全性

代码质量

测试

性能

文档

4. 推送前审查工作流

5. PR 审查工作流（端到端）

第一步：设置环境

第二步：收集 PR 上下文

第三步：在本地检出 PR

第四步：阅读差异并理解变更

第五步：在本地运行自动化检查（如适用）

第六步：应用审查清单（第 3 节）

第七步：将审查结果发布到 GitHub

第八步：同时发布摘要评论

第九步：清理

决策：批准 vs 请求变更 vs 评论