Agent skill

Receiving Code Review

by farm-fe in farm-fe/farm

A skill your agent uses when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and…

MITAuto-check passedDevelopment

Install Receiving Code Review

skills CLI
$ npx skills add farm-fe/farm --skill receiving-code-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install farm-fe/farm receiving-code-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/farm-fe/farm.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/receiving-code-review .claude/skills/receiving-code-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
receiving-code-review
GitHub stars
5.6k
Used in
44 other repos
Token cost
~1.6k tokens
SKILL.md length
377 words
Files
1
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and…

  • Receiving code review feedback
  • SKILL.md covers Overview, The Response Pattern, Forbidden Responses and Handling Unclear Feedback, plus 10 more sections
  • Calls gh
  • Before implementing suggestions

What it does

Receiving Code Review is an agent skill from farm-fe/farm. Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Its SKILL.md is about 1.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Code review. The repository describes itself as: Extremely fast Vite-compatible web build tool written in Rust. The licence is MIT.

When your agent uses it

  • Receiving code review feedback
  • Before implementing suggestions
  • Especially if feedback seems unclear
  • Technically questionable - requires technical rigor and verification

Example prompts

  • “/receiving-code-review”

What it can do on your machine

Read from SKILL.md and the folder at commit 2000ef8. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Receiving Code Review loads about 1.6k tokens when it runs. Until then it costs about 64 tokens; SKILL.md has 377 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~64
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from farm-fe/farm at commit 2000ef8, republished under its MIT licence (© farm-fe). 377 words, ~1,569 tokens.

