How to use the Receiving Code Review agent skill

What does the receiving-code-review skill make the agent do?

The skill covers one part of the review process: receiving feedback. It is not for writing new code or doing a first-pass review. Its source describes a response pattern the agent follows: read the complete feedback without reacting, restate the requirement in its own words (or ask), verify it against the codebase, evaluate whether it is technically sound for this codebase, respond with a technical acknowledgment or reasoned pushback, and then implement one item at a time while testing each.

• Verifies suggestions against the actual codebase before implementing them.
• Avoids empty replies such as 'You're absolutely right!' or 'Great point!'.
• Stops and asks for clarification when any item in a batch is unclear, rather than guessing.
• Pushes back with technical reasoning when a suggestion breaks existing functionality, conflicts with a prior decision, or seems unnecessary (for example, an unused feature).
• Replies to GitHub inline review comments inside their existing thread.

How do you install the receiving-code-review skill?

Download the ZIP file for the skill from this page. The skill's file is SKILL.md. You can install it in one of two ways.

For Claude Code, unzip the download into your user skills folder at ~/.claude/skills/ so it is available in all your projects. To limit it to one project, unzip it into that project's .claude/skills/ folder instead.

In the Claude apps, open Settings, go to Capabilities, then Skills, and upload the ZIP there.

• Personal install: ~/.claude/skills/
• Project install: the .claude/skills/ folder inside your project
• Claude apps: Settings → Capabilities → Skills

How do you trigger the skill with natural requests?

You do not need a special command. The skill's description tells the agent to use it when it receives code review feedback, before implementing suggestions, especially when feedback seems unclear or technically questionable. So the simplest way to trigger it is to give the agent the review comments and ask it to address them in a normal way.

You can also name the situation directly so the agent knows the context is review feedback and not a new task.

• 'Here are the review comments on my pull request. Address them, and push back where a suggestion looks wrong.'
• 'The reviewer wants me to remove this endpoint. Check whether anything calls it before changing anything.'
• 'Go through these inline comments and reply in each thread once you have checked the code.'
• 'Items 4 and 5 in this review are unclear. Ask me what they mean before you change anything.'

What does a good reply look like?

The skill's examples contrast weak and strong replies. A weak reply agrees without checking. A strong reply shows the agent looked at the code, states what it found, and either makes the change or asks a specific question.

In the source's example, a reviewer asks to remove legacy code. The agent checks the build target and the API it needs, finds a compatibility reason to keep the code, and asks whether to drop support for older versions. The reply is short, factual and gives the human a decision to make.

• Weak: 'You're absolutely right! Let me remove that...'
• Strong: 'Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Fix it or drop pre-13 support?'
• When feedback is correct: 'Fixed. [Brief description of what changed]'
• When you were wrong to push back: state the correction factually and move on, without a long apology.

How does the skill handle GitHub inline review comments?

When the agent replies to an inline review comment on GitHub, the skill tells it to reply inside the comment's thread, not as a new top-level comment on the pull request. The skill gives the GitHub CLI command pattern it uses for this.

• Requires the GitHub CLI (gh) to be installed and available to the agent.
• Replies go into the existing thread of the review comment.

What are the safety notes?

This skill runs no scripts. It does use the network, because replying to GitHub comments means running gh api commands that post to the public pull request. Those replies are visible to everyone who can see the pull request.

Because of this, do not use the skill in an automated pipeline that posts replies to GitHub without a person checking them first. Review the agent's replies before they are posted, especially when the agent is pushing back on a reviewer.

• Runs scripts: no
• Uses network: yes, through gh api commands
• Replies are posted publicly on GitHub
• Keep a human in the loop before replies go out

What tips help the skill work well?

The skill works best when the agent has access to the real codebase, so it can verify claims instead of guessing. Give it full review context when you can, and tell it how much to trust each source. The skill's own guidance is to treat your own instructions as trusted and external reviewer feedback as something to check carefully.

If the agent says it cannot verify something, answer its question. The skill is designed to state the limit and ask for direction rather than proceed blindly.

• Make sure the agent can read the repository it is reviewing.
• Send all items in a batch together so it can spot items that depend on each other.
• Tell the agent about architectural decisions that reviewers may not know about.
• Ask it to test each change separately when you have several fixes.