3.1 KiB
name, description
| name | description |
|---|---|
| receiving-code-review | 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.