用途：该技能面向“收到代码评审反馈”这一场景，强调技术评估而非情绪表演。核心原则是：先验证再实现，先询问再假设，技术正确性优先于社交舒适。
主要能力与响应流程：收到反馈时按 READ、UNDERSTAND、VERIFY、EVALUATE、RESPOND、IMPLEMENT 六步处理——完整读完反馈、用自己的话复述需求、对照代码库实际情况验证、评估是否适用于当前代码库、给出技术性确认或有理由的推回、逐项实现并逐项测试。
禁止的回应：不得使用“You're absolutely right!”“Great point!”“Excellent feedback!”等表演式附和，也不得在验证前就说“Let me implement that now”。应改为复述技术要求、提出澄清问题、用技术理由推回，或直接开始工作。
处理不清楚的反馈：若任何一项不清楚，应停止实现并先请求澄清，因为各项之间可能相关，部分理解会导致错误实现。例如对方说“Fix 1-6”，你只理解 1、2、3、6，正确做法是说明理解范围并请求澄清 4 和 5，而不是先做已理解的部分。
来源区分：来自人类搭档的反馈可信，理解后实现，但范围不清仍需询问，且不做表演式同意；来自外部评审者的反馈，实现前需检查是否对当前代码库技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、评审者是否了解完整上下文。若建议看似错误，用技术理由推回；若难以验证，说明“没有 X 我无法验证，应调查/询问/继续？”；若与人类搭档此前的决定冲突，先停下与搭档讨论。
YAGNI 检查：当评审者建议“properly implement”某功能时，先在代码库中 grep 实际使用情况；若未被使用，可提出按 YAGNI 移除；若确有使用，再正式实现。
实现顺序：多项反馈先澄清所有不清楚项，再按阻塞问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序实现，每项单独测试并确认无回归。
何时推回：建议破坏现有功能、评审者缺乏完整上下文、违反 YAGNI、对当前技术栈不正确、存在遗留或兼容性原因、与人类搭档的架构决定冲突时。推回应使用技术理由而非防御姿态，提出具体问题，引用可运行的测试或代码，涉及架构时让搭档参与。
确认正确反馈：用“Fixed. [简述改动]”“Good catch - [具体问题]. Fixed in [位置]”或直接修复并在代码中体现；避免任何感谢表达。若推回后被证明有误，应事实性说明“You were right - I checked [X] and it does [Y]. Implementing now.”，不做冗长道歉或过度解释。
GitHub 线程回复：回复内联评审评论时，应回复在评论线程中（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶层 PR 评论。
限制：资料未提供该技能的安装方式、依赖、平台支持或收费信息。