receiving-code-review

receiving-code-review skill 概览

receiving-code-review skill 的用途

receiving-code-review skill 的作用，是让 AI 在面对代码审查反馈时，按技术判断来回应，而不是条件反射式地先同意再说。它的职责很直接，但非常有价值：当 reviewer 提出修改建议时，agent 应该先理解对方到底在要求什么，再到真实代码库里核对，确认成立后才实施，或者在必要时明确提出异议。

它尤其适合处理这类情况：review 评论本身有歧义、只说对了一部分、彼此冲突，或者如果照单全收会带来风险。receiving-code-review skill 关注的不是在 PR 讨论里“显得礼貌”。它真正要避免的是另一类更常见的问题：AI 因为社交式反应，先说一句“你说得对，我来改”，结果在问题还没验证之前就引入了错误修改。

最适合哪些用户

这个 skill 很适合以下人群：

• 用 AI 协助处理 PR 评论的开发者
• 希望减少“表演式认同”、提升技术准确性的团队
• 在成熟代码库中工作的 agent，因为 reviewer 的建议未必符合本地约束
• 想要一套可重复执行的 review 回复流程，而不只是一个更好提示词的用户

如果你的核心问题是“模型太快执行 reviewer 反馈，结果把东西改坏了”，那这个 skill 正是针对这种失败模式设计的。

真正需要解决的任务

大多数用户其实并不缺“看懂评论”的能力。他们真正需要帮助的是判断：

• reviewer 实际上想表达什么
• 这条建议放到当前仓库里到底对不对
• 在动手改之前，是否必须先澄清
• 如果 reviewer 说错了或说得不完整，该怎么回应
• 如果反馈成立，怎样以安全的方式实施

这就是 receiving-code-review skill 的实际价值：它把“接收 review 意见”变成一个“先验证、再行动”的工作流。

它和普通 review 提示词有什么不同

一般的提示词往往会把模型推向“配合执行”：先总结反馈、感谢 reviewer，然后立刻开始改代码。这个 skill 则强制采用另一套响应模式：

1. 先读完整条反馈
2. 用自己的话复述要求
3. 对照代码库现实进行核验
4. 评估技术上是否适配
5. 再决定是确认、提问，还是有理有据地反驳
6. 最后一次只处理一个问题

它还明确禁止一些常见但价值很低的回应方式，比如过度夸赞，或者在验证之前就立刻承诺“我会改”。

安装前需要知道什么

这是一个很轻量、用途也很聚焦的 skill。它不附带 helper scripts、参考资料，或者仓库专用规则。如果你想要的是容易接入、低成本采用的东西，这反而是优点；但也意味着，输出质量会非常依赖你提供的 review 评论内容，以及对应的代码上下文。

更适合把这个 skill 理解为 Code Review 工作流中的“行为护栏”，而不是一个完整的代码审查自动化框架。

如何使用 receiving-code-review skill

如何安装 receiving-code-review skill

从 obra/superpowers 仓库安装：

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

如果你的环境使用的是其他 skill loader，也可以从这里添加：

https://github.com/obra/superpowers/tree/main/skills/receiving-code-review

由于这个仓库针对该 skill 只暴露了 SKILL.md，所以无论安装还是检查内容都很直接。

安装前在仓库里先看什么

如果你正在做 receiving-code-review install 决策，建议先看：

• skills/receiving-code-review/SKILL.md

这个文件几乎涵盖了所有真正有用的行为定义：

• 核心原则
• 响应模式
• 禁止的回应方式
• 面对不清晰反馈时的处理规则

它没有额外的 rules/、resources/ 或辅助脚本需要先学习，所以理解成本和上手时间都很低。

实际工作中什么时候调用 receiving-code-review

最合适的调用时机，是反馈刚到、但代码还没开始改的时候，使用 receiving-code-review skill。

典型触发场景包括：

• “Please simplify this logic.”
• “This should use a transaction.”
• “Fix comments 1–6.”
• “Why not just cache this?”
• “Use pattern X instead.”

尤其在以下情况下更应该调用它：

• 评论是打包成批出现的
• 其中有些点并不清楚
• reviewer 可能不了解本地架构约束
• AI 已经有“马上开改”的冲动

这个 skill 需要什么输入

这个 skill 在你提供以下四类信息时效果最好：

1. review 的原始反馈
2. 受影响的文件路径或 diff
3. 代码库中的相关约束
4. 你希望下一步做什么

有帮助的输入包括：

