GitHub 代码审查

这个技能解决什么问题

团队用 GitHub Pull Request 协作，PR 里往往堆了几十甚至几百个文件的改动。在网页上逐行翻 diff 很慢；想在某一行留评论，还要手动定位文件、行号，再逐条提交。更麻烦的是评论散落在页面各处，事后追溯困难。这个技能把 PR 审查搬进 Agent 的上下文：直接读取差异、定位到具体行、按统一的审查标准输出行内评论。

它是怎么工作的

核心能力有三块：

• 差异读取：拉取 PR 的 diff，按文件、按 hunk 审查，重点关注改动行及其上下文。
• 行内评论：通过 gh CLI 或 GitHub REST API，把评论精确挂到具体文件的具体行上，而不是只写一条笼统的顶层意见。
• 双通道实现：有 gh 的环境优先走 CLI；需要精细控制或没有 CLI 时退回 REST 接口。

典型流程：

1. 确认目标 PR 与仓库，获取改动范围。
2. 按文件读取 diff，跳过 lock 文件、生成代码等无关内容。
3. 对可疑改动定位到行，组织评论：问题是什么、为什么需要改、建议怎么改。
4. 逐条提交行内评论，最后汇总成一份整体审查意见。

审查标准由调用方在提示词里给出，比如团队代码规范、安全红线、性能要求。技能本身不内置固定规则，规则来自你的上下文。

适用边界与注意点

• 只针对 GitHub 托管的仓库；GitLab 或自建平台不适用。
• 提交评论需要具备写权限的凭证，gh auth login 或 GITHUB_TOKEN，权限不足会直接失败。
• REST 通道受 API 速率限制，审查大 PR 时要注意分页和限流。
• 它是审查执行器，不是判断力本身。diff 聚焦时能给出有价值的意见；超大 PR 建议先拆分或只挑关键文件。
• 评论过密会变成噪音，真正有问题的行留评论，风格类意见合并成顶层评论。
• 可与 github-auth（鉴权）、github-pr-workflow（PR 生命周期）等技能搭配，覆盖从登录、开 PR 到审查的完整链路。
• MIT 许可，当前版本 1.1.0，支持 Linux、macOS、Windows。