About

Imported from shipshitdev/skills (skills/receiving-code-review/SKILL.md). Install upstream with npx skills add shipshitdev/skills --skill receiving-code-review. Copyright stays with the author.

Receiving Code Review

Name: receiving-code-review
Author: shipshitdev

Core Principle

Code review requires technical evaluation, not emotional performance.

Verify before implementing. Ask before assuming. Technical correctness over social comfort.

Contract

Inputs:

Incoming review feedback (PR comments, verbal review notes) and the codebase the feedback refers to.

Outputs:

A per-point technical acknowledgment or reasoned pushback, plus an action plan for the changes that survive evaluation.

Creates/Modifies:

None directly. This skill produces responses; code edits happen through other skills.

External Side Effects:

Read-only git / gh invocations to verify claims against the codebase.

Confirmation Required:

None. All output is advisory.

Delegates To:

github-address-comments for posting the responses back to a PR.
code-review for a fresh review pass once changes land.

Response Pattern

WHEN receiving code review feedback:

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

Forbidden Responses

NEVER say:

"You're absolutely right!"
"Great point!" / "Excellent feedback!"
"Let me implement that now" (before verification)
Any expression of gratitude ("Thanks for catching that!", "Thanks for [anything]")

INSTEAD:

Restate the technical requirement
Ask clarifying questions
Push back with technical reasoning if the suggestion is wrong
Just start working — actions speak louder than words

Handling Unclear Feedback

IF any item is unclear:
  STOP — do not implement anything yet
  ASK for clarification on all unclear items before proceeding

WHY: Items may be related. Partial understanding leads to wrong implementation.

Example:

Reviewer: "Fix items 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."

Evaluating Feedback by Source

From the codebase owner / requester

Trusted — implement after understanding
Still ask if scope is unclear
No performative agreement
Skip to action or technical acknowledgment

From external reviewers

BEFORE implementing:
  1. Check: Is this technically correct for THIS codebase?
  2. Check: Would this break existing functionality?
  3. Check: Is there a reason the current implementation exists?
  4. Check: Does this work on all required platforms/versions?
  5. Check: Does the reviewer understand the full context?

IF the suggestion seems wrong:
  Push back with technical reasoning

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

IF the suggestion conflicts with prior architectural decisions:
  Stop and surface the conflict before implementing

YAGNI Check for "Implement Properly" Suggestions

IF a reviewer suggests adding or expanding a feature "properly":
  grep the codebase for actual usage

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

Reviewers often suggest improvements to code that isn't wired up anywhere. Verify usage before expanding scope.

Implementation Order

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

When to Push Back

Push back when the suggestion:

Breaks existing functionality
Assumes context the reviewer doesn't have
Violates YAGNI (adds unused code)
Is technically incorrect for this stack
Conflicts with legacy or compatibility requirements
Contradicts established architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions that surface the gap
Reference existing tests or working code
Escalate to the codebase owner if the disagreement is architectural

Acknowledging Correct Feedback

When feedback IS correct:

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and let the diff speak]

❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
❌ Any gratitude expression

The fix is the acknowledgment. State what changed and move on.

Gracefully Correcting Your Own 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

Mistake	Fix
Performative agreement	State the requirement or just act
Blind implementation	Verify against the codebase first
Implementing in batch without testing	One item at a time, test each
Assuming the reviewer is right	Check whether the suggestion breaks things
Avoiding pushback	Technical correctness over social comfort
Partial implementation	Clarify all items before starting
Cannot verify — proceed anyway	State the limitation, ask for direction

Real Examples

Performative agreement (bad):

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

Technical verification (good):

Reviewer: "Remove the legacy code"
✅ "Checking... build target is 10.15+, this API requires 13+.
   Removing it drops pre-13 support. Is that intentional,
   or should I gate it behind a version check instead?"

YAGNI check (good):

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

Unclear item (good):

Reviewer: "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 PR Comment Replies

When responding to inline review comments on GitHub, reply in the comment thread — not as a top-level PR comment:

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies \
  -f body="[your response]"

Reviewer feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement. No performative agreement. Technical rigor always.

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml

targets:
  - https://api.opensmartroute.ai/api/v1/registry/shipshitdev-skills-receiving-code-review/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

shipshitdev-skills-receiving-code-review.ocm.jsonjson

{
  "ocm": "1",
  "id": "shipshitdev-skills-receiving-code-review",
  "kind": "skill",
  "name": "receiving-code-review",
  "description": "Evaluate incoming code-review feedback with technical rigor before implementing any change. Verify each point against the codebase, push back with reasoning when the reviewer is wrong, and never perform empty agreement. Use when you receive a review, before touching any code, especially when feedback seems unclear or technically questionable.",
  "publisher": "shipshitdev",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "coding"
    ],
    "tags": [
      "skill-md",
      "code-review",
      "feedback",
      "review-response",
      "pushback",
      "verification",
      "skills-sh"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "Evaluate incoming code-review feedback with technical rigor before implementing any change. Verify each point against the codebase, push back with reasoning when the reviewer is wrong, and never perform empty agreement. Use when you receive a review, before touching any code, especially when feedback seems unclear or technically questionable."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "skills.sh",
      "repository": "https://github.com/shipshitdev/skills",
      "path": "skills/receiving-code-review/SKILL.md",
      "ref": "HEAD",
      "url": "https://github.com/shipshitdev/skills/blob/HEAD/skills/receiving-code-review/SKILL.md",
      "key": "shipshitdev/skills/skills/receiving-code-review/SKILL.md"
    },
    "allowed_tools": [
      "Bash(git",
      "*)",
      "Bash(gh",
      "*)"
    ]
  },
  "instructions": "# Receiving Code Review\n\n## Core Principle\n\nCode review requires technical evaluation, not emotional performance.\n\n**Verify before implementing. Ask before assuming. Technical correctness over social comfort.**\n\n## Contract\n\nInputs:\n\n- Incoming review feedback (PR comments, verbal review notes) and the codebase\n  the feedback refers to.\n\nOutputs:\n\n- A per-point technical acknowledgment or reasoned pushback, plus an action\n  plan for the changes that survive evaluation.\n\nCreates/Modifies:\n\n- None directly. This skill produces responses; code edits happen through other\n  skills.\n\nExternal Side E",
  "cost": {
    "context_tokens": 1722
  }
}

Fetch it by URL: GET /api/v1/registry/shipshitdev-skills-receiving-code-review/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.