用途：在 GitHub 拉取请求上发布评审评论时加载本技能，规范评审流程与评论输出。
主要能力与要求：
- 行号记录：分析 PR diff 时须随时记录每个发现的精确文件路径与行号。每个发现须包含新文件（diff 右侧）中的 path、line（多行时为结束行）、可选的 start_line（多行起始行）及 body（可直接发布的评论正文）。若由子代理执行评审，返回结果也须包含这些字段。
- 发布评论：可借助 GitHub CLI 针对每处问题发布行内评论，评论中应引用具体代码行，聚焦可操作的改进建议，清晰简洁，避免空泛表述，且评论须落到具体代码行，不得合并为一条整体评论。
- 建议编辑：当修复方案明确且局部（如拼写错误、缺失标注、类型错误、简单重命名）时，可在评论中附 GitHub 建议编辑块，格式为 ```suggestion 后接修正后的代码行。适用于拼写、override/[[nodiscard]]/constexpr 缺失、类型错误、简单重命名、明确的小 bug 修复；不适用于大重构、设计变更、存在多种有效方案或需作者决策的情况。建议应最小化，只改需要修复的行，不重排周边代码；多行建议须包含全部受影响行。
- 未解决评论复查：须检查此前被标记为已解决的评审评论，若当前代码仍存在该问题，按指定格式标记为发现：以 [HIGH] 开头，注明位置、问题、证据与建议，指出该评论被标为已解决但问题仍存；若问题已被合理解决（即使方式不同）则不应标记。
- 语气：不做评论性发挥，无赞美与填充语，正文仅为发现的简要汇总（可用项目符号列表）加 AI 生成免责声明。
- 礼仪：不过度刷评论，优先架构、性能、安全与正确性问题；不修改他人已有评论，问题解决后可新增评论确认；保持尊重与建设性，并说明评论由 AI 助手撰写、可能不完善。
- CI 状态：internal-build 需要 Cloudflare 内部访问权限，外部贡献者必然失败，不应将其视为代码问题；归因 CI 失败前先判断作者是否为外部贡献者及失败任务是否受访问限制。
工具：与 GitHub 交互时使用 GitHub CLI（gh）或 git。