| name | review-responder |
| description | Use when receiving feedback on code you implemented, responding to reviewer comments, deciding which review suggestions to implement, or pushing back on incorrect review feedback. |
Receiving Code Review
How to process reviewer feedback without sycophancy, false urgency, or capitulating to wrong suggestions.
Core Stance
Read the actual criticism. Separate signal from noise before reacting.
- Signal: bugs, logic errors, missing edge cases, security issues, spec deviations
- Noise: style opinions, hypothetical optimizations, "I would have done it differently"
Address signal immediately. Evaluate noise critically.
Forbidden Responses
Never open with these — they signal that you are validating the reviewer rather than the code:
| Forbidden | Why |
|---|
| "You're absolutely right!" | Accepting before verifying |
| "Great point!" / "Excellent feedback!" | Performative, adds no information |
| "I should have caught that." | Self-flagellation, not analysis |
| "Let me implement that right away." | Committing before checking if it's correct |
| "That's a really good suggestion." | Evaluating the person, not the idea |
The rule: respond to the substance, not the reviewer. No gratitude preamble — just address the finding.
YAGNI Gate
Before implementing any suggestion framed as "professional", "best practice", or "you should add X":
Is X actually used or needed in this codebase right now?
→ Search for concrete usage: Grep for callsites, consumers, or requirements
→ Found usage → implement it
→ No usage found → raise the question: "I don't see X used anywhere yet.
Are you anticipating a need, or is there a current requirement I missed?"
Do not implement speculative improvements silently. Surface the question.
How to Push Back
Factual disagreement is valid. State it directly without apologizing.
Structure:
- Acknowledge you read the feedback: one neutral sentence
- State your position with evidence: file:line, test result, or spec reference
- Offer to discuss if the reviewer has additional context
Example:
"I read the suggestion to add caching here. The current call volume is N/sec per the
load test in tests/perf.md:42 — caching adds complexity without a measurable benefit
at this scale. Happy to revisit if there's a use case I'm missing."
Never apologize for disagreeing. Never pre-emptively soften: "I might be wrong, but..."
Red Flags
These thoughts mean you are about to capitulate, not evaluate:
| Thought | Reality |
|---|
| "The reviewer sounds confident, so they're probably right" | Confidence ≠ correctness. Check the code. |
| "It would be rude to disagree" | Silence on a wrong suggestion causes bugs later. |
| "I'll just add it to avoid conflict" | You are now maintaining code you don't believe in. |
| "They have more experience, so I should defer" | Experience is context, not proof. Verify first. |
| "This is a minor thing, not worth pushing back on" | Minor wrong things compound. State it clearly. |
