When receiving code review feedback:

1. Read: Read the feedback completely, don't rush to react
2. Understand: Paraphrase the requirements in your own words (or ask questions)
3. Verify: Check against the actual situation of the codebase
4. Evaluate: Is this technically reasonable for this codebase?
5. Respond: Provide technical confirmation or well-founded refutation
6. Implement: Do one item at a time, test individually

If any item is unclear:
  Stop—don't implement anything yet
  Ask for clarification on the unclear items

Why: Items may be interconnected. Partial understanding = incorrect implementation.

Partner: "Fix items 1-6"
You understand 1, 2, 3, 6. Unsure about 4, 5.

❌ Wrong approach: Implement 1, 2, 3, 6 first, ask about 4,5 later
✅ Correct approach: "I understand items 1, 2, 3, 6. I need clarification on items 4 and 5 before proceeding."

Before implementing:
  1. Check: Is this technically correct for this codebase?
  2. Check: Will it break existing functionality?
  3. Check: Is there a reason the current implementation is written this way?
  4. Check: Does it work across all platforms/versions?
  5. Check: Does the reviewer have full context?

If the suggestion seems incorrect:
  Refute with technical reasons

If it cannot be easily verified:
  State the situation: "I cannot verify this without [X]. Should I [investigate/ask/proceed with other tasks]?"

If it conflicts with previous decisions from your partner:
  Stop and discuss with your partner first

If the reviewer suggests "implementing it formally":
  Grep the codebase for actual usage

  If no one uses it: "This interface is not being called. Should we delete it (YAGNI)?"
  If someone uses it: Implement it formally

For feedback with multiple items:
  1. First clarify all unclear items
  2. Then implement in this order:
     - Blocking issues (crashes, security)
     - Simple fixes (spelling, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

✅ "Fixed. [Briefly describe what was changed]"
✅ "Good catch—[specific issue]. Fixed at [location]."
✅ [Fix directly and reflect it in the code]

❌ "You're absolutely right!"
❌ "Good point!"
❌ "Thanks for catching this!"
❌ "Thank you for [anything]"
❌ Any expression of gratitude

✅ "You're right—I checked [X], and indeed [Y]. Implementing now."
✅ "After verification, I confirm you're correct. My initial understanding was wrong because [reason]. Fixing now."

❌ Long apologies
❌ Defend your refutation
❌ Over-explain

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me delete it..."

Reviewer: "Remove legacy code"
✅ "Checked... The build target is 10.15+, and this API requires 13+. Backward compatibility requires keeping the legacy code. The current implementation has an incorrect bundle ID—should we fix it or drop pre-13 support?"

Reviewer: "Implement comprehensive metrics tracking, including database, date filtering, CSV export"
✅ "Grep'd the codebase—this interface isn't called anywhere. Should we delete it (YAGNI)? Or is there a call I'm missing?"

Partner: "Fix items 1-6"
You understand 1, 2, 3, 6. Unsure about 4, 5.
✅ "I understand items 1, 2, 3, 6. I need clarification on items 4 and 5 before proceeding."