用途：当 AI 编程代理收到代码审查反馈时，本技能规定在实施建议前先做技术验证，避免盲目照做或表演式认同。核心原则是“先验证再实施，先提问再假设，技术正确性优先于社交舒适度”。
回应流程：完整读完反馈不急于反应；用自己的话复述需求或提问；对照代码库实际情况核验；评估该建议对当前代码库是否技术可行；做出技术确认或有理有据的反驳；最后逐项实施并逐项测试。
禁止的回应：禁止“你说得完全对！”这类表演式认同、赞美式反馈，以及在验证前就说“我马上实现”。替代做法是复述技术需求、提出澄清问题、用技术理由反驳，或直接动手修改。
不清晰反馈的处理：任一条目不清楚就停止，不要先实现其余部分，先请求澄清；因为条目之间可能相互关联，理解不完整会导致错误实现。
按来源区分：来自人类搭档的反馈可信，理解后即可实施，但范围不清仍要提问；来自外部审查者的反馈需先核查是否对当前代码库技术正确、是否破坏现有功能、现有实现的原因、是否兼容所有平台版本、审查者是否了解完整上下文。无法验证时如实说明并询问是否调查、转问或继续；若与人类搭档既有决策冲突，先停下来与人类搭档讨论。
YAGNI 检查：当审查者建议“规范地实现”某功能时，先在代码库中搜索其实际调用情况；未被调用则建议移除，确实被使用再规范实现。
实施顺序：先澄清所有不清楚项；再按阻塞性问题（故障、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）依次实施，逐项测试并确认无回归。
应有的反驳场景：建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI、对当前技术栈不正确、存在遗留或兼容性原因、与人类搭档的架构决策冲突。反驳时用技术理由而非防御姿态，引用可运行的测试或代码，架构层面问题引入人类搭档。
正确反馈的回应：直接说明修复内容与位置，或直接改好并展示代码；不要道谢、不要“好眼力”等表达，避免任何感谢语句。若自己的反驳有误，用事实陈述纠正并继续，不写长篇道歉或过度解释。
GitHub 线程回复：回复内联审查评论时应在评论线程内回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非作为 PR 顶层评论。
限制：本技能面向代码审查接受环节的工作方式，不包含安装命令、收费或平台信息，相关资料暂未提供。