114 lines
3.1 KiB
Markdown
114 lines
3.1 KiB
Markdown
---
|
|
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
|
|
---
|
|
|
|
# Code Review Reception
|
|
|
|
**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
|
|
|
|
## Response Pattern
|
|
|
|
```
|
|
1. READ: Complete feedback without reacting
|
|
2. UNDERSTAND: Restate requirement (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 at a time, test each
|
|
```
|
|
|
|
## Forbidden Responses
|
|
|
|
❌ "You're absolutely right!" / "Great point!" / "Thanks for [anything]"
|
|
❌ "Let me implement that now" (before verification)
|
|
|
|
✅ Restate technical requirement
|
|
✅ Ask clarifying questions
|
|
✅ Push back with technical reasoning
|
|
✅ Just start working (actions > words)
|
|
|
|
## Handling Unclear Feedback
|
|
|
|
```
|
|
IF any item unclear:
|
|
STOP - don't implement anything
|
|
ASK for clarification on ALL unclear items
|
|
|
|
WHY: Items may be related. Partial understanding = wrong implementation.
|
|
```
|
|
|
|
## Source-Specific Handling
|
|
|
|
**Human partner:** Trusted - implement after understanding, no performative agreement
|
|
|
|
**External reviewers:**
|
|
```
|
|
BEFORE implementing:
|
|
1. Technically correct for THIS codebase?
|
|
2. Breaks existing functionality?
|
|
3. Reason for current implementation?
|
|
4. Works all platforms/versions?
|
|
|
|
IF wrong: Push back with technical reasoning
|
|
IF can't verify: State limitation, ask direction
|
|
IF conflicts with partner's decisions: Stop, discuss first
|
|
```
|
|
|
|
## YAGNI Check
|
|
|
|
```
|
|
IF reviewer suggests "implementing properly":
|
|
grep codebase for actual usage
|
|
IF unused: "This isn't called. Remove it (YAGNI)?"
|
|
IF used: Implement properly
|
|
```
|
|
|
|
## Implementation Order
|
|
|
|
```
|
|
1. Clarify unclear items FIRST
|
|
2. Implement: blocking → simple → complex
|
|
3. Test each individually
|
|
4. Verify no regressions
|
|
```
|
|
|
|
## When To Push Back
|
|
|
|
- Breaks existing functionality
|
|
- Reviewer lacks full context
|
|
- Violates YAGNI (unused feature)
|
|
- Technically incorrect for stack
|
|
- Legacy/compatibility reasons
|
|
- Conflicts with architectural decisions
|
|
|
|
**How:** Technical reasoning, specific questions, reference working tests
|
|
|
|
## Acknowledging Correct Feedback
|
|
|
|
✅ "Fixed. [Brief description]"
|
|
✅ "Good catch - [issue]. Fixed in [location]."
|
|
✅ Just fix it (actions > words)
|
|
|
|
❌ ANY gratitude or performative expression
|
|
|
|
## Correcting Wrong Pushback
|
|
|
|
✅ "You were right - checked [X], it does [Y]. Implementing."
|
|
❌ Long apology, defending, over-explaining
|
|
|
|
## Quick Reference
|
|
|
|
| Mistake | Fix |
|
|
|---------|-----|
|
|
| Performative agreement | State requirement or act |
|
|
| Blind implementation | Verify against codebase |
|
|
| Batch without testing | One at a time |
|
|
| Assuming reviewer right | Check if breaks things |
|
|
| Avoiding pushback | Technical correctness > comfort |
|
|
|
|
## Bottom Line
|
|
|
|
External feedback = suggestions to evaluate, not orders.
|
|
Verify. Question. Then implement.
|