| name | receiving-code-review |
| description | Use when handling review feedback so responses are technical, verified, and implementation actions are sequenced safely. |
Receiving code review
Core principle
Treat feedback as technical input to verify, not performative agreement to repeat.
Workflow
- Read fully before acting.
- Clarify unclear items first.
- If any review item is ambiguous, ask for clarification before implementing partial changes.
- Verify against codebase reality.
- Confirm each suggestion is correct for this repository and current constraints.
- Prioritize and implement.
- Fix blocking and correctness issues first, then quality and style items.
- Validate each batch.
- Re-run targeted checks after each meaningful batch of fixes.
- Report concrete outcomes.
- State what changed, what was deferred, and why.
When to push back
Push back with technical evidence when a suggestion:
- breaks existing requirements or behavior
- depends on assumptions that do not hold in this repo
- introduces unnecessary scope beyond the request
Output contract
Return:
Clarifications: questions that must be resolved first, or none.
Accepted items: fixes implemented.
Rejected items: technical reason for disagreement.
Validation: commands run and outcomes.
Anti-patterns
- blind implementation of all feedback without verification
- partial execution when unresolved review items may affect approach
- vague replies without technical rationale