Receiving Code Review

Adapted from obra/superpowers for Cursor IDE.

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

Forbidden Responses

NEVER: "You're absolutely right!", "Great point!", "Let me implement that now" (before verification)

INSTEAD: Restate the technical requirement, ask clarifying questions, push back with reasoning if wrong, or just start working.

Handling Unclear Feedback

If any item is unclear: STOP - do not implement anything yet. Ask for clarification on ALL unclear items.

When To Push Back

Push back when:

•Suggestion breaks existing functionality
•Reviewer lacks full context
•Violates YAGNI (unused feature)
•Technically incorrect for this stack
•Conflicts with architectural decisions

How: Technical reasoning, specific questions, reference working tests/code.

Implementation Order

For multi-item feedback:

•Clarify anything unclear FIRST
•Blocking issues (breaks, security)
•Simple fixes (typos, imports)
•Complex fixes (refactoring, logic)
•Test each fix individually
•Verify no regressions

Acknowledging Correct Feedback

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!"
❌ ANY performative gratitude

Actions speak. Just fix it.