| name | receiving-code-review |
| description | Use when code review feedback has been received and needs to be assessed, answered, or implemented. Verify each suggestion against the actual code and requirements before changing anything. |
Receiving Code Review
Treat review feedback as technical input to evaluate, not an instruction to accept blindly or a debate to win.
Workflow
- Collect the feedback — Read the full thread and surrounding code before reacting to individual comments.
- Normalize the items — Restate each actionable request and identify ambiguity, dependencies, and duplicates.
- Verify against reality — Check the current code, tests, supported environments, requirements, and prior decisions.
- Classify each item:
- Accept — Correct and appropriate as written.
- Adapt — The concern is valid, but a different implementation better fits the codebase.
- Push back — Incorrect, harmful, out of scope, or unsupported by actual usage.
- Needs decision — Depends on product, architecture, compatibility, or scope authority.
- Act in priority order — Security or correctness blockers first, then simple independent fixes, then larger changes.
- Verify changes — Test each coherent group and run relevant regression checks before reporting resolution.
Clarification and scope
- Ask when wording is unclear or different interpretations would change behavior.
- Clear independent items may proceed while unrelated questions are pending.
- If feedback conflicts with an explicit user decision, architecture contract, or compatibility requirement, surface the conflict instead of silently overriding it.
- A diagnosis or review request does not automatically authorize implementation; follow the user's requested scope.
- Do not add speculative infrastructure or unused features merely because they sound more complete. Confirm actual need first.
How to push back
Use concrete technical evidence:
- Refer to the relevant code, test, contract, version, or runtime behavior.
- Explain the consequence of the suggestion, not the reviewer's presumed intent.
- Offer a safer alternative when one is clear.
- Escalate material product or architecture choices to the user.
If evidence later disproves the pushback, correct the record briefly and proceed with the verified approach.
Response style
- Prefer factual acknowledgment over empty praise or defensiveness.
- State what was verified, what changed, and what remains unresolved.
- When replying in a review system, keep discussion attached to the original thread when supported.
- Do not mark a thread resolved until the requested concern is addressed or a decision explicitly rejects it.
The goal is correct code and traceable decisions, not performative agreement.
