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 CLAUDE.md 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 Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K" 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. The Bottom Line External feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement. No performative agreement. Technical rigor always. When to Use This skill is applicable to execute the workflow or actions described in the overview. Limitations Use this skill only when the task clearly matches the scope described above. Do not treat the output as a substitute for environment specific validation, testing, or expert review. Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

receiving-code-review