Master Code Review Reception

Defines a structured protocol for receiving and responding to code review feedback, built around one core principle: verify before implementing, ask before assuming, and prioritize technical correctness over social comfort. The response pattern is a six-step sequence: read the complete feedback without reacting, restate the requirement in your own words (or ask), verify it against the codebase, evaluate whether it is technically sound for this specific codebase, respond with a technical acknowledgment or reasoned pushback, then implement one item at a time, testing each.

Use this skill when processing code review feedback, whether from a trusted human partner or an external reviewer, especially when feedback is ambiguous, multi-item, or proposes a "proper" implementation of a feature that may not actually be needed. Not a fit for feedback that requires no judgment call, such as an unambiguous typo fix, where the protocol's verification overhead adds no value.

Input is raw review feedback, which may come from a trusted human partner (implement after understanding, still ask if scope is unclear, no performative agreement) or an external reviewer, whose suggestions are subject to five checks before implementing: is it technically correct for this codebase, does it break existing functionality, is there a reason for the current implementation, does it work across all platforms and versions, and does the reviewer have full context. When feedback covers multiple items, any unclear items are flagged and clarified first before implementing anything, since partial understanding of related items risks a wrong implementation. A YAGNI check applies when a reviewer suggests "implementing properly": grep the codebase for actual usage first, and propose removing unused code rather than fully building out a feature nobody calls.

Output is either a technical acknowledgment (for example, "Fixed. [what changed]"), a reasoned technical pushback, a stated verification limitation when something can't easily be checked, or - when a prior pushback turns out to be wrong - a factual correction such as "You were right - I checked X and it does Y. Implementing now," without an apology or over-explanation. Explicitly forbidden outputs are performative agreement phrases like "You're absolutely right!" or "Great point!", and any gratitude expression such as "Thanks for catching that!" - the reasoning is that actions should speak, so the fix itself demonstrates the feedback was heard.

When replying to inline review comments on GitHub, the protocol calls for replying within the comment thread via gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies rather than posting a new top-level PR comment.

Developers and coding agents who receive code review feedback and need a consistent way to separate genuine technical correction from social pressure to agree, particularly in contexts where a human partner and other reviewers are both providing input and verification is expected before action is taken.