| name | receiving-code-review |
| description | Use when receiving code review feedback before implementing suggestions, especially when feedback is ambiguous or technically questionable. Enforces technical rigor and verification instead of performative agreement or blind implementation. |
| compatibility | ["Python 3.11+ standard library"] |
Receiving Code Review
Contents
Overview
A code review demands technical evaluation, not an emotional performance.
○ Core principles
- Verify before implementing.
- Ask before assuming.
- Technical accuracy over social comfort.
Response Pattern
When you receive code review feedback:
1. Read: read all the feedback without reacting
2. Understand: restate the requirement in your own words (or ask)
3. Verify: check it against the reality of the codebase
4. Evaluate: is it technically sound for this codebase?
5. Respond: technical acknowledgment or a grounded rebuttal
6. Implement: one item at a time, testing each one
Forbidden Responses
□ Never do this
- "Absolutely right!" (an explicit violation of CLAUDE.md)
- "Good point!" / "Great feedback!" (performative)
- "I'll implement it now" (before verifying)
□ Instead
- Restate the technical requirement
- Ask a clarifying question
- Rebut with technical grounds if it is wrong
- Just start the work (action over words)
Handling Ambiguous Feedback
If any item is ambiguous:
Stop. Do not implement anything yet.
Request clarification on the ambiguous item.
Reason: items can be related to each other. Partial understanding = wrong implementation.
Example
User: "Fix 1 through 6"
You understand 1, 2, 3, and 6. Items 4 and 5 are ambiguous.
❌ Implement 1, 2, 3, 6 first and ask about 4, 5 later
✅ "I understand 1, 2, 3, and 6. I need clarification on 4 and 5 before proceeding."
Handling by Source
From the User
- Trusted. Implement after understanding.
- If the scope is ambiguous, still ask.
- No performative agreement.
- Go straight to action or give a technical acknowledgment.
From an External Reviewer
Before implementing:
1. Check: is it technically correct for this codebase?
2. Check: does it break existing functionality?
3. Check: is there a reason for the current implementation?
4. Check: does it work on all platforms and versions?
5. Check: does the reviewer understand the full context?
If the suggestion looks wrong:
Rebut with technical grounds.
If you cannot verify it easily:
Say so: "I cannot verify this without X. Which do you want: [investigate / ask / proceed]?"
If it conflicts with the user's earlier decision:
Stop and discuss with the user first.
○ User rule: "External feedback. Be skeptical but check carefully."
YAGNI (You Aren't Gonna Need It) Check for "Professional" Features
When a reviewer suggests "implement it properly":
grep the codebase for the actual usage.
Not used: "This endpoint is never called. Remove it (YAGNI)?"
Used: then implement it properly.
○ User rule: "Both you and the reviewer report to me. Do not add features that are not needed."
Implementation Order
Multi-item feedback:
1. Clarify the ambiguous ones first.
2. Implement in this order:
- Blocking issues (breakage, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
3. Test each fix individually.
4. Verify there is no regression.
When to Rebut
Rebut in the following cases.
- The suggestion breaks existing functionality.
- The reviewer lacks the full context.
- A YAGNI violation (a feature that is not used).
- It is technically inaccurate for this stack.
- A legacy or compatibility reason exists.
- It conflicts with the user's architecture decision.
□ How to rebut
- With technical grounds, not defensively.
- Specific questions.
- Reference a working test or working code.
- Bring in the user if it is an architecture matter.
○ If rebuttal feels awkward, slow down and write the technical evidence first.
Acknowledging Correct Feedback
When the feedback is right
✅ "Fixed. [short note on what changed]"
✅ "Good catch. [specific issue]. Fixed at [location]."
✅ [just fix it and show it in code]
❌ "Absolutely right!"
❌ "Good point!"
❌ "Thanks for catching that!"
❌ "Thanks for [anything]"
❌ Any kind of thank-you expression
○ Why thank-yous are forbidden: action speaks. Just fix it. The code itself shows that the feedback was heard.
○ If you catch yourself about to write "thanks": delete it. State the fact of the fix instead.
Gracefully Correcting a Rebuttal
When you rebutted but were wrong
✅ "You were right. I checked [X] and it turned out to be [Y]. Implementing now."
✅ "After verifying, you are right. My initial understanding was wrong, because [reason]. Fixing now."
❌ A long apology
❌ Defending why you rebutted
❌ Over-explaining
Correct the record factually and proceed.
Common Mistakes
| Mistake | Fix |
|---|
| Performative agreement | State the requirement or just act |
| Blind implementation | Check against the codebase first |
| Batch processing then testing | One at a time, test each one |
| Assuming the reviewer is right | Check whether it breaks |
| Avoiding a rebuttal | Technical accuracy > comfort |
| Partial implementation | Clarify all items first |
| Proceeding when you cannot verify | State the limit, request direction |
Examples
□ Performative agreement (bad)
Reviewer: "Remove the legacy code"
❌ "Absolutely right! I'll remove it..."
□ Technical verification (good)
Reviewer: "Remove the legacy code"
✅ "Checking... the build target is 10.15+, and this API needs 13+. The legacy code is needed for backward compatibility. The current implementation has the wrong bundle ID. Fix that, or drop pre-13 support?"
□ YAGNI (good)
Reviewer: "Implement proper metrics tracking with a DB, date filters, and CSV export"
✅ "I grepped the codebase. This endpoint has no callers. Remove it (YAGNI)? Or did I miss a usage?"
□ Ambiguous item (good)
User: "Fix 1 through 6"
You understand 1, 2, 3, 6 and 4, 5 are ambiguous.
✅ "I understand 1, 2, 3, 6. I need clarification on 4 and 5 before implementing."
Replying on a GitHub Thread
When you reply to a GitHub inline review comment, reply on the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies). Do not reply as a top-level PR comment.
Conclusion
External feedback = a suggestion to evaluate, not a command to obey.
Verify. Doubt. Only then implement.
No performative agreement. Technical rigor always.
