receiving-code-review

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

1|Updated Feb 18, 2026
One-click install
npx skills add https://github.com/Emmanuel-R8/aikos --skill receiving-code-review-emmanuel-r8
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: receiving-code-review
Source: https://github.com/Emmanuel-R8/aikos/tree/main/.cursor/skills/receiving-code-review
Command: npx skills add https://github.com/Emmanuel-R8/aikos --skill receiving-code-review-emmanuel-r8

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When receiving code review feedback, AI assistants often respond with performative agreement or blindly implement suggestions without verifying them against the actual codebase. This Skill enforces a disciplined response pattern: read, understand, verify, evaluate, then implement or push back with technical reasoning. ## Core Features & Use Cases - Structured Response Pattern: A six-step workflow (read, understand, verify, evaluate, respond, implement) that prevents premature implementation of unverified feedback. - Source-Specific Handling: Different rules for trusted human partner feedback versus external reviewer suggestions, including YAGNI checks for unused features. - Pushback Guidance: Concrete criteria and phrasing for pushing back on technically incorrect suggestions, plus rules for GitHub inline review thread replies. - Use Case: A reviewer suggests removing legacy code or adding a metrics endpoint. Instead of agreeing, you grep the codebase, find the endpoint is unused or the legacy code is needed for backward compatibility, and respond with technical reasoning. ## Quick Start Use the receiving-code-review skill to evaluate this reviewer's feedback before implementing any changes.

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 as an AI assistant?▼

Follow a six-step pattern: read the full feedback, restate the requirement, verify against the codebase, evaluate technical soundness, respond with acknowledgment or reasoned pushback, then implement one item at a time with testing. Avoid performative phrases like "You're absolutely right!"

How do I handle unclear code review comments before implementing?▼

Stop and ask for clarification on any unclear items before implementing anything. Partial understanding leads to wrong implementations because feedback items are often related. State which items you understand and which need clarification.

When should I push back on a code review suggestion?▼

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

Should I implement external reviewer suggestions without verification?▼

No. External feedback is a suggestion to evaluate, not an order. Check whether it is technically correct for this codebase, breaks existing functionality, and whether the reviewer understands the full context. If you cannot verify, state the limitation and ask for direction.

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 (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment. This keeps the discussion threaded with the original feedback.