receiving-code-reviewlisted

# Receiving Code Review Review feedback is input to verify — not orders to obey, and not applause to return. Each finding is a *claim* about your code; your job is to confirm it against the code, then act on the merits. A reviewer can be wrong; so can you. Technical correctness over social comfort. ## When to use - Any review feedback has arrived on code you wrote — a human reviewer, an AI reviewer, a PR comment thread. - **Not** a step you skip because the feedback "looks obviously right". Obvious-looking findings are exactly where unverified agreement ships a wrong change. ## The discipline 1. **Gather all of it first.** Collect every comment — top-level, inline, per-file — before acting. Items relate; acting on a subset misimplements the whole. 2. **Understand each item.** If any is unclear, STOP — ask, don't guess. Partial understanding produces the wrong fix. 3. **Verify against the code.** For each *finding*, confirm the problem is real before changing anything. For each *suggestion*, check it's actually needed here (grep for the usage) before adopting it. 4. **Respond on the merits.** Agree where verified; push back with evidence where not. "Checked X — it already handles Y, leaving as is" is a complete, correct response. 5. **Acknowledge substantively, not socially.** "Verified — fixing." / "You're right, confirmed Z." No "absolutely right!", no thanks, no over-explaining. State it and move. ## Red flags — these thoughts mean STOP | Thought | Reality | | ------