Receiving Code Review: Technical Evaluation Over Performative Agreement

Introduction: The Moment the Findings Come Back

Every engineer has lived the other scene. You asked for the review exactly as the requesting-code-review skill prescribes — pinned SHA range, stack of evidence — and the findings came back: three of them, one you disagree with, one you half understand, one obviously right. The next sixty seconds decide whether the review was worth its price, and most people spend them performing enthusiasm instead of thinking.

The Superpowers receiving-code-review skill governs exactly that window. Its one-line description is already a filter: use when receiving code review feedback, before implementing suggestions — requires technical verification, not performative agreement or blind implementation. It is the second half of a handshake: the requesting skill makes sure good findings arrive; the receiving skill makes sure they are processed like evidence rather than received like applause.

What the Receiving Code Review Skill Actually Does

The skill is a response protocol: it defines what must happen between reading feedback and touching the keyboard, and it bans a specific list of sentences. Its core principle heads the SKILL.md: code review requires technical evaluation, not emotional performance. The six-step pattern it installs is deliberately boring:

WHEN receiving code review feedback:

1. READ:       Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY:     Check against codebase reality
4. EVALUATE:   Technically sound for THIS codebase?
5. RESPOND:    Technical acknowledgment or reasoned pushback
6. IMPLEMENT:  One item at a time, test each

Steps three and four are the whole skill compressed. “Check against codebase reality” means: open the code the reviewer is talking about, find out what it actually does, and ask whether the suggestion survives contact with this stack, this architecture, these tests. The reviewer — human or subagent — evaluated your work from the outside; you are the one positioned to check the feedback from the inside before spending a change on it.

The skill lives in software-development/superpowers-receiving-code-review and pairs explicitly with requesting-code-review: one scripts the ask, the other the answer. A perfect request met with blind compliance produces the same broken code as a sloppy one met with defensiveness.

Technical Evaluation Over Performative Agreement

The most conspicuous feature of the skill is its list of forbidden responses. Never say “You’re absolutely right!”, “Great point!”, or “Let me implement that now” before verification. The ban looks like a style preference until you notice what those sentences do: they announce a verdict the speaker has not reached. “You’re absolutely right” commits you to the fix before step three has checked whether the reviewer is right — the reviewer now believes the item is closed while the codebase says otherwise. For an AI agent the failure is worse: it immediately builds on the change.

The approved replacements are deliberately flat:

OK:  "Fixed. [brief description of what changed]"
OK:  "Good catch — [specific issue]. Fixed in [location]."
OK:  [just fix it and show the result in the code]

BAD: "You're absolutely right!"
BAD: "Great point!"
BAD: any gratitude expression at all

Restating the technical requirement is the preferred acknowledgment because a restatement is checkable: “So: extract the retry loop into a decorator so the backoff policy is testable — doing that one first” tells the reviewer what you understood, in a form they can correct. “Great point!” conveys nothing except that you can type. The skill’s summary of the exchange: actions > words — just fix it.

One Unclear Item Stops Everything

Multi-item feedback carries a trap the skill handles with a hard stop: if any item is unclear, do not implement anything yet. The reason is coupling — the comment about the error handler and the comment about the retry loop usually describe the same subsystem from two angles, and implementing the half you understood while the other half sits misunderstood is how a confidently wrong diff gets written at double speed. Clarify every open question first, then implement in a fixed order:

Blocking issues first — breakage and security findings, before anything else.
Simple fixes next — typos, imports, dead config.
Complex fixes last — refactors and logic changes.

Each fix gets tested individually before the next starts. Batch implementation without per-item testing turns every regression into a detective story: you know something broke, you no longer know what.

Where the Feedback Comes From Changes the Protocol

The skill treats all feedback as unequally verified. Feedback from the user is trusted: implement once you understand it, still asking when scope is unclear, but skip the legitimacy audit. Feedback from an external reviewer — a colleague, a CI bot, a reviewer subagent — gets a five-question gate before a single line changes:

1. Is this technically correct for THIS codebase?
2. Does implementing it break existing functionality?
3. Is there a reason for the current implementation?
4. Does the suggestion work on all platforms/versions?
5. Does the reviewer understand the full context?

Question three saves the most wasted effort: code that looks wrong is often code that survived an earlier review because it had to, and a reviewer seeing the scar for the first time will recommend the exact surgery that reintroduces the wound. One rule overrides the checklist — if the feedback conflicts with the user’s prior architectural decisions, stop and discuss with the user first.

Real Example: The Plan Review That Changed the Execution Approach

The plan behind this very article series provides a clean case. It called for nineteen self-contained HTML articles built from one shared template, with several writer agents dispatched in parallel against it. A reviewer subagent graded the plan and returned an Important finding: multiple agents working from one shared template concurrently will drift from it, article to article — serialize the writing so only one agent runs at a time.

