receiving-code-review · Receiving Code Review
A technical process for handling code-review feedback: verify before implementing — no performative agreement, no blind compliance.
Read the full feedback, restate the requirement in your own words, verify against the codebase, assess whether it fits this project — then technically acknowledge or push back with reasoning. Unclear feedback means stop and clarify before touching anything; multi-item feedback is clarified first, then implemented item by item (blockers → simple fixes → complex fixes), each tested. External reviewer input gets skeptical-but-careful treatment, argued with facts and tests.
Example invocation: "Walk me through this review feedback — what should actually change?"
Full brief
Positioning
receiving-code-review is a review-handling method: technical evaluation, not emotional performance. It defines the full process between "review received" and "code changed".
Core capabilities
- Six-step response: read (full feedback) → understand (restate) → verify (against codebase) → evaluate (fits this project?) → respond (technical acknowledgment or reasoned pushback) → implement (one item at a time, tested).
- No performative agreement: never "You're absolutely right!" — state the fix instead.
- Clarify ambiguity first: stop on any unclear item; clarify everything before implementing; no partial-understanding work.
- Source-specific handling: the human partner is trusted but still questioned on unclear scope; external reviewer suggestions are verified item by item (technically correct for this codebase? breaks existing behavior? understands full context?); conflicts go to the human partner first.
- YAGNI check: when a reviewer suggests "implementing properly", grep for actual usage first; unused means ask whether to remove.
- Implementation order: blockers (breaks/security) → simple fixes → complex refactors; tested one at a time, never batched blind.
- Pushback mechanism: push back with technical reasoning when a suggestion breaks existing functionality, lacks context, violates YAGNI, is wrong for this stack, or conflicts with architectural decisions.
- GitHub threads: reply inside the comment thread, not as top-level PR comments.
Workflow
- Read the full feedback without reacting
- Restate the requirement (or ask)
- Verify each item against the codebase
- Evaluate fit; confirm or push back with reasoning
- Clarify ambiguity, then implement in blocker → simple → complex order
- Test each fix; verify no regressions
Inputs & outputs
| Input | Required | Notes |
|---|---|---|
| Review feedback | Yes | List of review items |
Output: technical verdict per item (implement / push back / clarify) + tested code changes, item by item.
Fit
- Technical evaluation and implementation of PR review feedback
- Careful handling of external reviewer input
- Review-process discipline in multi-person collaboration
Before you start
- No API key.
- The method assumes codebase access to verify review claims; when you can't verify, state the limitation and ask for direction instead of pushing ahead.
receiving-code-review is part of the Aiglade Skill library. Invoke it from the Aiglade chat box in plain language.