PR 里同时出现行内评论、一般讨论和多轮回复时，容易漏掉需要修改的地方。gh-address-comments 先汇总当前分支关联 PR 的反馈，给每项编号并说明需要做什么，再按你选择的范围修改代码。它适合接手评审回合，而不是代替你判断所有建议都应该接受。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer gh-address-comments
- 已检出目标 PR 分支的本地 Git 仓库
- GitHub CLI gh 已安装并能访问仓库
- 有权读取 PR；修改应在你的工作副本中完成
在终端用 gh auth status 检查登录；未登录时运行 gh auth login 完成浏览器授权。GitHub CLI 的权限与当前账号决定哪些私有 PR 可读。 [4]
第一次怎么用
在目标 PR 分支里，可以先请求一份评审清单：
$gh-address-comments
检查当前分支 PR 的评审意见。先按编号列出每条意见、所在文件、讨论结论和建议改动，标出已过时或可能重复的意见；等我选定编号后再修改。保留现有未提交改动，不自动回复评论或合并 PR。
接下来怎样推进
-
确认 PR 身份。 检查当前仓库和分支，核对 PR 链接，避免把另一个工作树的反馈带进来。
-
选择需要解决的意见。 阅读编号清单，告诉 Codex 要处理哪些；对相互矛盾的建议先明确取舍。
-
检查每条修改。 让它把选中的意见对应到 diff 和相关验证，并报告尚未处理的编号。回复评审和发布修改可以另行安排。
一次评审怎么处理才不会漏项
在目标 PR 的分支上开始，先用 gh auth status 确认账号，再把 PR 链接交给 Codex。要求它按线程列出编号、评论人、受影响的文件、要解决的问题和当前状态。评审里常有已经过时的意见、单纯提问或互相冲突的建议；先选出真正需要修改的编号，再开始编辑。你可以说：“先只处理第 2 和第 4 条；第 3 条先解释为什么与现有接口约定冲突。”
处理一条评论时，先读它针对的 diff 和当前代码，避免修复旧行号却破坏新实现。修改后按问题选择最相关的测试、类型检查或手工复现。让 Codex 返回“编号 → 改动位置 → 验证结果”的简短对应表，这样复审时能知道哪些意见已解决、哪些需要继续讨论。
另一个场景：两条评审意见互相牵连
例如一位评审要求“删去重复的数据读取”，另一位要求“每次保存后都刷新列表”。可以输入：“先列出这两条评论各自针对的代码和预期，不改动；解释是否真的冲突，以及可以同时满足的最小方案。” 先读完整线程和当前 diff，再决定是修改实现、补测试，还是在评审中澄清误解。完成后检查刷新时机、请求数量和错误状态，尤其不要为减少一次请求而让保存后的列表显示旧数据。若某条已被后来提交解决，也应在编号清单中标为已处理，而不是重复修改。
完成标志与边界
完成本地改动并不等于已经在 GitHub 回复评审、推送分支或解决线程。交付时确认当前工作区的 diff、失败的验证以及尚未处理的评论；是否发评论或推送应单独明确。若脚本拿不到评论，先核对当前分支是否真有打开的 PR、账号是否有读取权限，不要凭浏览器通知里的片段猜测线程内容。
交付后先检查什么
你应拿到“意见编号 → 改动文件 → 验证结果”的对应关系。先对照原评论确认问题得到解决，再检查是否引入了意见之外的大幅重构；意见被整理或代码被改动，都不自动代表评审线程已经关闭。
脚本找不到时先检查安装目录
如果提示 fetch_comments.py 不存在，先区分“目标仓库里没有”和“安装的 Skill 里没有”。该脚本应从 Skill 自身的 scripts/ 目录定位；有用户报告 Agent 误在业务仓库查找，连续多次走了 GraphQL 兜底。即使成功拉到评论，也应回到原 PR 核对线程位置和是否仍未解决，避免根据过期评论改错文件。
常见卡点
找不到当前 PR。 检查当前分支是否确实有已打开的 PR，必要时直接提供准确链接并检出对应分支。
评论读不全或认证失败。 重新检查 gh 账号、仓库访问权限和限流情况，不靠猜测补全线程。
意见已经过时。 要求对照当前代码判断它是否仍成立，再决定修改或解释原因。