# Process Review Receiving Code Review

> Use when receiving code review feedback or PR review comments, before implementing suggestions - especially when a suggestion seems unclear, technically questionable, or breaks existing behavior, or when you feel the urge to reply "You're absolutely right"

- Skill: `bitranox/process-review-receiving-code-review` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add bitranox/process-review-receiving-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bitranox/process-review-receiving-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bitranox (https://skillmd.com/u/bitranox)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bitranox/process-review-receiving-code-review

---


# 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:

```bash
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.