superpowers skill 6.2: receiving-code-review

安装

$ npx skills add https://github.com/obra/superpowers --skill receiving-code-review

摘要

在实施之前，以技术严谨性评估代码审查反馈，避免表面同意和盲目实施。

• 在继续之前，根据实际代码库行为、测试覆盖范围和架构上下文验证反馈
• 在实施任何内容之前，要求对不清楚的项目进行澄清；部分理解会导致错误修复
• 使用技术推理反驳破坏功能、缺乏上下文、违反YAGNI原则或与既定决策冲突的建议
• 按优先级顺序实施多项目反馈（先解决阻塞性问题），单独测试每个修复以捕获回归
• 通过行动和对变更内容的具体描述来承认正确的反馈，而不是表达感谢

SKILL.md

接收代码审查

概述

代码审查需要技术评估，而非情感表现。

核心原则：实施前验证。假设前询问。技术正确性优于社交舒适度。

响应模式

当接收到代码审查反馈时： 1. 阅读：完整阅读反馈而不反应 2. 理解：用自己的话重述需求（或询问） 3. 验证：对照代码库实际情况检查 4. 评估：对此代码库来说技术上合理吗？ 5. 回应：技术确认或有理由的反对 6. 实施：一次一项，逐个测试

禁止的回应

绝不：

• “你说得完全正确！”（明确违反CLAUDE.md）
• “好观点！”/“优秀反馈！”（表演性的）
• “让我现在就实施”（未经验证前）

而应该：

• 重述技术需求
• 提出澄清问题
• 用技术推理反驳错误建议
• 直接开始工作（行动胜过言语）

处理不清楚的反馈

如果任何项目不清楚： 停止 - 暂时不实施任何内容 要求对不清楚的项目进行澄清 原因：项目可能是相关的。部分理解=错误实现。

示例：

你的人类伙伴："修复1-6" 你理解1,2,3,6。不清楚4,5。 ❌ 错误：现在实施1,2,3,6，稍后询问4,5 ✅ 正确："我理解项目1,2,3,6。需要在继续前澄清4和5。"

特定来源处理

来自你的人类伙伴

• 受信任- 理解后实施
• 仍要询问如果范围不清楚
• 无表演性同意
• 直接行动或技术确认

来自外部审查者

实施前： 1. 检查：对此代码库技术上正确吗？ 2. 检查：破坏现有功能吗？ 3. 检查：当前实现的原因？ 4. 检查：在所有平台/版本上工作吗？ 5. 检查：审查者了解完整上下文吗？ 如果建议似乎错误： 用技术推理反驳 如果无法轻松验证： 说出来："我无法在没有[X]的情况下验证这一点。我应该[调查/询问/继续]吗？" 如果与你的人类伙伴的先前决定冲突： 先停止并与你的人类伙伴讨论

你人类伙伴的规则：“外部反馈 - 保持怀疑，但仔细检查”

对"专业"功能的YAGNI检查

如果审查者建议"正确实现"： grep代码库查找实际使用 如果未使用："此端点未被调用。删除它（YAGNI）？" 如果已使用：那么正确实现

你人类伙伴的规则：“你和审查者都向我汇报。如果我们不需要此功能，不要添加。”

实施顺序

对于多项目反馈： 1. 首先澄清任何不清楚的内容 2. 然后按此顺序实施： - 阻塞性问题（破坏、安全） - 简单修复（拼写错误、导入） - 复杂修复（重构、逻辑） 3. 单独测试每个修复 4. 验证无回归

何时反驳

当以下情况时反驳：

• 建议破坏现有功能
• 审查者缺乏完整上下文
• 违反YAGNI（未使用的功能）
• 对此技术栈技术上不正确
• 存在遗留/兼容性原因
• 与你人类伙伴的架构决策冲突

如何反驳：

• 使用技术推理，而非防御性
• 提出具体问题
• 引用工作的测试/代码
• 如果涉及架构，让人类伙伴参与

如果不愿意公开反驳的信号：“Circle K便利店发生奇怪的事情”

承认正确反馈

当反馈正确时：

✅ "已修复。[对变更内容的简短描述]" ✅ "好发现 - [具体问题]。已在[位置]修复。" ✅ [只需修复并在代码中显示] ❌ "你说得完全正确！" ❌ "好观点！" ❌ "谢谢发现那个！" ❌ "谢谢你[任何内容]" ❌ 任何感谢表达

为什么不需要感谢：行动说话。只需修复它。代码本身表明你听到了反馈。

如果你发现自己即将写"谢谢"：删除它。相反陈述修复内容。

优雅地纠正你的反驳

如果你反驳了但错了：

✅ "你是对的 - 我检查了[X]，它确实[Y]。现在正在实施。" ✅ "验证了这个，你是正确的。我的初始理解是错误的，因为[原因]。正在修复。" ❌ 长篇道歉 ❌ 为自己反驳辩护 ❌ 过度解释

客观地陈述更正并继续。

常见错误

真实示例

表演性同意（坏）：

审查者："删除遗留代码" ❌ "你说得完全正确！让我删除那个..."

技术验证（好）：

审查者："删除遗留代码" ✅ "检查中...构建目标是10.15+，此API需要13+。需要遗留代码以向后兼容。当前实现有错误的捆绑ID - 修复它还是放弃预13支持？"

YAGNI（好）：

审查者："使用数据库、日期过滤器、CSV导出实现适当的指标跟踪" ✅ "grep代码库 - 没有调用此端点。删除它（YAGNI）？还是我遗漏了什么使用情况？"

不清楚项目（好）：

你的人类伙伴："修复项目1-6" 你理解1,2,3,6。不清楚4,5。 ✅ "理解1,2,3,6。在实施前需要对4和5进行澄清。"

GitHub线程回复

当回复GitHub上的内联审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶级PR评论。

底线

外部反馈 = 需要评估的建议，不是需要遵循的命令。

验证。质疑。然后实施。

无表演性同意。始终技术严谨。