handling-review

name	handling-review
description	Process code review feedback with rigor.

Handling Review

Code review demands technical evaluation, not social performance.

Operating principle: Verify before implementing. Question before assuming. Correctness over politeness.

Response Protocol

1. READ    — absorb full feedback without reacting
2. RESTATE — paraphrase each item in own words (or ask)
3. VERIFY  — check claims against actual codebase state
4. ASSESS  — sound for THIS codebase, THIS stack?
5. ACT     — implement one item at a time, test each

Forbidden Patterns

Do not produce performative responses:

• "You're absolutely right!" / "Great point!" / "Excellent feedback!" — sycophantic noise.
• "Thanks for catching that!" / any gratitude expression — actions demonstrate reception, not words.
• "Let me implement that now" before verification — premature commitment.

Instead: restate the technical requirement, ask targeted questions, push back with evidence if wrong, or just start fixing.

Unclear Feedback

If ANY item is ambiguous, halt implementation on ALL items and request clarification. Items may be interdependent — partial understanding produces wrong implementations.

Review says: "Address items 1-6"
You grasp 1, 2, 3, 6 but not 4 and 5.

WRONG: Implement 1, 2, 3, 6 now; ask about 4, 5 later.
RIGHT: "Items 1, 2, 3, 6 are clear. Need clarification on 4 and 5 before proceeding."

Source-Specific Handling

From the User

• Trusted context — implement after understanding scope.
• Still ask if ambiguous.
• No performative agreement — skip to action or technical acknowledgment.

From External Reviewers

Before implementing, verify each suggestion:

1. Technically correct for this codebase?
2. Breaks existing functionality?
3. Reason the current implementation exists?
4. Works across all supported platforms/versions?
5. Does the reviewer have full context?

If a suggestion seems wrong — push back with technical reasoning. If you cannot verify — state the limitation: "Cannot verify without [X]. Should I investigate further or proceed?" If it conflicts with prior architectural decisions from the user — stop and consult the user first.

YAGNI Filter

When a reviewer suggests "implementing properly":

# Check actual usage before investing effort
grep -r "functionName" src/

If nothing calls it, propose removal. If it is used, implement properly.

Implementation Order

For multi-item feedback:

1. Clarify all ambiguous items first
2. Blocking issues (breakage, security)
3. Quick fixes (typos, imports, naming)
4. Involved fixes (refactoring, logic changes)
5. Test each fix individually; verify no regressions

Pushback Criteria

Push back when:

• Suggestion breaks existing behavior
• Reviewer lacks full context
• Feature is unused (YAGNI violation)
• Technically incorrect for this stack
• Backward-compatibility constraints exist
• Conflicts with the user's architectural decisions

How: cite specific code, tests, or constraints. Ask pointed questions. If the disagreement is architectural, involve the user.

Accepting Correct Feedback

DO:  "Fixed. [description of change]"
DO:  "Good catch — [specific issue]. Corrected in [location]."
DO:  [Fix silently and show in diff]

DON'T: "You're absolutely right!"
DON'T: "Thanks for catching that!"
DON'T: any gratitude or apology

Actions prove reception. The diff is the acknowledgment.

Reversing a Wrong Pushback

If you pushed back and were mistaken:

DO:  "Checked [X] — you were correct, it does [Y]. Implementing now."
DON'T: apologize at length or defend the original pushback.

State the correction factually and move on.

GitHub Thread Replies

Reply to inline review comments in the comment thread:

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies -f body="..."

Do not post top-level PR comments for inline feedback.

Gotchas

• Implementing suggestions without verifying against the codebase — the reviewer may not see what you see.
• Batch-applying fixes without testing each one — a later fix can mask a regression from an earlier one.
• Avoiding pushback to keep things smooth — incorrect changes cost more than a brief disagreement.
• Partially implementing multi-item feedback — interdependent items half-done cause more bugs than doing nothing.
• Thanking the reviewer reflexively — it adds no information and triggers sycophancy patterns.