Agent skill · software engineering · aiskillstore
receiving-code-review
Assesses and responds to incoming code review feedback on PRs (reviewer comments, requested changes), especially when suggestions are unclear, technically questionable, or scope-expanding. Use before implementing review suggestions to align on intent and keep changes minimal.
Why this skill is useful
Codifies a structured approach to handling code review feedback, reducing ambiguity in responses.
What it needs
About 4k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
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. When NOT to Use Simple, unambiguous feedback you fully understand Direct requests from your human partner with clear intent When explicitly asked to "just implement this" Trivial corrections (typos, formatting) that need no verification The Response Pattern Forbidden Responses NEVER: "You're absolutely right!" (performative; violates anti-sycophancy norms) "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 Principle: External feedback warrants skepticism but thorough checking. YAGNI Check for "Professional" Features Principle: If a feature isn't needed, don't add it—regardless of who suggests 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 Acknowledging Correct Feedback When feedback IS correct: (See Forbidden Responses above for what NOT to say) Why no thanks: Actions speak. The code itself shows you heard the feedback. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/receiving-code-review