Gh Address Comments

GitHub PR 评审意见处理

用户要处理一个 PR 上的 requested changes 时使用本技能。关键判断：扁平的评论列表不等于评审线程状态——只要任务依赖"这条线程解决了没有""这条意见挂在哪个文件哪一行"，就必须走 GraphQL 读取。

用之前先确认 CLI 认证：gh auth status；失败就请用户 gh auth login。

流程

1. 确定 PR

   • 用户给了仓库 + PR 号或 URL，直接用。
   • 说的是当前分支的 PR，就用本地 git 上下文加 gh pr view --json number,url 解析。

2. 读取带线程状态的评审上下文

   • 需要 PR 元信息、patch 上下文：gh pr view / gh pr diff。
   • 需要未解决线程、行内位置、解决状态：运行本技能目录下的 scripts/fetch_comments.py。它取回 reviewThreads、isResolved、isOutdated 以及文件与行锚点——这些是扁平评论接口给不了的。
   • 只有做顶层评论的轻量摘要时，才用扁平评论读取。

3. 归类可行动的线程

   • 按文件或行为域分组。
   • 把需要改动的意见，与纯信息、赞同、已解决、重复的意见分开。

4. 动手前确认范围

   • 编号列出可行动的线程，每条一句话说明要改什么。
   • 用户没说全改，就问他要处理哪几条。
   • 用户说"全改"，理解为所有未解决且可行动的线程，其中含糊的单独点出来。

5. 在本地实施选定的修改

   • 每处代码改动都能追溯回它对应的线程或意见簇。
   • 意见要的是解释而不是代码，就起草回复，不要硬改代码。

6. 总结

   • 列出处理了哪些线程、有意留着哪些、以及支撑改动的测试或检查。

写操作安全

• 用户没有明确要求，就不要在 GitHub 上回复、解决线程或提交 review。
• 评审意见互相冲突、或者照做会造成行为回退时，先把取舍摆出来再动手。
• 意见含糊就问清楚，或起草一个待确认的回复，不要猜。
• 不要把扁平评论当成评审线程状态的完整表示。
• 中途遇到认证或限流问题，请用户重新认证后重试。

兜底

如果实在解析不出 PR，明确告诉用户卡在哪一环：仓库权限范围不足、缺少 PR 上下文、还是 CLI 认证问题；然后要缺失的仓库/PR 标识，或让用户重新登录。