Code Review Reception

Wrong skill? Reviewing someone's PR → providing-code-review. Sending to reviewer agent → code-review. Acting as reviewer → code-review-respond.

Strategy before execution

Before every automated review or test/check pass, resolve a snapshot-bound REUSE, WAIT, RUN_MINIMAL, REVIEW_REQUIRED or STOP decision at its supported execution/dispatch boundary. Reuse valid coverage or join its active producer. Missing/stale decisions refuse; unknown coverage stays conservative. No model calls or recursive checks inside strategy. Status/HEAD changes, clean reviews and score targets alone never justify another expensive pass.

When to Use

• After receiving PR/MR review comments from any reviewer
• When review feedback seems unclear, contradictory, or technically questionable
• Before implementing any suggested changes from code review

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

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time; strategy selects affected coverage and reuses valid prior checks
7. SYSTEMIC CHECK: Search for OTHER instances (see below)

🚨 Systemic Verification (MANDATORY)

After implementing all feedback items, BEFORE claiming done: The reviewer's feedback identifies SYMPTOMS. Your job is to fix the DISEASE, not just the symptoms.

AFTER implementing all items:

1. EXTRACT the underlying principle/goal — e.g., "Remove all silent defaults" not "fix these 3 lines"
2. SEARCH for OTHER instances of the same pattern: grep -rn "pattern" --include="*.ts" .
3. FIX additional instances within the authorized boundary; report unrelated findings without expanding scope
4. VERIFY the GOAL is achieved, not just the checklist

Why This Exists

Common failure pattern:

• Reviewer identified 3 instances of a problematic pattern
• Agent fixed all 3 listed items ✓
• Agent claimed "Done!" ✓
• A 4th instance existed that wasn't in the reviewer's list
• Only caught by adversarial self-review asking "are there OTHER places?"

Root cause: Treated feedback as finite checklist, not systemic issue.

The Gate

BEFORE claiming code review changes are complete:

☐ Did I extract the underlying GOAL from the feedback? ☐ Did I search for OTHER instances of the same pattern? ☐ Did I verify the GOAL is achieved (not just items checked off)? ☐ Would a harsh reviewer find more instances I missed?

If ANY box is unchecked → you're not done

Example

Reviewer says: "Remove hardcoded defaults at lines 96, 127, and 81"

❌ WRONG: Fix lines 96, 127, 81 → "Done!"

✅ RIGHT: 1. Goal: "No hardcoded defaults for userRole" 2. Search: grep -rn "userRole.||.'guest'" . 3. Find: Lines 96, 127, 81 (listed) + line 2199 (NOT listed) 4. Fix ALL four 5. Verify: grep returns nothing 6. "Done - fixed 4 instances (3 listed + 1 additional in data import)"

Response Rules

Never performative ("You're absolutely right!", "Great point!"). Instead: restate requirement, ask questions, push back with reasoning, or just fix it.

Correct feedback: "Fixed. [what changed]" or "Good catch — [issue]. Fixed in [location]." or just fix and show.

Unclear feedback: STOP — clarify ALL items before implementing. Partial understanding = wrong implementation.

Source-Specific Handling

Human partner: Trusted — implement after understanding. Still ask if scope unclear. External reviewers: Check: correct for THIS codebase? Breaks functionality? Reason for current approach? Push back if wrong. Conflicts with partner's decisions → discuss with partner first.

Implementation Order

1. Clarify unclear items FIRST
2. Blocking (breaks, security) → simple (typos, imports) → complex (refactoring)
3. Test each individually → verify no regressions → SYSTEMIC CHECK

Push Back When

Breaks functionality · reviewer lacks context · YAGNI · technically wrong · legacy reasons · conflicts with partner's architecture.

Common Mistakes

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement. Then verify the GOAL, not just the checklist.

No performative agreement. Technical rigor always.

Anti-Patterns

Failure Modes

• Blind implementation: Implementing every suggestion without evaluating whether it's correct for THIS codebase
• Performative agreement: Saying "great catch!" instead of technically verifying the feedback is accurate
• Fixing symptoms only: Addressing the specific line a reviewer flagged without checking for the same pattern elsewhere

Example: Systemic Check After Review

# Reviewer says: "This null check is missing"
# WRONG: Add null check to just this line
# RIGHT: Search for ALL similar patterns in the codebase
grep -rn "\.getData()" --include="*.ts" src/ | grep -v "?." | grep -v "!= null"
# Then fix ALL instances, not just the one the reviewer spotted

Companion Skills

• providing-code-review: How the reviewer should structure feedback
• inter-agent-review-protocol: File-protocol review (may generate the feedback you're processing)
• systematic-debugging: For investigating complex review findings
• code-review-respond: Review response workflow
• code-review-battery: Multi-reviewer orchestration