| name | receiving-code-review |
| description | Use when processing review feedback. Technical rigor, not performative agreement. |
Receiving Code Review
When to Use
∀ review feedback from any reviewer.
HARD-GATE
¬blindly implement review suggestions. Verify each suggestion is technically correct first.
Process
∀ review finding:
- UNDERSTAND: What exactly is the reviewer asking for?
- VERIFY: Is the suggestion technically correct?
- Read the code the reviewer references
- Check if the reviewer's understanding matches reality
- If unclear, ask for clarification (¬guess)
- EVALUATE: Does implementing this improve the code?
- Correct finding -> implement
- Wrong finding -> push back with evidence
- Style preference -> discuss, ¬auto-implement
- IMPLEMENT: If accepted, make the change + verify it doesn't break anything
Anti-Patterns
- Performative agreement ("great catch!" then implementing wrong suggestion)
- Implementing every suggestion without evaluation
- Defensive rejection of valid feedback
- Making changes without understanding why
Rules
- ∀ accepted change: run tests after implementing
- ∀ rejected finding: explain with evidence (code reference, test output)
- Severity Critical/Important -> must address (implement ∨ push back with evidence)
- Severity Minor -> may defer with justification