receiving-code-review
Scannednpx machina-cli add skill Joncik91/ucai/receiving-code-review --openclawReceiving 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. |
Source
git clone https://github.com/Joncik91/ucai/blob/main/skills/receiving-code-review/SKILL.mdView on GitHub Overview
Receiving Code Review teaches you to parse reviewer feedback without sycophancy, separating signal from noise. It guides you to address the signal—bugs, logic errors, missing edge cases, security issues, and spec deviations—while critically evaluating noise such as style opinions or hypothetical optimizations. It also provides a disciplined approach to push back on incorrect feedback and decide which suggestions to implement.
How This Skill Works
Triage feedback by reading the actual criticism and separating signal from noise before reacting. Address signal immediately and surface questions when you don’t see concrete usage for a suggestion. If you disagree, push back using a structured approach (acknowledge, present evidence with file:line or tests, and offer to discuss) and apply the YAGNI gate before implementing any change.
When to Use It
- You’ve received feedback on code you implemented.
- You’re responding to reviewer comments that are unclear or conflicting.
- You need to decide which review suggestions to implement.
- You’re pushing back on a suggestion you believe is incorrect or unnecessary.
- You want to surface usage, requirements, or edge cases before applying changes.
Quick Start
- Step 1: Read the feedback and separate signal (bugs, edge cases, spec issues) from noise (style opinions, hypothetical optimizations).
- Step 2: Decide action using the YAGNI gate and current usage: implement, surface questions, or push back with evidence.
- Step 3: If pushing back, respond using the structure: acknowledge, state your evidence (file:line, tests, spec), and offer to discuss.
Best Practices
- Treat signal, not style opinions, as the driver of changes.
- Don’t open with praise or gratitude; address the substance first.
- Use the push-back structure: acknowledge; cite file:line, test results, or spec; invite discussion.
- Apply the YAGNI gate to confirm changes are actually used or needed.
- Reference concrete evidence when adopting or rejecting feedback (tests, specs, usage references).
Example Use Cases
- Caching suggestion: 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.
- Refactor idea: The proposed refactor would touch module X and risks breaking tests Y; the spec requires Z, which is preserved by the current structure.
- Style-only suggestion: This change improves readability but doesn’t affect correctness or usage; I can apply it if there’s a clear need for consistency in this part of the codebase.
- YAGNI question: I don’t see X used anywhere yet. Are you anticipating a need, or is there a current requirement I missed?
- Discussion plan: If there’s disagreement on this point, I’d prefer to discuss in a follow-up meeting with the relevant stakeholders to align on usage and requirements.
