| name | receiving-code-review |
| version | 1.0.0 |
| 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 |
| dependencies | {} |
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
- READ: Complete feedback without reacting
- UNDERSTAND: Restate requirement in own words (or ask)
- VERIFY: Check against codebase reality
- EVALUATE: Technically sound for THIS codebase?
- RESPOND: Technical acknowledgment or reasoned pushback
- IMPLEMENT: One item at a time, test each
Handling Unclear Feedback
If any item is unclear: STOP - do not implement anything yet. ASK for clarification on unclear items.
Items may be related. Partial understanding = wrong implementation.
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:
- Check: Technically correct for THIS codebase?
- Check: Breaks existing functionality?
- Check: Reason for current implementation?
- Check: Works on all platforms/versions?
- Check: Does reviewer understand full context?
Implementation Order
For multi-item feedback:
- Clarify anything unclear FIRST
- Then implement in order: Blocking → Simple → Complex
- Test each fix individually
- 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
Common Mistakes
| Mistake | Fix |
|---|
| Performative agreement | State requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One at a time, test each |
| Assuming reviewer is right | Check if breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
