receiving-code-review

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

2|Updated May 30, 2026
One-click install
npx skills add https://github.com/virahitvin8/crafty-gis --skill receiving-code-review-virahitvin8
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: receiving-code-review
Source: https://github.com/virahitvin8/crafty-gis/tree/main/GIT_STAR/assignment-generator/antigravity-skills-main/antigravity-skills-main/skills/receiving-code-review
Command: npx skills add https://github.com/virahitvin8/crafty-gis --skill receiving-code-review-virahitvin8

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Developers often respond to code review feedback with performative agreement or blind implementation, leading to broken functionality, wasted effort on unused features, and missed clarification on unclear items. ## Core Features & Use Cases - Structured Response Pattern: Enforces a read-understand-verify-evaluate-respond-implement workflow for every piece of review feedback. - Source-Specific Handling: Applies different trust levels for feedback from your human partner versus external reviewers, with explicit verification checklists. - YAGNI and Pushback Rules: Checks whether suggested features are actually used in the codebase and provides technical reasoning templates for pushing back on incorrect suggestions. - Use Case: A reviewer asks you to remove legacy compatibility code. Instead of agreeing immediately, you verify the build target, discover the API requires a newer version, and respond with the technical constraint and options. ## Quick Start Apply the receiving-code-review skill to evaluate and respond to the review comments on my current pull request.

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?

Read the complete feedback, restate the requirement in your own words, verify it against the codebase, then respond with technical acknowledgment or reasoned pushback. Implement one item at a time and test each fix individually.

What should I do when code review feedback is unclear?

Stop and ask for clarification before implementing anything. Partial understanding leads to wrong implementation, especially when items are related. State which items you understand and which need clarification.

When is it appropriate to push back on a reviewer suggestion?

Push back when a suggestion breaks existing functionality, violates YAGNI for unused features, is technically incorrect for your stack, or conflicts with prior architectural decisions. Use technical reasoning and reference working code or tests.

Should I implement every suggestion from external reviewers?

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

Why avoid saying thanks or great point in code review responses?

Performative agreement adds no technical value and can mask unverified implementation. State the fix or the technical requirement instead, letting the code itself demonstrate that the feedback was heard.