receiving-code-review

Guides verification-first handling of code review feedback before implementing suggested changes.

Updated May 21, 2026
One-click install
npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill receiving-code-review-cagesthrottleus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: receiving-code-review
Source: https://github.com/CagesThrottleUs/private-ai-harness/tree/main/skills/receiving-code-review
Command: npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill receiving-code-review-cagesthrottleus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers and AI agents often respond to code review feedback with performative agreement or blind implementation, shipping unverified changes that break functionality or miss sibling occurrences of the same defect. This Skill enforces technical verification, clarification of unclear items, and complete pattern propagation before any code changes. ## Core Features & Use Cases - Verify-Before-Implement Workflow: A six-step response pattern (read, understand, verify, evaluate, respond, implement) that replaces performative agreement with technical rigor. - Pattern Propagation Check: Sweeps the current PR diff for sibling occurrences of each accepted finding, including analogous paths (CLI vs MCP, primary vs fallback, sync vs async) and shared-helper call sites. - Proportionality Gate: Decides whether an accepted finding gets fixed now or filed as a follow-up ticket based on fix complexity and cumulative PR size. - Use Case: A reviewer flags a missing nil check in one handler; the Skill directs you to fix the same defect in the other two handlers the PR touched, verify shared-helper callers, and reply in each GitHub comment thread. ## Quick Start Use the receiving-code-review skill to process the reviewer feedback on my current pull request before making any changes.

Frequently Asked Questions about receiving-code-review

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

FAQPage Schema
How do I respond to code review feedback professionally?

Restate the technical requirement, verify it against the codebase, then implement or push back with technical reasoning. Avoid performative phrases like "great point" or "you're absolutely right" — state the fix or ask clarifying questions instead.

How to handle unclear code review comments before implementing?

Stop and ask for clarification on every unclear item before implementing anything. Partial understanding leads to wrong implementations because feedback items are often related, so clarify all items first, then implement in order of blocking issues, simple fixes, and complex fixes.

When should I push back on a code review suggestion?

Push back when a suggestion breaks existing functionality, violates YAGNI or KISS, conflicts with architectural decisions, or is technically incorrect for your stack. Use technical reasoning and reference working tests, and involve the project owner for architectural disagreements.

Should I fix only the exact line a reviewer commented on?

No. A review comment usually indicates a pattern, so sweep the current PR diff for sibling occurrences, including analogous paths like fallback handlers and async variants. Fixing only the quoted line typically costs another full review round.

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

Reply within the comment thread using the GitHub API replies endpoint, not as a top-level PR comment. Reply to every comment, even trivial ones — a short "Fixed." confirms the feedback was seen, while silence leaves reviewers unsure.