receiving-code-review

Guides verification and implementation of code review feedback with technical rigor.

Updated Aug 28, 2026
One-click install
npx skills add https://github.com/epicodic/drift --skill receiving-code-review-epicodic
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: receiving-code-review
Source: https://github.com/epicodic/drift/tree/main/.agents/skills/receiving-code-review
Command: npx skills add https://github.com/epicodic/drift --skill receiving-code-review-epicodic

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Receiving code review feedback often triggers performative agreement or blind implementation, leading to broken code, wasted effort on unclear items, and unverified suggestions from external reviewers. This Skill enforces a verify-before-implement discipline so feedback is evaluated against the actual codebase before any changes are made. ## Core Features & Use Cases - Structured Response Pattern: Read, understand, verify, evaluate, respond, then implement feedback one item at a time with individual testing. - Source-Specific Handling: Differentiates trusted feedback from your human partner versus external reviewer suggestions that require skepticism and codebase verification. - Pushback and YAGNI Checks: Provides criteria for pushing back on technically incorrect suggestions and checking whether proposed features are actually used before implementing them. - Use Case: A reviewer leaves six comments on your pull request, two of which are unclear. Instead of guessing, you clarify items 4 and 5 first, verify the rest against the codebase, then implement and test each fix individually. ## Quick Start Use the receiving-code-review skill to help me evaluate and respond to the review comments on my pull request before implementing anything.

Frequently Asked Questions about receiving-code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I respond to code review feedback before implementing it?▼

Read all feedback completely, restate each requirement in your own words, verify it against the actual codebase, then implement one item at a time with individual testing. Skip performative agreement phrases and let the code changes demonstrate the response.

What should I do when code review feedback is unclear?▼

Stop and ask for clarification on the unclear items before implementing anything. Partial understanding leads to wrong implementations because feedback items are often related, so clarify everything first rather than implementing only the items you understand.

Should I implement every suggestion from external code reviewers?▼

No. External feedback is a suggestion to evaluate, not an order. Check whether it is technically correct for your codebase, breaks existing functionality, follows project conventions, and whether the reviewer understands the full context before implementing.

When is it appropriate to push back on code review comments?▼

Push back when a suggestion breaks existing functionality, violates YAGNI by adding unused features, is technically incorrect for your stack, or conflicts with prior architectural decisions. Use technical reasoning and specific questions rather than defensiveness.

How do I reply to inline review comments on GitHub pull requests?▼

Reply within the comment thread using the GitHub API endpoint for pull request comment replies rather than posting a top-level PR comment. This keeps the discussion attached to the specific line of code being reviewed.