用途：审查 GitHub 上的 Pull Request，并以仿佛真人手打的语气发布行内评论。风格定义在 reference/voice.md 中，替换该文件即可改变语气。
安装：将该文件夹放到智能体可发现技能的任意位置，例如 ~/.agents/skills/、~/.config/cloudcode/skills/，或 ~/.config/cloudcode/cloudcode.json 中 skills.paths 注册的任意绝对路径。运行前设置 SKILL_DIR： SKILL_DIR=~/.agents/skills/github-pr-review 依赖已认证的 gh 与 python3，无其他依赖；若存在 pyyaml 则使用，否则降级并给出警告。
限制：评论必须指向可在该行观察到的事实，而非要求作者自行推导；这是决定评论是否被采用的最强预测因素。分析范围有意限定为“人读该 PR 时能看到的内容”，不得阅读第三方或依赖源码、不得执行被审代码、不得全仓库扫描以证明某事物不存在、不得构造漏洞载荷、不得跨超过一跳。这些评论以人类名义发布，故不得出现只有深挖或运行代码才能得出的结论。分析阶段与语气阶段分离：先无线索约束地找缺陷，再对幸存项赋以语气。分析可并行分派子智能体，语气与标注不可并行。
流程：Step 1 收集 PR 信息与既有评论（existing_comments.py），克隆 PR head 到本地树；大型 PR 不要运行 gh pr diff。Step 2 用 plan_review.py 生成文件跳过清单、评论预算、车道划分与预计时间，并就测试/网页目录是否纳入征询用户，然后公布检查点。Step 3 分析（小 PR 内联，大 PR 用 batch_task 分派文件车道与一致性车道）。Step 4 由 verify_findings.py 依据 verify_steps 计算成本并过滤。Step 5 赋予语气。Step 6 为硬性停止点，用户必须阅读每条评论后才可发布，绝不代替用户未经批准发布。
评论预算按可审查改动量：<50 行 2–3 条，50–200 行 3–5 条，200–600 行 5–8 条，600–1500 行 8–12 条，>1500 行 12–20 条，硬上限 20。同类缺陷出现 3 处及以上合并为一条，锚定最清晰实例。风格、命名与格式问题不作为发现。
不适用场景：审查本地未提交改动或分支间 git diff 应使用 review 技能；用户想要一份详尽的审计报告则不适合本技能，因为其深度限制正是相反方向。若被要求发布用户未读的评论，或刻意隐藏 AI 生成痕迹，则超出本技能用途。