• 原样复制的 PR 评论
• 当前实现代码
• 测试失败信息或性能约束
• 可能与建议冲突的架构规则
• 你是想要回复草稿、技术评估，还是实施帮助

如果没有代码库上下文，这个 skill 仍然可以帮你解释评论，但很难准确验证建议是否真的适配当前代码。

把模糊目标写成高质量提示词

弱提示词：

Handle this review feedback.

更强的提示词：

Use the receiving-code-review skill.

Review feedback:
"Please combine these queries and move validation into the controller."

Context:
- Files: app/services/order_sync.rb, app/controllers/orders_controller.rb
- Current pattern: validation is intentionally kept out of controllers
- This code handles retry behavior and partial failures
- I want to know whether the suggestion is correct for this codebase

Please:
1. Restate what the reviewer is asking
2. Identify any ambiguity
3. Verify the suggestion against the current design
4. Recommend whether to implement, ask a question, or push back
5. If valid, propose the smallest safe change

之所以更有效，是因为它给了 skill 完成关键步骤所需的材料：不是单纯复述评论，而是做真正的验证。

一套实用的 receiving-code-review 工作流

一个可靠的 receiving-code-review usage 流程通常是这样：

1. 粘贴完整的 review 线程或整批评论
2. 让 agent 先区分哪些明确、哪些不明确
3. 要求它逐条复述 reviewer 想改什么
4. 让它把每一项都对照代码库检查
5. 再要求给出建议：实施、先澄清，还是不同意
6. 只有到了这一步，才开始实际修改，而且一次只处理一个问题

这样可以避免一个很常见的错误：一边误解着剩余评论，一边已经先把其中一部分改了。

receiving-code-review 如何处理不清晰或打包评论

这个 skill 里最强的一条原则之一就是：只要有任何一项不清楚，就先不要开始实施。

这在真实 PR 里非常重要，因为评论之间经常是互相关联的。如果 reviewer 说“Fix points 1–6”，而其中第 4、5 点含义不清，那么你先改 1–3 和 6，很可能会把后续方向彻底锁死在错误路径上。

这里一个很好的提示词是：

Use receiving-code-review. Group this feedback into:
- clear and ready to verify
- unclear and needs clarification
Do not recommend implementation until all linked items are understood.

这个 skill 的优质输出应该长什么样

好的结果绝不是一句“Thanks, great catch.”。更理想的输出应该包含：

• 对 reviewer 技术诉求的清晰复述
• 明确指出任何假设或歧义
• 对照真实代码做出的验证
• 带理由的结论
• 最终给出澄清问题、尊重但明确的反驳，或安全的实施方案

如果输出是从评论直接跳到代码修改，那说明这个 skill 并没有被正确使用。

面向 Code Review 的推荐提示词模式

可以根据目标选用不同模式。

只做评估时：

Use the receiving-code-review skill to evaluate whether this review comment is technically correct for this repository. Do not implement yet.

要起草回复时：

Use the receiving-code-review skill to write a concise technical reply to this PR comment. Avoid praise language. Ask for clarification if needed.

在验证后再实施时：

Use the receiving-code-review skill. First verify the reviewer's request against the codebase. If valid, propose the smallest testable change and list risks before editing.

提升输出质量的实用技巧

一些很小的输入升级，往往能明显改善结果：

• 提供 reviewer 的原话，不要只给你自己的转述
• 提供相邻代码，而不只是目标函数
• 说明 reviewer 关注的是 style、correctness、performance 还是 architecture
• 告诉模型你们代码库里哪些约束是不能妥协的
• 让它识别 reviewer 是否在基于并未证实的前提做判断

当 agent 能把“要求改什么”与“仓库现实是什么”放在一起比较时，这个 skill 才会真正发挥作用。

receiving-code-review skill 常见问题

receiving-code-review 只适合在 PR 评论里回复真人吗？

不是。它同样适合在你正式回复之前，先做内部评估。很多时候，receiving-code-review 最好的第一次使用方式反而是“私下先判断”：先确认这条评论到底是正确、不完整，还是照做会有风险，再决定要不要公开回应以及怎么回应。

这个 skill 对新手友好吗？

是的，但有一个前提。它的工作流本身很容易理解，不过新手未必具备足够的技术上下文去判断某条反馈是否真的适合当前代码库。这个 skill 能提升处理纪律，但不能替代工程判断。

它和普通的“analyze this PR feedback”提示词有什么区别？

