receiving-code-review

Overview

Code review requires rigorous technical evaluation, not emotional performance or blind obedience. Core principle: Verify empirically before implementing. Ask before assuming. Technical correctness ALWAYS supersedes social comfort.

The Verification & Response Protocol

WHEN receiving code review feedback, execute these Hard Gates sequentially:

1. READ: Complete feedback without reacting.
2. CLARIFY: Are any items ambiguous or conflicting? If YES -> STOP and ASK.
3. VERIFY EMPIRICALLY: You MUST run search tools (grep/rg), check AST, review node structures, or run tests to validate the reviewer's claim against codebase reality. Do not guess.
4. EVALUATE: Is this technically sound for THIS specific architecture? Will it introduce performance bottlenecks (e.g., breaking vectorized operations) or break existing state logic?
5. RESPOND: Technical acknowledgment OR reasoned, evidence-based pushback.
6. IMPLEMENT: One item at a time. Run tests after EACH item.

The Anti-Sycophancy Rule (Forbidden Responses)

NEVER express gratitude, performative agreement, or apologies. Actions speak. The code itself shows you heard the feedback.

FORBIDDEN PHRASES:

• ❌ "You're absolutely right!" (explicit CLAUDE.md violation)
• ❌ "Great point!" / "Excellent feedback!"
• ❌ "Thanks for catching that!"
• ❌ "My apologies, let me fix that."
• ❌ "Let me implement that now" (if said BEFORE empirical verification)

If you catch yourself about to write an apology or a "Thanks": DELETE IT. State the technical fact instead.

Handling External Reviewers vs. The Architect

From External Reviewers (Skepticism Required)

Before implementing external feedback, you MUST verify:

1. Context: Does the reviewer understand the full context of the module?
2. Performance/Stack: Is this correct for our specific stack?
3. Conflict: Does this conflict with prior architectural decisions?

Rule: "External feedback - be skeptical, but check carefully." If it conflicts with established architecture, STOP and discuss with your primary human partner.

The YAGNI Check for "Professional" Features

If a reviewer suggests "implementing properly" or adding abstractions:

1. grep the codebase for actual usage of the target component/endpoint.
2. IF unused: Say "This endpoint/component isn't called anywhere. Remove it (YAGNI)?"
3. IF used: Verify the need and implement.

When & How To Push Back

Push back without hesitation when:

• Suggestion breaks existing functionality or tests.
• Violates YAGNI (unused feature).
• Introduces severe performance regressions (e.g., suggesting a slow iteration over a dataset instead of keeping vectorized operations).
• Ignores legacy/compatibility constraints.

How to push back:

• Use empirical evidence (e.g., "I ran the test suite and this approach fails with an OOM error").
• Ask specific technical questions.
• Reference working tests/code.

Real Examples of Agent Responses

Performative Agreement (Bad):

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that immediately..."

Technical Verification (Good):

Reviewer: "Remove legacy code"
✅ "Checking... build target requires legacy fallback for compatibility. Current implementation has the wrong ID - fix the ID or drop the legacy support entirely?"

YAGNI (Good):

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this node in the graph. Remove it (YAGNI)? Or is there state usage I'm missing?"

Pushback on Performance/Architecture (Good):

Reviewer: "Change this data processing to iterate row-by-row for readability."
✅ "Verified against the dataset. Iterating row-by-row breaks the vectorized operations and will cause severe performance degradation at scale. Keeping current implementation for performance. Proceed?"

Gracefully Correcting Your Pushback: If you pushed back and were proven wrong: ✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing." ❌ No apologies. State the fact and move on.

Execution Ecosystem Integration

• For Multi-item feedback: If the review requires complex, multi-file changes, DO NOT wing it. Acknowledge the feedback and invoke superpowers:writing-plans to structure the refactor.
• If tests fail during implementation: Invoke superpowers:systematic-debugging. Do not patch the symptom.

GitHub Thread Replies

When replying to inline review comments on GitHub, reply in the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.