Review comments can expose real defects, but they can also rely on outdated assumptions. Receiving-code-review helps an agent understand the feedback and verify it against the current implementation before changing code.
Install and start
Run the following plugin command inside a Claude Code session to install Superpowers, including its cooperating skills. In Codex, find Superpowers in the plugin interface and install it there. Install separately for each client you use. Start a fresh session in the project and explicitly ask to use receiving-code-review with a bounded task.
/plugin install superpowers@claude-plugins-official
Read the complete set of comments
Adapt this first request to your project:
Use Superpowers receiving-code-review for the three comments I provide. Read the implementation and callers, identify actionable items and unresolved requirements, and support disagreements with code or test evidence. Implement confirmed changes one at a time, verify them, and draft replies without posting comments.
Provide the original comments, relevant code locations, and the revision reviewed. Several comments may depend on the same unresolved assumption, such as whether an old client must remain compatible. Clarify that assumption before implementing dependent changes. A vague comment should not silently become a complete product requirement.
Check the suggestion against the code
Inspect actual callers, tests, and project constraints. If a reviewer proposes a new general configuration option, look for a real consumer. If a check appears redundant, trace whether it protects another entry point. Decisions should follow behavior and evidence rather than the reviewer's authority alone.
Classify comments as accepted, needing clarification, or not currently applicable, with a reason for each. Clarification should ask a precise question, such as whether an older API must retain its error code. When disagreeing, identify the relevant code or test and explain what changed requirement would make the suggestion appropriate.
This does not require debating every small improvement. Clear corrections consistent with project conventions can be implemented directly. Reserve deeper analysis for ambiguous comments or changes that alter behavior, scope, or compatibility.
Verify changes individually
Address blocking issues first, then order the remaining work by dependencies and complexity. Verify each accepted change before moving on so a regression can be connected to its cause. If a comment conflicts with the approved requirement, resolve that conflict with the person responsible for the requirement rather than quietly broadening the task.
Useful deliverables include a disposition list, code changes, relevant verification results, and draft replies. Posting comments to a pull request is a separate action; the example asks only for drafts. When an issue is fixed, a concise reply can identify the changed location and result without lengthy statements of agreement.
The aim is better code and a clearer technical discussion, not merely reducing the count of open comments. Keeping uncertainty visible while efficiently handling straightforward feedback makes the review easier to finish and easier for the next reader to understand.
Handle conflicting review comments
Suppose one reviewer asks to cache every response, while another notes that the endpoint includes live inventory. Trace the callers, update frequency, and existing cache controls before deciding. State the problem each comment aims to solve. If the query is slow but stock must be current, you might cache only stable product metadata or first measure the slow path. Blindly accepting the first comment, or replying “done,” does not resolve the conflict.
A draft reply should describe behavior: inventory still reads live, while product details use a cache with tests for delisting and price changes. Any cache lifetime is an example until project constraints establish it. A suggestion that changes product semantics, such as accepting orders against stale stock, must go back to the product decision maker. Keep each original comment, code location, check command, and outcome together. If a comment relied on an old revision, explain the current behavior with evidence rather than changing code for the sake of acceptance.
Restore context for subagent reviews
After a subagent, GitHub, or colleague reviews the work, give the receiving session the exact comment, affected change, and current branch, then explicitly ask for receiving-code-review on each item. A community user reported that in subagent workflows, especially after compaction, the skill sometimes did not trigger and replies became perfunctory or rushed into edits. Restore the context and ask for a per-comment account of code location, reproduction, decision, and verification. Inspect code where the claim is uncertain rather than accepting every suggestion. Rerun relevant checks and record why each comment was accepted or declined.