receiving-code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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:

1. **Understand** what the reviewer is asking for and why
2. **Check** if the suggestion is technically correct (will it break anything?)
3. **Implement** the change
4. **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:
1. Run full test suite
2. Chain to `verification-before-completion`
3. 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)

From thesyntaxninja/syntaxninja-dojo, MIT.

More from thesyntaxninja/syntaxninja-dojo