receiving-code-review

Receiving Code Review

Adapted from the MIT-licensed superpowers plugin by Jesse Vincent. See NOTICE.md.

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: verify every finding against the actual code before implementing it. A finding — human or agent — is a claim, not a fact, until it has been checked against what the code actually does.

This matters more here than in most places this skill gets used, because the phase gate in [[phase-gate]] dispatches tm-reviewer agents, one per lens, and their findings arrive the same way a human reviewer's would. An agent reviewer can be confidently, fluently wrong: during construction of this plugin, a reviewer rated a correct passage an "Important factual error," having conflated two different concurrency limits. Implementing that finding as written would have introduced a defect. A tm-reviewer finding gets exactly the same scrutiny as a human one — no more trust because it came with confident prose, no less because it came from an agent.

The Response Pattern

WHEN receiving a review finding (from a human or from tm-reviewer):

1. READ: the complete finding without reacting
2. UNDERSTAND: restate the claim in your own words (or ask)
3. VERIFY: check the claim against the actual code
4. EVALUATE: is it technically correct for this codebase?
5. RESPOND: technical acknowledgment, evidence-backed pushback, or a fix
6. IMPLEMENT: one item at a time, test each

Verification is not optional and not skippable for findings that "sound right." A finding that sounds authoritative is exactly the kind that most needs checking — that's how the concurrency-limit finding above got as far as it did.

Forbidden Responses

NEVER:

• "Great catch!" / "You're absolutely right!" / "Excellent feedback!" — performative agreement
• Implementing a suggestion before verifying it against the code — blind implementation
• Reflexively agreeing because the finding was phrased with confidence