处理 GitHub 评论

问题在哪

PR 评审和 issue 讨论往往散落在多条线程里：有人指出边界条件，有人要求改命名，还有「这里再测一下」的跟进。若只靠人工翻 GitHub 网页，很容易漏掉某条未回复的评论，或在没读清上下文时就改错文件。

本技能面向已用 gh 做日常协作的工程师，把「看评论 → 定方案 → 改代码 → 关线程」收成可重复的执行顺序，而不是零散提醒。

技能如何工作

核心依赖 GitHub CLI（gh） 拉取当前分支关联 PR 的评论（或配合你已有的列评论脚本）。典型流程分四步：

1. 检查评论：获取当前分支对应 PR 上的评审与讨论。
2. 分类与规划：列出评论与线程，为每条拟定修复思路；评论量大时，技能会先等你确认要处理哪些，避免盲目改一大片。
3. 应用修复：按选定评论改代码，并围绕评论附近的实现阅读上下文。
4. 回复与收尾：改完后把对应线程标记为已解决。

前置上只需保证 gh 已认证（例如 gh auth login / gh auth status）。

适用边界与注意点

• 适合 PR 评审评论、issue 反馈 这类需要「逐条对照代码」的场景；不替代你自己的代码审查标准或 CI 策略。
• 常见坑：未读评论上下文就改代码；会话开始前未检查 gh 登录状态。
• 若评论指向架构或产品决策而非具体 diff，仍需要你拍板后再动代码。