receiving-code-review
Evaluate code review feedback with technical rigor before implementing, avoiding performative agreement and blind implementation.
- Verify feedback against actual codebase behavior, test coverage, and architectural context before proceeding
- Ask for clarification on unclear items before implementing anything; partial understanding leads to wrong fixes
- Push back on suggestions that break functionality, lack context, violate YAGNI, or conflict with established decisions using technical reasoning
- Implement multi-item feedback in priority order (blocking issues first), testing each fix individually to catch regressions
- Acknowledge correct feedback through action and specific description of what changed, not gratitude expressions
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
More from obra/superpowers
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
152.3Kusing-superpowers
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
92.7Ksystematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
92.0Kwriting-plans
Use when you have a spec or requirements for a multi-step task, before touching code
91.3Krequesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
80.4Ktest-driven-development
Use when implementing any feature or bugfix, before writing implementation code
79.8K