| name | receiving-code-review |
| description | Use when receiving code review feedback — requires technical verification of each suggestion before implementing, not blind agreement |
| tags | ["review","discipline","quality"] |
| triggers | ["review feedback","PR comments","code review response","reviewer says","feedback received"] |
| chains_to | ["verification-before-completion"] |
| priority | core |
| gate | false |
Receiving Code Review
Quick Reference
When receiving review feedback: verify each suggestion technically before implementing. Don't blindly agree. Don't blindly reject. Understand, verify, then act.
When to Use
- Received PR review comments
- Sensei returned findings to address
- User relays feedback from a reviewer
- Review agent findings need to be addressed
When NOT to Use
- You're giving a review (use
requesting-code-review)
- Feedback is about requirements, not code quality
Core Process
Step 1: Read All Feedback First
Read every comment/finding before responding to any. Understand the full picture — some comments may relate to each other.
Step 2: Categorize Each Item
For each piece of feedback:
| Category | Action |
|---|
| Clearly correct (bug, security issue, missing test) | Fix it. No discussion needed. |
| Technically sound suggestion | Verify the suggestion works, then implement. |
| Debatable (style, approach, taste) | Understand the reasoning. If it improves the code, do it. If not, explain why. |
| Incorrect (misunderstood the code, wrong assumption) | Explain politely with evidence. Show the code that proves your point. |
Step 3: Verify Before Implementing
For each suggestion you plan to implement:
- Understand what the reviewer is asking for and why
- Check if the suggestion is technically correct (will it break anything?)
- Implement the change
- Verify the change works (run tests, build, etc.)
Never implement a suggestion you don't understand. Ask for clarification instead.
Step 4: Respond to Each Item
For items you implement:
Done. [Brief description of the change.]
For items you disagree with:
[Technical explanation with evidence — file:line, test output, docs reference.]
For items that need clarification:
I want to make sure I understand: are you suggesting [interpretation]? Because [context].
Step 5: Final Verification
After all changes:
- Run full test suite
- Chain to
verification-before-completion
- Confirm all findings are addressed
Anti-Patterns
| Anti-Pattern | Why It's Wrong |
|---|
| "Good point, fixed!" without verifying | The "fix" might introduce new bugs |
| Implementing every suggestion blindly | Some suggestions are wrong. Verify first. |
| Rejecting all feedback defensively | Review is about the code, not you |
| Bulk-fixing without understanding | You'll miss the learning opportunity |
| "I'll fix it later" | You won't. Fix it now. |
| Performative agreement | Saying "great catch" when you disagree helps nobody |
The Rule
Technical rigor over social compliance. Verify the suggestion. If it's right, implement it. If it's wrong, explain why with evidence. Never agree just to be agreeable.
Chaining
REQUIRED: syntaxninja-dojo:verification-before-completion (after all fixes applied)
