yuchi-chang Receiving Review Feedback
Feedback is input to evaluate, not orders to execute. Verify before implementing; technical correctness over social comfort.
The pattern
- Read all the feedback before reacting to any of it.
- Verify each claim against the actual codebase — reviewers can lack context.
- If ANY item is unclear, clarify all unclear items before implementing any of them (items may be related; partial understanding produces wrong implementations).
- Implement in order: blocking issues → simple fixes → complex fixes. Test each one separately.
No performative agreement
Never "You're absolutely right!" / "Great point!". Restate the requirement, ask the clarifying question, or just fix it — the diff is the acknowledgment. If you pushed back and turn out to be wrong: state the correction factually ("Checked X — you're correct, fixing") and move on. No apology spiral.
When to push back
- The suggestion breaks existing functionality or violates platform/version constraints
- The reviewer lacks context the current code depends on
- YAGNI: asked to "implement X properly" → grep for actual usage first; if nothing calls it, propose removing it instead
- It conflicts with an architectural decision the user already made → surface the conflict, don't silently comply
Push back with evidence (code, tests, grep output), not defensiveness.
GitHub
Reply to inline review comments in their thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.