The receiving-code-review Skill — Verify Before Implementing Review Feedback
How Datarim's receiving-code-review skill replaces performative agreement with a six-step verification pattern — read, understand, verify against the codebase, evaluate, respond, implement.
An AI assistant that replies "You're absolutely right! Let me implement that now" to every review comment is not doing code review — it is doing social performance. The receiving-code-review skill replaces that pattern with a six-step sequence built around one principle: verify before implementing.
The six-step pattern
The response sequence is fixed: read the complete feedback without reacting, restate the technical requirement in the agent's own words (or ask for clarification if the requirement is unclear), verify against the actual codebase, evaluate whether the suggestion is technically sound for this project, respond with a technical acknowledgment or a reasoned objection, then implement one item at a time and test each. If any item in the feedback is unclear, the skill halts the sequence entirely at step two — partial implementation based on partial understanding produces a wrong result.
When to push back
The skill lists concrete conditions for pushback: when a suggestion breaks existing functionality, when the reviewer lacks full context of the codebase, when the change adds a feature nothing currently calls (YAGNI), when it is technically incorrect for the stack in use, or when it conflicts with prior architectural decisions. The mechanism for pushback is technical reasoning — checking whether the proposed change would break existing tests, referencing the reason the current implementation exists, or asking a specific question. The skill treats external review suggestions as items to evaluate, not orders to follow.
No performative agreement
Responses like "Great point!" or "Thanks for catching that!" are listed as forbidden — not because thanks are rude, but because they substitute social signals for technical ones. When feedback is correct, the right response is either a brief description of what changed or the fix itself. When it is wrong, the right response is a specific technical counter-argument. Both cases call for precision, not warmth.
GitHub inline replies
When responding to inline review comments on a GitHub pull request, the skill specifies that replies go into the comment thread via the gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies endpoint — not as top-level PR comments. This keeps the conversation threaded under the line of code it references, not scattered across the PR. See the receiving-code-review reference, or read what Datarim is for the full picture.