Download SKILL.mdSave it as .claude/skills/receiving-code-review/SKILL.md (or your agent's skills folder).
name
receiving-code-review
description
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Code Review Reception

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

Forbidden Responses

NEVER:

  • "You're absolutely right!" (explicit CLAUDE.md violation)
  • "Great point!" / "Excellent feedback!" (performative)
  • "Let me implement that now" (before verification)

INSTEAD:

  • Restate the technical requirement
  • Ask clarifying questions
  • Push back with technical reasoning if wrong
  • Just start working (actions > words)

Handling Unclear Feedback

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

Example:

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

Source-Specific Handling

From your human partner
  • Trusted - implement after understanding
  • Still ask if scope unclear
  • No performative agreement
  • Skip to action or technical acknowledgment
From External Reviewers
BEFORE implementing:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

IF suggestion seems wrong:
  Push back with technical reasoning

IF can't easily verify:
  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"

IF conflicts with your human partner's prior decisions:
  Stop and discuss with your human partner first

your human partner's rule: "External feedback - be skeptical, but check carefully"

YAGNI Check for "Professional" Features

IF reviewer suggests "implementing properly":
  grep codebase for actual usage

  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
  IF used: Then implement properly

your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it."

Implementation Order

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

When To Push Back

Push back when:

  • Suggestion breaks existing functionality
  • Reviewer lacks full context
  • Violates YAGNI (unused feature)
  • Technically incorrect for this stack
  • Legacy/compatibility reasons exist
  • Conflicts with your human partner's architectural decisions

How to push back:

  • Use technical reasoning, not defensiveness
  • Ask specific questions
  • Reference working tests/code
  • Involve your human partner if architectural

Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K"

Show full SKILL.md (169 more words)Show less

Acknowledging Correct Feedback

When feedback IS correct:

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
❌ "Thanks for [anything]"
❌ ANY gratitude expression

Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.

If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.

Gracefully Correcting Your Pushback

If you pushed back and were wrong:

✅ "You were right - I checked [X] and it does [Y]. Implementing now."
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."

❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining

State the correction factually and move on.

Common Mistakes

MistakeFix
Performative agreementState requirement or just act
Blind implementationVerify against codebase first
Batch without testingOne at a time, test each
Assuming reviewer is rightCheck if breaks things
Avoiding pushbackTechnical correctness > comfort
Partial implementationClarify all items first
Can't verify, proceed anywayState limitation, ask for direction

Real Examples

Performative Agreement (Bad):

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

Technical Verification (Good):

Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"

YAGNI (Good):

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"

Unclear Item (Good):

your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."

GitHub Thread Replies

When replying to inline review comments on GitHub, reply in the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

© farm-fe, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/receiving-code-review of farm-fe/farm.

Open the folder on GitHubat commit 2000ef8

Used in at least 32 other repositories

We found 73 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 44 other GitHub owners. This page covers the copy in farm-fe/farm, which our catalogue first saw on October 7, 2026.

…and 23 more copies not listed here.

Compare with similar skills

Receiving Code Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Receiving Code Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Receiving Code Review this skillfarm-fe/farm5.6k44 repos~1.6kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k5 repos~1.1kAutomated safety check: PassMIT
Backend Code Reviewlangflow-ai/langflow156k—~3.5kAutomated safety check: NotesMIT
Understand Diff AnalysisEgonex-AI/Understand-Anything85k1 repos~1.4kAutomated safety check: PassMIT
Mole Bug Patternstw93/Mole69k—~2kAutomated safety check: PassGPL-3.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 5 repos~1.1k tokens
    DevelopmentAuto-check passed
  • Backend Code Review

    langflow-ai/langflow

    Review backend code for quality, security, maintainability, and best practices based on established checklist rules.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check: notes
  • Understand Diff Analysis

    Egonex-AI/Understand-Anything

    Reads your git changes or a pull request against a prebuilt knowledge graph of the project to explain what changed, which components are affected and what is risky.

    85k GitHub starsUsed in 1 repo~1.4k tokens
    DevelopmentAuto-check passed
  • A catalog of recurring bug shapes in the Mole Mac cleaner, used to review safety-sensitive diffs for deletion safety, unbounded commands, shell traps and weak tests.

    69k GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed
  • Backend Code Review

    langgenius/dify

    Reviews backend code under api/ for concrete, reproducible defects, routes to rule packs for architecture, schema, repositories and SQLAlchemy, and ranks findings from P0 to P3.

    158k GitHub stars~676 tokensUpdated today
    DevelopmentAuto-check passed

More from farm-fe/farm

All 20 skills in this repo
  • Using Superpowers

    farm-fe/farm

    A skill your agent uses when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

    5.6k GitHub starsUsed in 34 repos~1.4k tokens
    Auto-check passed
  • A skill your agent uses when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for…

    5.6k GitHub starsUsed in 33 repos~1.8k tokens
    Auto-check passed
  • Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook.

    5.6k GitHub starsUsed in 3 repos~1.1k tokens
    Auto-check passed
  • A skill your agent uses when completing tasks, implementing major features, or before merging to verify work meets requirements

    5.6k GitHub starsUsed in 37 repos~702 tokens
    Auto-check passed
  • A skill your agent uses when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any…

    5.6k GitHub starsUsed in 45 repos~1k tokens
    Auto-check passed
  • A universal self-improving agent that learns from ALL skill experiences.

    5.6k GitHub starsUsed in 2 repos~3.3k tokens
    Auto-check: notes

Categories

Questions about Receiving Code Review

What does Receiving Code Review do?

A skill your agent uses when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and…. Receiving Code Review is an agent skill from farm-fe/farm.

When should I use Receiving Code Review?

Receiving Code Review fits situations like: receiving code review feedback; before implementing suggestions; especially if feedback seems unclear; technically questionable - requires technical rigor and verification.

How do I install Receiving Code Review in Claude Code?

Run `npx skills add farm-fe/farm --skill receiving-code-review -a claude-code`. Or copy the skill folder (.agents/skills/receiving-code-review in farm-fe/farm) into .claude/skills/receiving-code-review in your project. Claude Code loads it when a task matches its description.

How do I install Receiving Code Review in Codex?

Run `npx skills add farm-fe/farm --skill receiving-code-review -a codex`. Or copy the skill folder (.agents/skills/receiving-code-review in farm-fe/farm) into .agents/skills/receiving-code-review in your project. Codex loads it when a task matches its description.

Can I use Receiving Code Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add farm-fe/farm --skill receiving-code-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/receiving-code-review, .gemini/skills/receiving-code-review, .github/skills/receiving-code-review and .opencode/skills/receiving-code-review in your project.

What does Receiving Code Review need to run?

Going by SKILL.md and its folder, Receiving Code Review needs the command-line tools its instructions call (gh).

Does Receiving Code Review access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Receiving Code Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Receiving Code Review use?

Receiving Code Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Receiving Code Review use?

About 1.6k tokens (SKILL.md is roughly 6.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Receiving Code Review?

Skills that share tags, products or a category with Receiving Code Review: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Code Review Checklist (shareAI-lab/learn-claude-code, 78k stars), Backend Code Review (langflow-ai/langflow, 156k stars) and Understand Diff Analysis (Egonex-AI/Understand-Anything, 85k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Receiving Code Review?

farm-fe (a GitHub organization) maintains it in farm-fe/farm, which has 5,594 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on September 22, 2026.

Source: farm-fe/farm on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.