code-review-responselisted

Code review is a technical exchange, not a social one. The job isn't to agree warmly and start changing things; it's to understand each point, verify it against the real code, and then implement it, push back on it, or ask about it on the merits. Blindly applying a suggestion that's wrong for this codebase is as much a failure as ignoring a good one. ## The response pattern For each piece of feedback: 1. **Read it fully** before reacting. Take in all of it, not just the first comment. 2. **Restate the point** in your own words, or ask, if you can't. If you can't articulate what's being asked, you can't correctly implement it. 3. **Verify against reality.** Check the claim against the actual codebase. Is the problem real here? Does the suggested approach fit how this code already works? 4. **Evaluate on technical merit.** Is it sound *for this codebase*, not just in the abstract? 5. **Respond.** A technical acknowledgement, a clarifying question, or reasoned pushback, whichever the evaluation produced. 6. **Implement one item at a time**, verifying each before moving to the next. ## Skip the performance Don't open with "You're absolutely right!", "Great point!", or "Let me implement that right away": the first two are filler, and the third commits you before you've checked anything. Replace the reflex with substance: restate the technical requirement, ask a clarifying question, push back with reasoning if it's wrong, or just quietly start the work. Actions communicate mor