receiving-code-review

Receiving Code Review

Process code review feedback with technical evaluation, not emotional performance.

When Invoked

This skill is invoked after code-reviewer agent returns output. This skill processes the feedback.

The Response Pattern

1. Read - Complete feedback without reacting
2. Categorize - Critical / Important / Minor
3. Verify - Check each issue against codebase
4. Evaluate - Technically sound for THIS codebase?
5. Respond - Acknowledge valid, push back if wrong
6. Implement - One fix at a time, test each

Processing Feedback

Categorize

From code-reviewer output, separate issues:

Verify Each Issue

For each Critical and Important issue:

# Check if the issue is real
# Read the file/line mentioned
# Determine if feedback is accurate

Questions to ask:

• Does this file/line exist?
• Is the described problem present?
• Would the suggested fix work?
• Does this break existing functionality?

Evaluate

For each verified issue:

If valid:

• Note the fix needed
• Add to implementation queue

If unclear:

• STOP
• Do not guess
• Ask for clarification on ALL unclear items before implementing any

If wrong:

• Note why (technical reasoning)
• Do not implement
• Push back in summary

Forbidden Responses

Never say:

• "You're absolutely right!"
• "Great point!"
• "Thanks for catching that!"

Instead: Restate the technical requirement, or fix silently.

Implementing Fixes

Order of implementation:

1. All unclear items clarified first - Partial understanding = wrong implementation
2. Critical issues - Security, data loss, broken functionality
3. Simple fixes - Typos, imports, obvious errors
4. Complex fixes - Refactoring, architecture changes

For each fix:

# 1. Implement the fix

# 2. Run tests
npm test  # or project test command

# 3. If tests pass, commit
git add -A && git commit -m "fix: [description from review]"

# 4. Next fix

Do not batch fixes. One fix, one test run, one commit.

Pushing Back

Push back when:

• Suggestion breaks existing functionality
• Reviewer lacks context visible in codebase
• Violates YAGNI (adding unused feature)
• Technically incorrect for this stack/framework

How to push back:

Issue: "[reviewer's concern]"
Response: Not implementing. [Technical reasoning with code references]

Reference working tests, existing patterns, or documentation.

Handling External Reviewers

Before implementing external feedback:

1. Check: Technically correct for THIS codebase?
2. Check: Breaks existing functionality?
3. Check: Reviewer understand full context?

External reviewers may not know:

• Project conventions
• Existing patterns
• Why something was done a certain way

Verify before implementing.

Acknowledging Correct Feedback

✅ "Fixed. [Brief description]"
✅ [Just fix it silently]
❌ "You're absolutely right!"
❌ "Thanks for [anything]"

Actions speak. The code shows the feedback was heard.

Summary Output

After processing all feedback, report:

Review processed:
- Critical: [N] found, [M] fixed
- Important: [N] found, [M] fixed
- Minor: [N] noted for later
- Pushed back: [N] (not valid for this codebase)

All fixes verified with tests.

Integration

Uses:

• dev-workflow:verification-before-completion - Verify each fix before next

Receives from:

• dev-workflow:code-reviewer agent output