bitranox Code Review Reception
Adapted from the superpowers plugin (MIT).
Overview
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
Pathfinder: when a review surfaces a real issue, fix it rather than defer it (no technical debt); a
valid fix that is out of scope for this change goes in its own worktree, not bolted on. See
bitranox:meta-self-improve ("Pathfinder discipline").
The Response Pattern
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Acknowledge, push back with reasoning, or SPLIT the finding (see below)
6. IMPLEMENT: One item at a time, test each
Capability check (EVALUATE). Deciding whether external review feedback is technically sound for
THIS codebase - and whether to push back - is capability-sensitive; a weaker model wrongly defers to
plausible-but-wrong feedback (or wrongly rejects good feedback). If the session is on a lesser tier,
delegate the EVALUATE judgment to a pinned sonnet/opus subagent or offer switch-model-or-continue
(the main agent cannot self-switch its model). See bitranox:process-agents-subagent-driven-development
("The session model is fixed").
Forbidden Responses
NEVER:
- "You're absolutely right!" (explicit instruction-file violation)
- "Great point!" / "Excellent feedback!" (performative)
- "Let me implement that now" (before verification)
INSTEAD:
- Restate the technical requirement
- Ask clarifying questions
- Push back with technical reasoning if wrong
- Just start working (actions > words)
Handling Unclear Feedback
IF any item is unclear:
STOP - do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
Example:
your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.
NO WRONG: Implement 1,2,3,6 now, ask about 4,5 later
OK RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
Source-Specific Handling
From your human partner
- Trusted - implement after understanding
- Still ask if scope unclear
- No performative agreement
- Skip to action or technical acknowledgment
From External Reviewers
BEFORE implementing:
1. Check: Technically correct for THIS codebase?
2. Check: Breaks existing functionality?
3. Check: Reason for current implementation?
4. Check: Works on all platforms/versions?
5. Check: Does reviewer understand full context?
IF suggestion seems wrong:
Push back with technical reasoning
IF can't easily verify:
Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF conflicts with your human partner's prior decisions:
Stop and discuss with your human partner first
your human partner's rule: "External feedback - be skeptical, but check carefully"
YAGNI Check for "Professional" Features
IF reviewer suggests "implementing properly":
grep codebase for actual usage
IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
IF used: Then implement properly
your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it."
Implementation Order
FOR multi-item feedback:
1. Clarify anything unclear FIRST
2. Then implement in this order:
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
3. Test each fix individually
4. Verify no regressions
When To Push Back
Push back when:
- Suggestion breaks existing functionality
- Reviewer lacks full context
- Violates YAGNI (unused feature)
- Technically incorrect for this stack
- Legacy/compatibility reasons exist
- Conflicts with your human partner's architectural decisions
How to push back:
- Use technical reasoning, not defensiveness
- Ask specific questions
- Reference working tests/code
- Involve your human partner if architectural
If you're uncomfortable pushing back out loud: Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
The third outcome: right defect, wrong trigger
Accept-or-push-back is a binary, and the case it loses is common enough to name: a finding whose stated TRIGGER is unreachable while the DEFECT it points at is real. It happens because a reviewer reads the file in front of them and cannot see the coupling that makes the code correct - the invariant lives somewhere else, maintained by someone else.
The shape: a reviewer flags a narrowing cast as overflow-prone and reaches for a trigger that cannot occur - a clock rate orders of magnitude below anything the hardware produces. Declining on that trigger is correct AND leaves the finding's real content untouched, because the cast is sound only while an independently maintained floor stays above what a resolution formula needs. Nothing in the file says so, nothing tests it, and the two are edited by different people.
Before splitting it, re-run the reviewer's OWN check with the real constants. An unreachable trigger often has a reachable neighbour, and the reviewer was looking in the right place with the wrong numbers: substitute what the values actually are and see where the boundary really falls. In the cast example the true limit sits one step below the cap an earlier validation already allows, so the same failure is reachable through the current configuration rather than a changed one. Skip this and you decline a finding that was live.
Then SPLIT it rather than voting on it:
- The trigger gets the ordinary treatment - accept it or decline it with the reasoning.
- The defect gets asked about separately: what invariant makes this correct, is it stated anywhere, and what happens when it moves? If the answer is an unwritten coupling, the fix is to write it down - an assertion, a test that fails when the floor drops, or a comment naming the other file.
Neither half of the binary reaches that. Declining on the unreachable trigger keeps latent fragility in the code and reads as a clean rebuttal; accepting the finding as stated logs a mechanism that cannot happen, so the next reader inherits a false explanation of why the change was made.
The tell that you are in this case: the trigger is easy to refute and refuting it feels disproportionately satisfying. That is the moment to ask what the reviewer was looking at.
Acknowledging Correct Feedback
When feedback IS correct:
OK "Fixed. [Brief description of what changed]"
OK "[specific issue] - fixed in [location]."
OK [Just fix it and show in the code]
NO "You're absolutely right!"
NO "Great point!"
NO "Thanks for catching that!"
NO "Thanks for [anything]"
NO ANY gratitude expression
Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.
If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.
Gracefully Correcting Your Pushback
If you pushed back and were wrong:
OK "You were right - I checked [X] and it does [Y]. Implementing now."
OK "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
NO Long apology
NO Defending why you pushed back
NO Over-explaining
State the correction factually and move on.
Common Mistakes
| Mistake | Fix |
|---|---|
| Performative agreement | State requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One at a time, test each |
| Assuming reviewer is right | Check if breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
| Can't verify, proceed anyway | State limitation, ask for direction |
Real Examples
Performative Agreement (Bad):
Reviewer: "Remove legacy code"
NO "You're absolutely right! Let me remove that..."
Technical Verification (Good):
Reviewer: "Remove legacy code"
OK "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
YAGNI (Good):
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
OK "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
Unclear Item (Good):
your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
OK "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
GitHub Thread Replies
When replying to inline review comments on GitHub, reply in the comment thread, not as a
top-level PR comment. gh api defaults to GET, but adding any field switches it to POST, so
the -f body= below is what makes this a reply; -X POST is explicit for readability, not
required:
gh api -X POST repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies -f body='...'
The Bottom Line
External feedback = suggestions to evaluate, not orders to follow.
Verify. Question. Then implement.
No performative agreement. Technical rigor always.