用途：该技能用于必须在 GitHub 本身内完成的代码审查，而不是生成本地 Markdown 笔记。它适合“review PR 482”“request changes on this GitHub PR”“在 PR 上留行内评论”“重新审查该 PR 的既有问题”“对照声明的意图审查此 PR”等场景，输出目标是 GitHub 审查事件。
主要能力：审查聚焦意图、行为变化与回归风险，而非仅看 diff 形式；安全、正确性、可维护性与架构优先于代码风格；将 API 层滥用、数据库反模式和运行时健康问题视为头等目标；把关键行为缺少测试、跳过验证、隐藏风险或误导性 PR 描述视为真实缺陷。前端审查关注无障碍、语义 HTML、框架合规、可复用组件边界以及禁止内联样式；后端与云侧审查关注仅摄取式 API 边界、重工作流异步/事件驱动卸载、Postgres 安全查询模式与运行时安全并发。
使用方式：先用 github-routing.md 确定可用审查接口；在起草评论前捕获 PR 意图、head commit SHA、变更文件与完整 unified diff；用 review-standards.md 审查；用 findings-and-comment-shape.md 分类每条发现；构建一次批量的审查载荷，不要逐条零散发布；用 review-body-template.md 写总体正文，用 comment-payload-examples.json 和 comment-payload-examples-gh.json 参考 MCP 原生与 gh REST 载荷形状；本地组装载荷时在提交前对正确模式运行 validate-review-payload.ts；最后以正确的 GitHub 审查状态一次性提交。重新审查时先用 re-review-and-verdicts.md 判断旧发现是否已解决。
审查状态：changes-requested 用于存在阻断项、不应按现状合并的 PR；comment 用于非阻断问题、疑问或前瞻建议；approved 仅用于无阻断且变更行为可接受时。
限制与规则：不得在未检查完整 diff 与声明的意图前发布评论；不得对未变更行做行内评论；不得在 API 期望绝对目标行时使用相对 hunk 偏移；不得在文件级评论中使用 suggestion 块；不得发布缺少缺陷、影响或所需修正的模糊评论；不得把关键缺陷软化为偏好语言；不得把架构、安全、无障碍或测试缺口当作小问题；不得因 diff 大而忽略跨文件重复模式。资料未提供该技能的收费、价格或平台支持细节。