ia-receiving-code-reviewlisted

# Receiving Code Review ## Core Principle Verify before implementing. Technical correctness matters more than social comfort. A reviewer can be wrong -- blindly implementing bad suggestions creates bugs. ## Response Pattern For each piece of feedback, follow this sequence: **0. Prior feedback check (re-reviews only)** -- if this is not the first review round, check whether previously flagged issues were addressed before processing new comments. Compare the current diff against prior review threads (`gh api repos/{owner}/{repo}/pulls/{pr}/comments`). Surface any that were ignored or only partially fixed -- these take priority over new feedback. 1. **Read** -- Understand what's being suggested and why 2. **Verify** -- Is the suggestion technically correct for THIS codebase? 3. **Evaluate** -- Does it improve the code, or is it preference/style? 4. **Respond** -- Agree with evidence, disagree with evidence, or ask for clarification 5. **Implement** -- Only after verification confirms the suggestion is correct Triage all feedback first (see Implementation Order below), then implement one item at a time. Don't batch-implement everything at once. ## Handling Unclear Feedback When feedback is ambiguous or incomplete: - **Stop** -- do not implement anything unclear - Clarify ALL unclear items before implementing ANY of them (they may be related) - Ask specific questions: "Are you suggesting X or Y?" not "Can you elaborate?" - If the reviewer's intent is clear but the techni