AC
Methodology & Process5.8 KBMIT licensed

receiving-code-review

Rewritten from patterns in obra/superpowers (MIT)

Discipline for responding to code review feedback: verify against the codebase before implementing, push back with evidence, no performative agreement. Use when review comments arrive on your work, before implementing any reviewer suggestion, or when feedback seems unclear or wrong. Not for asking for a review of your own work: use requesting-code-review. Not for performing a review of someone else's code.

  • receiving
  • code
  • review

SKILL.md

Receiving Code Review

Review feedback is input to evaluate, not orders to execute. Verify against the codebase before implementing, push back with evidence when the reviewer is wrong, and never perform enthusiasm.

The response loop

  1. Read the full feedback without reacting. All items, not just the first.
  2. Understand. Restate each item in your own words. Any item unclear: stop, ask about all unclear items before implementing anything. Items interact; partial understanding produces wrong fixes.
  3. Verify. Check the claim against the code. Does the suggestion break existing behavior? Is there a reason the current code is the way it is? Does the reviewer have full context (platform targets, compat constraints, prior decisions)?
  4. Evaluate. Is it correct for this codebase, not codebases in general?
  5. Respond. Technical acknowledgment, a clarifying question, or reasoned pushback. Never flattery.
  6. Implement one item at a time: blocking issues first, then trivial fixes, then complex ones. Test each before the next. Verify no regressions at the end.

Trust levels

  • Your human partner's feedback: trusted. Implement after you understand it. Still ask when scope is unclear. Still no performative agreement.
  • External reviewers (bots, CI reviewers, other engineers): evaluate first. If a suggestion conflicts with your partner's prior decisions, stop and raise it with your partner before touching code.
  • Cannot verify a claim? Say exactly that: "I can't verify this without <X>. Investigate, ask, or proceed?" Do not implement unverifiable suggestions silently.

Banned responses

Never write: "You're absolutely right!", "Great point!", "Excellent feedback!", "Thanks for catching that!", or any gratitude filler. Never announce "Let me implement that now" before verifying. Instead: restate the requirement, ask the question, push back with evidence, or just fix it and show the diff. The code is the acknowledgment.

If you catch yourself typing "Thanks": delete it, state the fix.

Pushing back

Push back when the suggestion breaks working behavior, ignores platform or compatibility constraints, adds an unused feature (grep first: if nothing calls it, propose deleting it instead of gold-plating it), or contradicts an architectural decision your partner made. Use technical reasoning and cite code or tests, not defensiveness. If it is architectural, involve your partner.

If you pushed back and were wrong: one factual sentence. "Verified, you're correct: <X> does <Y>. Fixing." No apology spiral, no defense of the original pushback.

Good vs Bad

Reviewer: "Remove this legacy code path."

Bad: "You're absolutely right! Removing it now." Then CI breaks for every user on the older OS the path served.

Good: "Checked: build target is <MIN_VERSION>, the replacement API needs a newer OS. The legacy path is load-bearing for older targets. It does have a wrong identifier though. Fix the identifier, or drop support for older targets?"

Verification

Before replying to any review item, run the check that proves or disproves it: grep for callers, run the affected tests, check version or platform constraints. Expect concrete evidence in hand before you write a response. If you have no evidence either way, your reply must be a question or a stated limitation, not agreement.

After implementing, run the full test suite. Expect green plus a passing test covering each fix. If anything fails, fix before reporting done.

When replying to inline comments on GitHub, reply in the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

Red flags: stop if you hear yourself say

  • "You're absolutely right!"
  • "Great point, implementing now."
  • "I'll just do what the reviewer says, it's faster than checking."
  • "I'll implement the items I understand and ask about the rest later."
  • "The reviewer is senior, they must be right."
  • "I'll batch all the fixes and test at the end."
  • "It's easier to add the feature than to argue it's unused."

Every one of these is the same move: substituting social compliance for verification. Rewording the excuse does not exempt you from the loop. If a response would violate the letter of these rules, it violates the spirit. Verify, then respond.

Footguns

  • Partial clarity, full speed. Implementing the clear items while items 4 and 5 are ambiguous. Related items make your "clear" fixes wrong. Fix: clarify everything first, then implement.
  • Batch-fix, single test run. One broken fix hides inside five good ones. Fix: implement and test one item at a time.
  • Silent capitulation. You suspected the suggestion was wrong, implemented it anyway, shipped a regression. Fix: name the tension, show the evidence, let your partner decide.

Completion checklist

  • [ ] Every feedback item restated, clarified, or challenged; none skipped
  • [ ] Each implemented item verified against the codebase before coding
  • [ ] Items implemented one at a time, each tested
  • [ ] Pushback (if any) cites code, tests, or constraints
  • [ ] Zero performative agreement or gratitude filler in responses
  • [ ] Full suite green after all fixes

Any box unchecked: not done. Fix or say so.

More in Methodology & Process

brainstormingTurn a raw idea into an approved design before any code exists. Use before creating features, building components, addin...doubt-driven-developmentSubject every non-trivial decision to a fresh-context adversarial review before it stands, while course-correction is st...executing-plansExecute a written implementation plan task by task with verification at every step. Use when a plan file exists and the ...
All skills