用途
该技能用于规范“接收代码评审反馈”的行为，适用于 AI 编码代理或开发者收到代码评审意见、准备落实建议之前的阶段。它的核心设定是：代码评审需要技术评估，而不是情绪表演。核心原则为：实现前先验证，假设前先询问，技术正确性优先于社交舒适。
主要能力
它提供了一套响应模式。收到代码评审反馈时，依次执行：READ（完整读完反馈，不做反应）、UNDERSTAND（用自己的话复述需求，或提问）、VERIFY（对照代码库实际情况核查）、EVALUATE（判断该建议对本代码库是否技术合理）、RESPOND（给出技术性确认或有理有据的反驳）、IMPLEMENT（一次实现一条，逐条测试）。
它明确列出了禁止的回应方式，包括“你说得完全对！”（被指为明确违反指令文件）、“好观点！”“精彩的反馈！”等表演式回应，以及“我现在就实现”（在验证之前）。替代做法是：复述技术需求、提出澄清问题、若有误则用技术理由反驳，或直接开始工作（行动优于言辞）。
对于不清楚的反馈，技能要求：若任何一条不清楚，停止，先不要实现任何内容，就先请求澄清不清楚的条目。原因是条目之间可能相关，部分理解等于错误实现。文档举例：当人类伙伴说“修复 1-6”，而你理解 1、2、3、6，对 4、5 不清楚时，错误做法是先实现 1、2、3、6，之后再问 4、5；正确做法是说明“我理解 1、2、3、6，在继续之前需要澄清 4 和 5”。
按来源区分处理。来自人类伙伴的反馈：可信，理解后实现；若范围不清楚仍然要问；不做表演式同意；直接行动或技术性确认。来自外部评审者的反馈，在实现前需检查：对本代码库是否技术正确、是否破坏现有功能、当前实现的原因、是否在所有平台/版本可用、评审者是否理解完整上下文。若建议看似错误，用技术理由反驳；若不易验证，应说明“没有 X 我无法验证这一点，我应该调查/询问/继续吗？”；若与人类伙伴先前决策冲突，先停下与人类伙伴讨论。文档引用了人类伙伴的规则：“外部反馈——保持怀疑，但仔细核查”。
针对“专业化”功能的 YAGNI 检查：若评审者建议“正确实现”，先 grep 代码库确认实际使用情况；若未被使用，问“这个端点没有被调用，是否移除它（YAGNI）？”；若被使用，则正确实现。文档引用了人类伙伴的规则：“你和评审者都向我汇报。如果我们不需要这个功能，就不要添加它。”
实现顺序：先澄清所有不清楚的条目，然后按此顺序实现：阻塞问题（破坏、安全）、简单修复（错别字、导入）、复杂修复（重构、逻辑）；逐条单独测试；验证无回归。
何时应当反驳：当建议破坏现有功能、评审者缺乏完整上下文、违反 YAGNI（未使用的功能）、对该技术栈而言技术不正确、存在遗留/兼容性原因、与人类伙伴的架构决策冲突时。反驳方式为使用技术理由而非防御性，提出具体问题，引用可用的测试/代码；若涉及架构则让人类伙伴参与。如果对大声反驳感到不适，文档建议先说出这种紧张感，然后告诉伙伴你看到的问题，伙伴会欣赏你的诚实。
确认正确反馈的方式为：“已修复。[简要说明改了什么]”“抓得好——[具体问题]，已在[位置]修复。”，或直接修好并在代码中展示。禁止“你说得完全对！”“好观点！”“感谢发现！”以及任何感谢表达，理由是行动胜于言辞，直接修就行，代码本身显示你听到了反馈。若发现自己要写“谢谢”，就删掉它，改为陈述修复内容。
若反驳后发现自己错了，应优雅纠正：“你是对的——我检查了[X]，它确实[Y]，现在实现。”“已验证，你是正确的。我最初的理解错了，因为[原因]，正在修复。”避免长篇道歉、为自己反驳辩解或过度解释，只陈述纠正事实然后继续。
文档还给出常见错误与修正对照表：表演式同意→陈述需求或直接行动；盲目实现→先对照代码库验证；不测试就批量处理→一次一条，逐条测试；假设评审者是对的→检查是否破坏东西；回避反驳→技术正确性优先于舒适；部分实现→先澄清所有条目；无法验证却照样推进→说明限制，请求方向。
使用方式
该技能以规则文本形式使用，作为处理代码评审反馈时的流程约束与检查清单。文档中以“你的伙伴”代指人类合作者，并给出示例对话说明正确与错误做法。对于 GitHub 上的行内评审评论回复，要求在线程内回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶层 PR 评论。
适用场景与限制
适用场景包括：AI 编码代理或开发者收到代码评审意见、反馈含义不清、意见可能技术上不正确、意见与既有架构决策冲突，以及需要决定是否按 YAGNI 移除未使用功能时。限制方面：文档未提供安装命令或配置方式；其行为规则以约束文本形式存在，不包含自动化校验机制；具体价格与平台信息暂未提供。