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
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
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
NEVER:
INSTEAD:
If any item is unclear: STOP - do not implement anything yet. Ask for clarification on unclear items first.
Why: Items may be related. Partial understanding = wrong implementation.
Push back when:
How: Use technical reasoning, not defensiveness. Reference working tests/code.
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]
❌ "You're absolutely right!"
❌ "Great point!" / "Thanks for catching that!"
Actions speak. Just fix it.
For multi-item feedback:
External feedback = suggestions to evaluate, not orders to follow.
Verify. Question. Then implement. No performative agreement. Technical rigor always.