receiving-code-review

Evaluate incoming review feedback technically before acting on it: read all items, restate or ask about anything unclear before implementing any of them, verify each suggestion against the actual codebase, push back with evidence when a suggestion is wrong for this code, and skip performative agreement entirely. Use when processing review comments from a human or an automated reviewer, when feedback seems technically questionable or context-blind, when a reviewer proposes 'implementing properly' something nothing calls (grep usage first, propose removal), or when a reply is about to start with 'you're absolutely right'. Order of work: clarify everything, then blocking issues, simple fixes, complex fixes — testing each individually; a pushback that turns out wrong gets a one-line factual correction, not an apology. Not for performing a review of someone else's change (/code-review or review-panel) and not for triaging accumulated feedback reports into a backlog (feedback-triage).