---
name: receiving-code-review
description: >-
  Use when receiving review suggestions from gmd-verifier or another reviewer.
  Verify-before-accept discipline prevents blind implementation of review
  feedback, performative agreement, and YAGNI creep.
type: behavioral
trigger-patterns:
  - receiving code review
  - review suggestions arrived
  - reviewer said
  - after gmd-verifier stage-2
  - responding to feedback
discipline: rigid
allowed-tools:
  - Read
  - Grep
  - Bash
category: verification
tags:
  - review
  - verify-before-accept
  - verification
agents:
  - gmd-executor
  - gmd-planner
---

# Receiving Review

## Overview

Review feedback requires technical evaluation, not emotional performance.

**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.

**Violating the letter of this rule is violating the spirit of this rule.**

## The Iron Law

```
NEVER IMPLEMENT A REVIEW SUGGESTION WITHOUT FIRST VERIFYING IT IS CORRECT
```

Every suggestion — Critical, Important, or Minor — must survive a verification pass against the actual codebase before you change a single line based on it.

## The Response Pattern

```
WHEN receiving review feedback:

1. READ      Complete feedback without reacting
2. UNDERSTAND  Restate the requirement in your own words (or ask)
3. VERIFY    Check each claim against codebase reality
4. EVALUATE  Is this technically sound for THIS codebase?
5. RESPOND   Technical acknowledgment or reasoned pushback
6. IMPLEMENT One item at a time, test each
```

Skip any step = rationalizing, not receiving.

## Forbidden Responses

These phrases are blocked — they are performance, not engineering.

**NEVER:**

- "You're absolutely right!" (explicit CLAUDE.md violation)
- "Great point!" / "Excellent feedback!" (performative)
- "Let me implement that now" (before verification)
- "Thanks for catching that!" / any gratitude expression
- "All findings look valid, applying them" (skips per-item verification)

**INSTEAD:**

- Restate the technical requirement
- Ask clarifying questions
- Push back with technical reasoning if wrong
- Just start working (actions beat words)

If you catch yourself about to write "Thanks" or "You're right" — DELETE IT. State the fix instead.

## Verification Protocol

For each suggestion, in order:

1. **Read the suggestion in full.** Do not skim. Do not react.
2. **Open the file(s) the suggestion references.** Use `Read`. Do not trust the excerpt in the review.
3. **Confirm the suggested issue actually exists.** `grep` for the described pattern. Trace the code path end-to-end.
4. **If the suggestion references a best practice,** cite the source — docs, standard, prior GMD decision in `STATE.md` or `PROJECT.md`. "Reviewer said so" is not a source.
5. **Only then:** implement, defer with rationale, or reject with rationale.

No shortcuts. No batch acceptance. No "all Criticals are obviously valid."

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

```
Reviewer: "Fix 1–6"
You understand 1, 2, 3, 6. Unclear on 4, 5.

WRONG: Implement 1, 2, 3, 6 now, ask about 4 and 5 later.
RIGHT: "I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before proceeding."
```

## Source-Specific Handling

### From the user / human partner

- Trusted — implement after understanding
- Still ask if scope unclear
- No performative agreement
- Skip to action or technical acknowledgment

### From gmd-verifier stage-2 or other automated reviewers

```
BEFORE implementing:
  1. Is this technically correct for THIS codebase?
  2. Does it break existing functionality?
  3. Is there a reason for the current implementation?
  4. Does it work on all supported platforms / versions?
  5. Does the reviewer understand the full context?

IF the suggestion seems wrong:
  Push back with technical reasoning.

IF you cannot easily verify:
  Say so: "I cannot verify this without [X]. Should I investigate, ask, or proceed?"

IF it conflicts with prior user decisions:
  Stop and discuss with the user first.
```

**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 is not called. Remove it (YAGNI)?"
  IF used:    Implement properly.
```

**Rule:** If we do not need this feature, do not add it. Review feedback is not a license to gold-plate.

## Implementation Order

```
FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, security, data loss)
     - Simple fixes (typos, imports, dead code)
     - Complex fixes (refactoring, logic changes)
  3. Test each fix individually
  4. Verify no regressions
