receiving-code-review
在收到代码审查反馈后、实施建议前使用,尤其当反馈看起来不清晰或技术上存疑时——需要技术严谨与验证,而非敷衍同意或盲目实施。
技能说明obra/superpowers
在收到代码审查反馈后、实施建议前使用,尤其当反馈看起来不清晰或技术上存疑时——需要技术严谨与验证,而非敷衍同意或盲目实施。
技能简介
本技能用于在收到代码审查(Code Review)反馈时、实施建议之前。它帮助 Agent 以技术严谨的态度处理反馈——先验证再实施,先询问再假设,而不是敷衍同意或盲目照做。
使用场景
- 审查反馈表述不清晰或存在歧义时
- 外部审查者提出的建议与当前代码库实际情况不符时
- 反馈建议与用户(或合作伙伴)之前的技术决策冲突时
- 审查者建议添加“专业性”功能,但不确定是否真的被使用时
- 收到多项反馈,需要判断优先实施顺序时
使用方法
- 将本 SKILL.md 放置到 Agent 的 skills 目录下(或通过
skills add导入),使 Agent 在收到代码审查反馈时自动加载该技能。 - 收到反馈后,按以下流程处理:
1. 完整阅读反馈,不做即时反应
2. 用自己的话复述需求(或提问澄清)
3. 对照代码库实际情况验证
4. 判断该建议对当前代码库是否技术可行
5. 给出技术性确认或有理由的异议
6. 逐项实施,每项单独测试
- 若反馈内容不明确,先停下来,向对方确认,不要实施任何部分项。
- 对于外部审查者的建议,先核实技术正确性、是否破坏现有功能、是否与先前架构决策冲突;如认为不对,用技术理由提出异议。
注意事项
- 禁止使用“你说得对”“好点子”等敷衍性附和用语;正确做法是复述技术要求,或直接动手改。
- 如果反馈正确,直接修复并在代码中体现即可,无需表达感谢。
- 如果自己此前提出了异议但被证实是错误的,简洁承认事实并继续实施,不要过度道歉或辩解。
- 若审查者建议“实现得正规一点”,先用
grep检查代码库中是否有实际调用——如果没人用,按 YAGNI 原则建议删除而不是实现。 - 多项目反馈的顺序:先澄清不明确项,再处理阻塞性问题(崩溃、安全),然后是简单修复(拼写、导入),最后是复杂重构,每一项改动后立即测试,确保无回归。