The performative response — “You’re absolutely right! Restructuring for sequential execution now” — takes four seconds and costs nineteen serial runs instead of parallel batches. The protocol runs steps two through four instead. Restated requirement: guarantee structural consistency across all nineteen articles. Verified against reality: writers never edit the shared template — each copies it once into its own file and writes only there. No concurrent write path exists, so drift cannot occur by the route proposed. But the underlying concern survived: consistency across nineteen independent outputs genuinely was not guaranteed — just not by the failure mode the reviewer named.

The response was reasoned pushback with partial adoption: keep parallel dispatch, freeze the template for the duration of writing, and add a per-article byte-level verification gate — carriage-return count (catching the Windows CRLF failure mode), meta description presence, internal link resolution — so any drift gets caught mechanically. The plan was amended on those terms and execution stayed parallel. The reviewer’s concern won; the reviewer’s proposed fix did not; nobody said “great point.”

How to Disagree: Explain Why, Not Just Say “Ok”

Quiet compliance is the other side of performative agreement, and the skill bans it by giving disagreement an explicit legitimacy. Push back when the suggestion breaks existing functionality, when the reviewer lacks full context, when it violates YAGNI by adding an unused feature, when it is technically wrong for the stack, or when it conflicts with the user’s architectural decisions.

The how matters as much as the when. Pushback is delivered as technical reasoning — the specific mechanism that breaks, the platform matrix the suggestion ignores, the working tests that disprove the finding — or as a precise question the reviewer can answer in one sentence. The goal is not to win the exchange but to reach the same place verification reaches when the reviewer is right: a correct fix, accepted without a face-saving detour. A wrong pushback costs one round trip; blind compliance with a wrong suggestion costs a rewrite plus whatever the rewrite regressed. That asymmetry is the entire argument for disagreeing out loud.

The skill protects the other direction too: “avoiding pushback” is listed as a common mistake with the fix “technical correctness > comfort.” Saying “ok” to a suggestion you believe is wrong is not humility — it is transferring your verification work to the next person who reads the diff.

Sidebar: The difference between a good reviewer and a nitpicker. A good reviewer ties every item to a consequence — what breaks, what becomes unmaintainable, which requirement goes unmet — and grades severity honestly, so “Important” means fix before proceeding rather than fix before proceeding, allegedly. A nitpicker optimizes for presence in the diff: re-litigating formatting a linter already owns, renaming for taste, marking everything Important because severity is free to spend. The litmus test is one question: can the reviewer state what goes wrong if they don’t get their way? If not, it’s preference wearing a findings hat. The receiver’s protocol costs the same either way — verify, evaluate, respond — and a nitpick dies cheaply in one paragraph of technical reasoning, while a rewrite based on it dies expensively in production.

The Mistake Ledger

The SKILL.md closes with a table of the failure modes it exists to prevent:

Mistake	Fix
Performative agreement	State the requirement or just act
Blind implementation	Verify against the codebase first
Batch without testing	One item at a time, test each
Assuming the reviewer is right	Check whether it breaks things
Avoiding pushback	Technical correctness > comfort

Related Deep Dives in the Series

requesting-code-review — the other half of the handshake: how to compose the request so the findings worth evaluating are the ones that arrive.
finishing-a-development-branch — where every accepted and rejected review item is finally reconciled before merge, PR, or discard.
subagent-driven-development — the workflow that makes review mandatory after every task, so the receiving protocol runs many times per feature.
verification-before-completion — the same epistemology pointed at your own claims: fresh evidence, not memory.

Frequently Asked Questions

Q: Doesn’t verification-before-implementation slow the loop down, if reviewers are usually right?
The check is minutes: open the named code, run the named test. Blind implementation of a wrong suggestion costs a rewrite plus regressions, and you pay it even when the reviewer is wrong only a fraction of the time. The expected-value math is not close.

Q: Does this protocol apply when an AI agent receives review from a human?
Especially then — the skill is adapted from the Superpowers canon where both reviewers and implementers are agents. Performative agreement is the agent’s native failure mode: trained to be agreeable, it will cheerfully implement a suggestion that breaks its own passing tests. The forbidden-response list and the verify-first gate are load-bearing because the pressure to comply is strongest when the implementer has no ego to protect, only a completion signal.

Q: What if I can’t evaluate a finding because I don’t know that part of the codebase?
Then step two already has your answer: restate the requirement or ask. Not knowing the area is exactly when blind implementation is most dangerous, and the hard stop on unclear items exists so you ask before you break something.

Key Takeaways

The receiving-code-review skill turns feedback into a technical claim with a protocol: read, restate, verify against the codebase, evaluate, respond, then implement one item at a time with a test after each.
Performative agreement — “You’re absolutely right!”, “Great point!” — is banned because it announces a verdict before the evidence exists; restate the requirement in checkable words or just fix it.
Any unclear item stops all implementation until clarified; fix order is blocking, simple, complex, tested individually.
User feedback is trusted and implemented after understanding; external feedback faces a five-question gate, and anything that conflicts with the user’s decisions goes back to the user.
Disagree with reasoning, questions, and working tests — not silence. Accept the reviewer’s concern, verify the proposed fix, and change course only where evidence says to.

Next in this series: finishing a development branch — reconciling every review outcome before the merge decision. Browse the full Skills We Use series index for all nineteen articles.