Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical verification, not performative agreement
Installs into .claude/skills of the current project.
Are you the author of Receiving Code Review?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/skeletorflet-receiving-code-review)
---
name: receiving-code-review
description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical verification, not performative agreement
---
# 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!", "Great point!", performative agreement.
INSTEAD: Restate the technical requirement, ask clarifying questions, push back with technical reasoning.
## Implementation Order
1. Clarify anything unclear FIRST
2. Then implement: Blocking issues → Simple fixes → Complex fixes
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, technically incorrect.
## The Bottom Line
External feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement.
