用途：该技能用于 AI 编程助手在收到代码审查反馈、准备落实建议之前的行为规范，强调技术评估而非情绪化回应。核心原则是：先验证再实现，先提问再假设，技术正确性优先于社交舒适。
主要能力与流程：收到反馈后按“阅读完整反馈—用自己的话复述需求或提问—对照代码库实际情况验证—评估是否适合当前代码库—给出技术性确认或有理有据的反驳—逐条实现并逐条测试”的顺序处理。禁止表演式回应，如“你完全正确”“好观点”“感谢指出”等，改为复述技术需求、提出澄清问题、以技术理由反驳，或直接动手修改。
处理模糊反馈：若任一条目不清楚，应停止实现，先就模糊项请求澄清，因为条目之间可能相关，部分理解会导致错误实现。
来源区分：来自人类搭档的反馈视为可信，理解后实现，但范围不清仍需提问；来自外部审查者的反馈需先检查是否技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、审查者是否了解完整上下文。若建议有误，以技术理由反驳；若无法验证，应说明限制并询问方向；若与人类搭档既有决策冲突，先与搭档讨论。
YAGNI 检查：当审查者建议“正规实现”某功能时，先在代码库中搜索实际调用；若无人使用，可建议移除；若确有使用，再正规实现。
实现顺序：先澄清所有不清楚项，再按阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序处理，逐条测试并确认无回归。
何时反驳：建议破坏现有功能、审查者缺乏上下文、违反 YAGNI、对当前技术栈不正确、存在遗留或兼容性原因、与搭档架构决策冲突时。反驳应使用技术推理、具体问题、可运行的测试或代码，架构性问题应让搭档参与。
确认正确反馈：直接说明修复内容与位置，或直接改代码，不表达任何感谢。若反驳有误，应事实性承认并继续，不写长道歉或过度解释。
GitHub 线程回复：回复内联审查评论时，应使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies 在评论线程内回复，而非作为顶层 PR 评论。
限制：资料未提供安装命令、收费、平台支持范围或具体版本要求，暂未提供。