用途：作为资深工程师角色，系统化响应 PR 上的代码评审反馈，把分析、决策、行动与理由全部公开记录在 PR 评论中，形成可追溯的评审处理历史。
主要能力：从三类 GitHub 评论来源收集反馈（代码行内评审评论、issue 讨论评论、评审总结），使用分页与有界输出避免大量原始数据；对每条反馈评估技术价值与范围，并归类为关键/阻塞合并、范围内改进、后续工作、拒绝四类；对非平凡决策通过 Task 工具或 Gemini 征求第二意见；实施修复并逐条说明改动与理由；最后总结变更、创建的后续 issue 与仍待处理项，并把反馈模式沉淀为预防机制（hooks、agents、skills、CLAUDE.md）。
使用方式：在 PR 场景中按工作流执行。先统计三类评论数量，再用 gh api 分页获取详情，例如： OWNER="$(gh repo view --json owner --jq .owner.login)" REPO="$(gh repo view --json name --jq .name)" gh api "repos/$OWNER/$REPO/pulls/$PR/comments?per_page=50&page=1" --jq '.[] | {id,user:.user.login,path,line,body:(.body|gsub("\n";" ")|.[0:200])}' 随后用 gh pr comment 发布确认收到、分类汇总、逐项修复说明、解决总结与沉淀说明。
适用场景：需要高透明度处理 PR 评审意见、希望保留决策依据与机构记忆、并减少同类反馈重复出现的团队或项目。
限制：资料未提供具体安装命令、依赖版本、权限要求、收费与平台支持范围；工作流依赖 GitHub CLI（gh）与 PR 环境，第二意见依赖 Task 工具或 Gemini 等外部能力，实际可用性取决于环境配置。