用途：指导 AI 编程代理在收到代码审查反馈后、实施建议前，如何做技术评估而非情绪表演。核心原则是：先验证再实现，先询问再假设，技术正确性高于社交舒适。
主要能力：给出固定的响应流程——完整读完反馈、用自己的话复述需求、对照代码库实际情况核验、评估是否适用于本代码库、给出技术性确认或有理有据的反驳、最后逐条实现并逐条测试。明确列出禁止的回应方式，如“你说得完全对”“好点子”这类表演式附和，以及未验证就说“我马上实现”。对不清楚的反馈，要求先停下、不实现任何内容，先就不清楚的项目请求澄清，理由是条目之间可能相关，理解不全会导致错误实现。
区分来源：来自人类伙伴的反馈可信，理解后即可实现，但范围不清仍要问；来自外部审查者的反馈要先检查是否符合本代码库、是否破坏现有功能、当前实现原因、跨平台/版本兼容性、审查者是否了解完整上下文，若无法轻易验证则如实说明并询问是调查、提问还是继续。对“正规实现”类建议会先 grep 代码库确认实际使用情况，未使用则按 YAGNI 提议移除。
实施方式：先澄清所有不清楚项，再按阻塞问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序实施，逐项测试并确认无回归。实施后逐条在对应评论线程回复一句话总结与提交引用，使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies，而非顶层 PR 评论；不要自行解决评论线程，那是人类开发者的工作。默认每条审查评论一个提交，仅在逻辑不可分割或改动同一代码行时才合并，合并时在提交信息中列出所有已处理评论并在每条回复中引用该提交。
适用场景：AI 编程代理在 PR 审查、结对编程或外部审查者反馈环节中处理 code review 意见。
限制：该技能为行为规范类指南，具体适用的模型、平台、安装方式与收费信息暂未提供；其中的人类协作规则与 gh 命令依赖 GitHub 工作流环境。