Guides responding to code review feedback: distinguish signal from noise, avoid sycophancy, apply YAGNI checks, push back factually with evidence.
From ucainpx claudepluginhub joncik91/ucai --plugin ucaiThis skill uses the workspace's default tool permissions.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
How to process reviewer feedback without sycophancy, false urgency, or capitulating to wrong suggestions.
Read the actual criticism. Separate signal from noise before reacting.
Address signal immediately. Evaluate noise critically.
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.
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.
Factual disagreement is valid. State it directly without apologizing.
Structure:
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..."
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. |