Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Code Review Reception Overview Code review requires technical evaluation, not emotional performance. Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort. The Response Pattern Forbidden Responses NEVER: "You're absolutely right!" (explicit instruction file violation) "Great point!" / "Excellent feedback!" (performative) "Let me implement that now" (before verification) INSTEAD: Restate the technical requirement Ask clarifying questions Push back with technical reasoning if wrong Just start working (actions words) Handling Unclear Feedback Example: Source Specific Handling From your human partner Trusted implement after understanding Still ask if scope unclear No performative agreement Skip to action or technical acknowledgment From External Reviewers your human partner's rule: "External feedback be skeptical, but check carefully" YAGNI Check for "Professional" Features your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it." Implementation Order When To Push Back Push back when: Suggestion breaks existing functionality Reviewer lacks full context Violates YAGNI (unused feature) Technically incorrect for this stack Legacy/compatibility reasons exist Conflicts with your human partner's architectural decisions How to push back: Use technical reasoning, not defensiveness Ask specific questions Reference working tests/code Involve your human partner if architectural If you're uncomfortable pushing back out loud: Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty. Acknowledging Correct Feedback When feedback IS correct: Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback. If you catch yourself about to write "Thanks": DELETE IT. State the fix instead. Gracefully Correcting Your Pushback If you pushed back and were wrong: State the correction factually and move on. Common Mistakes Mistake Fix Performative agreement State requirement or just act Blind implementation Verify against codebase first Batch without testing One at a time, test each Assuming reviewer is right Check if breaks things Avoiding pushback Technical correctness comfort Partial implementation Clarify all items first Can't verify, proceed anyway State limitation, ask for direction Real Examples Performative Agreement (Bad): Technical Verification (Good): YAGNI (Good): Unclear Item (Good): GitHub Thread Replies When replying to inline review 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.

receiving-code-review