评审意见可能发现真实缺陷，也可能基于过时的上下文。receiving-code-review 的目的，是让 Agent 先弄懂问题和当前实现，再决定怎么改，而不是看到评论就把建议全部照搬进代码。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 receiving-code-review，再交代任务范围。
/plugin install superpowers@claude-plugins-official
先读完整反馈，不急着逐句修
以下是可按项目调整的首次输入：
使用 Superpowers receiving-code-review，处理我粘贴的三条评审意见。先读相关实现和调用处，指出哪些可以直接修、哪些依赖未明确需求；对有争议的意见给代码与测试依据。逐项实施已确认修改并验证，先起草回复，不发送评论。
给出评论原文、对应代码位置以及评审时所看的版本。几条意见有时共享一个前提，例如接口是否必须兼容旧客户端；如果前提尚未确定，先问清楚，再处理依赖它的修改。把一句模糊评论当成完整需求，容易造成新的偏差。
用当前代码判断建议是否成立
Agent 应查看实际调用处、测试与项目约束。有人建议增加一个通用配置项，就先检查是否有真实使用场景；有人认为某条校验多余，就追踪它是否保护了其他入口。讨论应落在具体行为与证据上，而不是因为对方是评审者就默认其结论正确。
可以把意见分成接受、需要澄清和暂不采用三类，每项都写明理由。需要澄清的内容应给出具体问题，例如“旧 API 是否仍需返回相同错误码”，比“这里不太懂”更容易推进。提出异议时也应说明哪段代码或测试支持当前做法，以及怎样的需求变化会让建议成立。
一项修改配一次验证
先处理阻塞问题，再按依赖关系安排简单和复杂的改动。每修一项就运行相关验证，避免同时改动过多后无法判断回归来自哪里。评审过程中发现与原需求冲突的建议，要回到需求决策者，而不是擅自扩大范围。
交付可以包括逐项处置表、代码改动、验证结果和可直接发送的回复草稿。真正向 PR 发评论是另一个动作，应在你要求发送时执行。意见已落实时，回复指出修改位置和结果即可，不需要长篇解释自己的态度。
这套流程也不意味着每一条小建议都要开辩论。明确、正确且符合项目约定的反馈可以直接修；关键是在不确定或影响行为的地方保留判断，确保评审让代码更好，而不是只是让评论数量归零。
遇到相互矛盾的评审意见
假设一位评审要求“为所有请求加缓存”，另一位指出该接口包含实时库存，担心读到旧数据。先追踪接口调用者、库存变化频率和现有缓存控制，写出两条意见各自想解决的问题。若慢查询确实存在，但实时库存不能过期，可提出只缓存不随库存变动的商品元数据，或先测量慢点。直接接受第一条或简单回复“已处理”，都没有解决冲突。
给评审者的草稿应对应具体行为：“库存响应继续实时读取；商品详情用 60 秒缓存，相关测试覆盖下架与价格变动”。时间值只是示例，必须依据项目已有约束确定。若建议改变了产品语义，例如允许旧库存继续下单，应把决定交回需求负责人。逐项修改时保留原评论、代码位置、验证命令和结果；如果核查后发现评论依据的是旧提交，礼貌说明当前行为及证据即可，不必为了“采纳率”改坏代码。
接手子代理评审时恢复上下文
收到子代理、GitHub 或同事的评审后，先把评论原文、对应改动和当前分支交给接手会话，明确要求使用 receiving-code-review 逐条判断。社区使用者发现，子代理评审或会话压缩之后，Skill 有时没有自动触发，回复变成“问题不大”或直接修改。此时先恢复评论的上下文，再让 Agent 对每条写出“所指代码—是否复现—决定—验证方式”，有疑问就查代码而不是礼貌地全部接受。完成修改后重新跑相关检查，并把接受或拒绝的理由写回评审记录。