用途
该技能专注于代码审查反馈的接收与处理，帮助开发者在实施审查建议前进行技术评估，避免盲目服从或表演式回应。核心原则是：先验证再实现，先询问再假设，技术正确性优先于社交舒适。
主要能力
- 定义标准响应模式：阅读完整反馈而不反应、用自己的话复述需求（或询问）、对照代码库现实验证、评估是否适用于当前代码库、给出技术性确认或有理由的反驳、逐项实现并逐个测试。
- 明确禁止的回应：如“你完全正确！”、“好观点！”、“感谢指出！”等表演式或致谢表达，以及未经验证就说“我现在就实现”。
- 处理不清晰反馈：若任何一项不清楚，停止实施，先要求澄清，因为条目可能相互关联，部分理解会导致错误实现。
- 区分来源处理：来自人类伙伴的反馈可信，理解后实施，但范围不清仍需询问；来自外部审查者的反馈需先检查技术正确性、是否破坏现有功能、当前实现原因、平台/版本兼容性、审查者是否了解完整上下文。
- YAGNI检查：当审查者建议“正确实现”某功能时，先在代码库中搜索实际使用情况；若未使用则建议移除，若使用则再正确实现。
- 实施顺序：先澄清所有不清晰项，然后按阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序逐项实施，每个修复单独测试，验证无回归。
- 推送回退原则：当建议破坏现有功能、审查者缺乏完整上下文、违反YAGNI、技术栈上不正确、存在遗留/兼容性原因、或与人类伙伴的架构决策冲突时，应使用技术推理而非防御性态度进行反驳。
- 正确确认反馈：反馈正确时，用“已修复。［简要描述变更］”或“好发现——［具体问题］。已在［位置］修复。”等表述，或直接修复并在代码中展示，避免任何致谢表达。
- 优雅纠正自己的反驳：若反驳后发现自己错了，用事实性陈述如“你是对的——我检查了［X］，它确实［Y］。现在实施。”，避免长道歉或过度解释。
- 常见错误对照表：列出表演式赞同、盲目实施、批量未测试、假设审查者正确、回避反驳、部分实现、无法验证仍继续等错误及修复方式。
- GitHub线程回复：回复GitHub内联审查评论时，应在评论线程中回复（使用
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非作为顶层PR评论。
使用方式
当收到代码审查反馈时，按响应模式逐步处理。若反馈不清晰，先停止并询问。对外部审查者建议，先验证再实施。若反馈正确，直接修复并简要说明。若需反驳，使用技术推理。实施时逐项进行并测试。
适用场景
适用于代码审查反馈接收阶段，尤其是反馈不清晰或技术上可疑时；也适用于处理来自人类伙伴或外部审查者的建议、需要决定是否采纳或反驳、以及需要避免表演式回应和盲目实施的开发场景。
限制
资料未提供该技能的具体安装方式、平台支持、收费模式或与其他工具的集成细节。该技能为行为指导型技能，不包含自动化代码修改功能。