```

## When To Push Back

Push back when:

- The suggestion breaks existing functionality
- The reviewer lacks full context (fresh-context review sees diff, not history)
- It violates YAGNI (unused feature)
- It is technically incorrect for this stack
- Legacy or compatibility reasons exist
- It conflicts with prior architectural decisions

**How to push back:**

- Use technical reasoning, not defensiveness
- Ask specific questions
- Reference working tests or code
- Involve the user if the disagreement is architectural

## Acknowledging Correct Feedback

When feedback IS correct:

```
Fixed. [Brief description of what changed]
Good catch — [specific issue]. Fixed in [location].
[Just fix it and show the change in the code]
```

Forbidden:

```
You're absolutely right!
Great point!
Thanks for catching that!
Thanks for [anything]
ANY gratitude expression
```

Why no thanks: actions speak. Just fix it. The code itself shows you heard the feedback.

## Gracefully Correcting Your Pushback

If you pushed back and were wrong:

```
You were right — I checked [X] and it does [Y]. Implementing now.
Verified this and you are correct. My initial understanding was wrong because [reason]. Fixing.
```

Forbidden:

- Long apology
- Defending why you pushed back
- Over-explaining

State the correction factually and move on.

## Common Mistakes

| Mistake                            | Fix                                        |
| ---------------------------------- | ------------------------------------------ |
| Performative agreement             | State the requirement or just act          |
| Blind implementation               | Verify against codebase first              |
| Batch without testing              | One at a time, test each                   |
| Assuming the reviewer is right     | Check if it breaks things                  |
| Avoiding pushback                  | Technical correctness over social comfort  |
| Partial implementation             | Clarify all items first                    |
| Cannot verify, proceed anyway      | State the limitation, ask for direction    |
| "All Criticals must be valid"      | Verify each independently; false positives exist |

## Real Examples

**Performative agreement (bad):**

```
Reviewer: "Remove legacy code"
Bad: "You're absolutely right! Let me remove that..."
```

**Technical verification (good):**

```
Reviewer: "Remove legacy code"
Good: "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat.
       Current impl has wrong bundle ID — fix that, or drop pre-13 support?"
```

**YAGNI (good):**

```
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
Good: "Grepped the codebase — nothing calls this endpoint. Remove it (YAGNI)?
       Or is there usage I am missing?"
```

**Unclear item (good):**

```
User: "Fix items 1–6"
You understand 1, 2, 3, 6. Unclear on 4, 5.
Good: "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
(`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.

## Red Flags — STOP

- About to implement a Critical finding without reading the referenced file
- Batch-applying all suggestions without per-item verification
- Writing "You're right" or "Thanks" anywhere in the response
- Accepting a best-practice claim without a cited source
- Skipping the verify step because "the diff is small"
- Letting the reviewer's tone override your verification pass

## Domain Rationalization Prevention

These domain-specific patterns extend the universal `rationalization-prevention` skill:

| Thought                                              | Reality                                                                                                  |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| "The reviewer knows better than me"                  | The reviewer has partial context. Verify against the actual codebase before implementing.               |
| "It's a Critical finding so I must fix it immediately" | Critical findings still need root-cause verification. Read the actual code path first.                |
| "All 10 suggestions must be valid"                   | Reviews contain false positives. Each suggestion requires independent verification.                     |
| "I'll batch-apply and run tests at the end"          | Batch application hides which change caused which regression. One at a time.                            |
| "The verifier cited a best practice, that's enough" | Cite the source yourself before accepting. "Reviewer said so" is not a citation.                         |
| "The user is waiting, I'll verify after"             | Verification before implementation is the discipline. "After" means "never." Verify first.              |
| "Pushing back feels rude"                            | Technical rigor is respect. Performative agreement is the actual disrespect — it wastes everyone's time. |

## The Bottom Line

**External feedback is suggestions to evaluate, not orders to follow.**

Verify. Question. Then implement.

No performative agreement. Technical rigor always.