核心区别在于：它内建了对“立刻认同”的拒绝机制。SKILL.md 里的 receiving-code-review guide 把验证、澄清和有依据的反驳放在中心位置。相比之下，通用提示词经常优化的是社交表达是否顺滑，而不是技术结论是否正确。

什么情况下不该使用 receiving-code-review skill？

当任务已经定义得非常完整，而且属于机械执行、风险很低的场景时，可以跳过它，例如：

• 修一个明显的 typo
• 重命名一个不会影响行为的符号
• 执行团队中已经明确记录好的约定

它也不适合拿来对别人的代码做一次完整的对外 code review。这个 skill 的定位非常明确：它是帮助你“接收反馈”，而不是“发起审查”。

如果 reviewer 说错了，receiving-code-review 能帮上忙吗？

可以，事实上这正是它最强的使用场景之一。这个 skill 鼓励的是基于技术事实的回应，而不是防御性语气，也不是无脑照做。如果 reviewer 的建议和当前代码库冲突，你应该期待 agent 解释冲突点在哪里，并给出更清晰、更合适的回复方式。

它支持成批的 review 反馈吗？

支持，但前提是你要把完整批次都提供出来，并允许 skill 先把明确项和不明确项分开。这个 skill 很强调一点：只理解了一部分时，不应该开始实施。 这对于“把这些评论全修掉”这类场景尤其有用。

如何改进 receiving-code-review skill 的效果

给 receiving-code-review skill 提供仓库现实，而不只是 reviewer 文本

想快速提升 receiving-code-review 的输出质量，最有效的方法就是把评论和以下内容一起提供：

• file paths
• 当前实现片段
• constraints
• tests
• 相关的架构模式

如果一条 review 建议依赖本地设计决策，那它就不可能在脱离上下文的情况下被正确评估。

不要只让它总结，要让它做决策

很多效果不佳的运行，根源在于提示词只是让 agent “处理一下”反馈。更好的写法应该逼它做出明确选择：

• implement
• ask a clarifying question
• push back with reasoning
• defer pending missing context

这样这个 skill 才会从“描述反馈”变成“推动下一步行动”。

主动防住最常见的失败模式

最常见、也是代价最大的失败模式，就是过早实施。模型一看到 reviewer 建议，就开始改代码，却没先检查：

• reviewer 是否真的理解了当前代码
• 现有约束是否会让这个建议无效
• 其他评论是否会改变这条建议的含义
• 请求的改动是否带有隐藏副作用

你应该明确告诉 agent：“Do not implement until verification is complete.”

面对含糊的 review 线程，补齐更强的输入

如果反馈本身很模糊，那就由你来补齐判断框架：

Use receiving-code-review.

The reviewer says: "This flow should be simplified."
Please identify at least 3 plausible interpretations, map each to the current code, and tell me what clarification question would unblock implementation safely.

这比让模型自己猜一个含义然后直接继续，效果要好得多。

让反驳保持技术化且简洁

如果 reviewer 说错了，最好的输出通常是：短、准、基于证据。你可以要求它给出：

• reviewer 看起来依赖了哪个前提
• 代码库中哪个事实与这个前提冲突
• 一段最小但足够尊重的回复，用来解释这种不匹配

这样能让 receiving-code-review for Code Review 工作流保持有用，而不是变成对抗。

在第一轮回答后继续迭代

第一轮跑完之后，可以根据仍然缺失的信息补充上下文，再提升结果，例如：

• reviewer 意图仍然不清楚
• 缺少代码片段
• 缺少架构约束
• 缺少测试证据
• 缺少 diff 上下文

一个很好的二次提示词是：

Re-run receiving-code-review with this added context. Update your recommendation and tell me whether the original review comment is now clear enough to implement.

先验证，再把 skill 和实施步骤接起来

最好的采用方式是两阶段：

1. 先用 receiving-code-review 评估评论
2. 只有确认之后，才让模型开始改代码

把这两步分开，能显著提升可信度，因为你可以先检查它的推理，再决定是否让它动文件。

把这个 skill 变成团队标准

如果你的团队希望 AI 在 PR 工作流中表现一致，可以把这个 skill 固化成处理输入型 review 的默认指令：

• 不要先夸赞再说
• 不要盲目实施
• 不清楚就提问
• 对照本地代码验证
• 技术上站不住脚时就明确反驳

receiving-code-review skill 最长期、最有价值的用法，往往不是把它当成一次性提示词，而是把它变成团队内可重复执行的工作习惯。