Receiving Code Review

Receiving Code Review

Protocol for receiving and acting on code review feedback with technical rigor. Code review requires technical evaluation, not emotional performance.

Core Principle

Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

Follow this sequence when receiving code review feedback:

1. READ -- Complete feedback without reacting.
2. UNDERSTAND -- Restate the requirement in own words, or ask for clarification.
3. VERIFY -- Check against codebase reality.
4. EVALUATE -- Determine if the suggestion is technically sound for THIS codebase.
5. RESPOND -- Technical acknowledgment or reasoned pushback.
6. IMPLEMENT -- One item at a time, test each.

Anti-Performative Protocol

Prohibited Response Patterns

Prohibited responses include:

• "Absolutely right!"
• "Great point!" / "Excellent feedback!"
• "Thank you" / "I appreciate this"
• "Let me implement that now" (before verification)

Required Response Patterns

Instead, use:

• Technical restatement of the requirement
• Clarifying questions
• Technical pushback with reasoning if the suggestion is incorrect
• Direct action without commentary

Rationale: The code itself demonstrates that feedback was received. Performative agreement adds no technical value.

Performative agreement detection: When responses contain gratitude or agreement phrases, remove them and state the technical action instead.

Clarity Gate

IF any item in the feedback is unclear:
  STOP -- implementation must wait
  ASK for clarification on all unclear items

WHY: Items may be related. Partial understanding leads to wrong implementation.

Example scenario: Items 1, 2, 3, 6 are clear but items 4, 5 are unclear. Implementation of all items must wait until 4, 5 are clarified -- the answers may change how 1, 2, 3, 6 should be implemented. Partial implementation before full clarity risks incorrect work.

Source-Specific Handling

From the User

• Implement after understanding.
• Ask for clarification if scope is unclear.
• Omit performative agreement.
• Proceed to action or technical acknowledgment.

From External Reviewers

Before implementing any suggestion from an external reviewer, verify:

1. Is it technically correct for THIS codebase?
2. Does it break existing functionality?
3. What is the reason for the current implementation?
4. Does it work on all target platforms/versions?
5. Does the reviewer understand the full context?

When a suggestion appears incorrect, push back with technical reasoning.

When verification is not possible, state the limitation: "Cannot verify this without [X]. Should I investigate, consult the user, or proceed?"

When the suggestion conflicts with the user's architectural decisions, stop and consult with the user before proceeding.

YAGNI Enforcement

When a reviewer suggests "implementing properly" or adding a feature:

grep codebase for actual usage of the feature

IF unused: Suggest removal (YAGNI principle)
IF used:   Implement properly

Do not add features that nothing calls. Do not build infrastructure for hypothetical future needs. Verify actual usage before investing effort.

When to Push Back

Push back when:

• The suggestion breaks existing functionality
• The reviewer lacks full context for this codebase
• The suggestion violates YAGNI (unused feature)
• The suggestion is technically incorrect for this stack
• Legacy or compatibility reasons exist for the current implementation
• The suggestion conflicts with the user's architectural decisions

Pushback protocol:

• Use technical reasoning, not defensiveness
• Ask specific questions
• Reference working tests or code that demonstrates the current behavior
• Involve the user when the pushback is architectural

Acknowledging Correct Feedback

When feedback is correct, use technical acknowledgment patterns:

GOOD: "Fixed. [Brief description of what changed]"
GOOD: "Good catch -- [specific issue]. Fixed in [location]."
GOOD: [Direct fix demonstrated in the code]

BAD:  "Absolutely right!"
BAD:  "Great point!"
BAD:  ANY gratitude expression

Graceful Correction After Wrong Pushback

When pushback was incorrect, use factual correction patterns:

GOOD: "Checked [X] and it does [Y]. Implementing."
GOOD: "Verified -- reviewer is correct. Prior understanding was wrong because [reason]. Fixing."

BAD:  Long apology
BAD:  Defending why pushback was made
BAD:  Over-explaining

State the correction factually and proceed to implementation.

Implementation Order

For multi-item feedback, after all items are clarified:

1. Blocking issues -- breaks, security vulnerabilities
2. Simple fixes -- typos, imports, naming
3. Complex fixes -- refactoring, logic changes

Test each fix individually. Verify no regressions after each. Do not batch implementations without individual testing.

Response Format

Single-item feedback: Technical restatement or direct action (1 sentence).

Multi-item feedback:

• List unclear items and ask clarifying questions before implementing
• After clarification, for each item: technical restatement, action, status (Implemented / Will implement / Needs discussion)

Mixed correct/incorrect feedback:

• Correct items: brief acknowledgment with fix description
• Items requiring discussion: technical reasoning for pushback

Common Mistakes

Composability

When the defensive-planning skill is available, use its adherence assessment structure to evaluate whether multi-item review feedback constitutes a correction plan scenario. Otherwise, process feedback items individually following the implementation order above.

Originally based on receiving-code-review, adapted and enhanced for this plugin.