# Receiving Code Review

> Use when you receive review feedback on your own code or changes. Triggers on: 'reviewer said', 'PR feedback', 'review comments', 'address the feedback', 'fix the review'. Classifies feedback into must-fix / optional / reject-with-reason.

- Skill: `yanacuti1121/receiving-code-review` (Agent Skill)
- Install (CLI): `npx skillmds add yanacuti1121/receiving-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yanacuti1121/receiving-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yanacuti1121 (https://skillmd.com/u/yanacuti1121)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/yanacuti1121/receiving-code-review

---


# Receiving Code Review Skill

Review feedback is not a to-do list to blindly execute.
Classify each item, act on what matters, and justify what you decline.

## When to use this skill

- You receive review comments on a PR or diff you wrote
- Someone flags issues in code you produced
- User asks you to "address the feedback" or "fix the review comments"

## Step 1 — Read all feedback before acting

Do not start editing on the first comment. Read everything first.
Build a complete picture of what the reviewer is asking.

## Step 2 — Classify each comment

| Category | Definition | Action |
|----------|-----------|--------|
| **Must fix** | Correctness bug, security issue, data loss risk | Fix immediately |
| **Should fix** | Real concern, reasonable improvement | Fix unless there's a strong reason not to |
| **Optional** | Style, preference, minor nitpick | Fix if fast (<5 min), otherwise note and move on |
| **Reject** | Disagrees with an intentional design choice | Respond with reasoning, do not change code |

## Step 3 — Act

For each **must-fix** and **should-fix**:
1. Make the change
2. Confirm the fix with evidence (diff or test output)
3. Reply to the reviewer with what you changed

For each **optional**:
- If fast: do it
- If not: "Noted, deferring — [why]"

For each **reject**:
- Write a clear explanation: "This is intentional because [X]. I'm keeping it as is."
- Do not change the code under social pressure alone

## Step 4 — Do not over-accept

Signs you are over-accepting:
- Applying every comment without reading context
- Changing code you are confident was correct
- Letting the reviewer's style override your project's conventions

If a comment would break something or contradict a documented decision: push back.

## Response format (for PR reply)

```markdown
Thanks for the review. Here's what I did:

**Fixed:**
- [comment ref] [what I changed] — [file:line]

**Deferred:**
- [comment ref] [why — e.g. out of scope, separate ticket]

**Not changing:**
- [comment ref] [reason — e.g. this is intentional because X]
```

## After applying changes

Run tests and use `verify-before-done` before marking the PR ready again.