How to use the Receiving Code Review agent skill

What the receiving-code-review skill makes the agent do

The skill sets a working order for review feedback: read the whole list, restate or question each item, verify it against the code, assess whether it is technically sound for this codebase, respond, then implement one item at a time with testing in between.

It tells the agent to avoid empty agreement such as "you're absolutely right" and to state what was fixed instead. When feedback is unclear, the agent should stop and ask about the unclear items before implementing anything, because related items may depend on each other.

• Ask clarifying questions when any item in the feedback is unclear.
• Check external reviewer suggestions for breaking changes, missing context, and unused features (YAGNI).
• Push back with technical reasons when a suggestion would break existing behaviour or is incorrect for the stack.
• Fix blocking issues first, then simple fixes, then complex ones, testing each one.
• Reply to GitHub inline review comments inside the comment thread, not as a top-level PR comment.

Install the skill from the ZIP

Download the ZIP for this skill from this page and unzip it. The skill is a single file named SKILL.md. Place the unzipped skill folder in one of two locations: your personal skills folder at ~/.claude/skills/, or a project-specific .claude/skills/ folder inside the repository you are working on.

If you use the Claude apps instead of a local folder, you can upload the skill under Settings → Capabilities → Skills.

• Personal use across projects: put the skill in ~/.claude/skills/.
• Shared with one repository: put the skill in that project's .claude/skills/ folder.

How to trigger the skill with natural requests

You do not need a special command. The skill describes itself as applying after you receive code review feedback and before you act on it, especially when feedback is vague or technically questionable. Give the agent the review comments and say what you want done with them.

Requests that match the skill's purpose include asking the agent to evaluate comments rather than apply them, or asking it to take a list of review items one at a time.

• "Here are the review comments on my PR. Check each one against the code before changing anything."
• "The reviewer wants items 1 to 6 fixed. Tell me if any of them are unclear before you start."
• "This reviewer suggests adding a generic helper. Is anything calling it? Push back if it isn't needed."
• "Respond to these inline GitHub comments in their threads."

Example: handling a review comment

Suppose a reviewer writes "Remove the legacy code." Instead of deleting it, the agent checks the project. In the source's worked example, the agent finds that the build target is 10.15 or later while the API in question needs 13 or later, so the legacy code is needed for backward compatibility. It then replies with that finding and asks whether to fix the incorrect bundle ID or drop support for versions before 13.

In another example, a reviewer asks for full metrics tracking with database, date filtering and CSV export. The agent searches the codebase, finds nothing calls the interface, and asks whether to delete it under the YAGNI principle or whether it missed a caller.

What you need before you start

The skill assumes a software codebase and a review workflow. You need access to the code, plus a pull request or written review feedback to work from. For replying to GitHub inline review comments, the skill references the GitHub CLI (gh) and a replies API endpoint for pull request comments.

The skill contains no scripts and does not use the network on its own. The GitHub reply step is the only tool-specific instruction in the file.

• Access to the codebase the feedback applies to.
• A PR or written review feedback.
• The GitHub CLI (gh), only if you want replies posted to GitHub comment threads.

Safety notes: scripts and network

The skill runs no scripts and uses no network access according to its listing. Its main effect is on how the agent reasons and what text it writes. Changes to code still happen through the agent's normal tools in your project, so review the diffs it produces as you would for any change.

The reply command above posts to GitHub on your behalf when used. Check the target pull request and comment ID before the agent posts.

• Review any code changes the agent makes before merging.
• Confirm the repository, PR number and comment ID before any GitHub reply is posted.

Tips for getting good results

Give the agent the full feedback in one message so it can see dependencies between items. Ask it to verify before implementing, and expect it to report what it checked. If you want the agent to simply apply every comment, this skill will work against that, so choose a different approach for that workflow.

• Paste all review items at once so related items are read together.
• Ask for one fix at a time and a test run after each.
• Keep the "what was fixed" style: short, factual replies.