pproenca 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
- Read - Complete feedback without reacting
- Categorize - Critical / Important / Minor
- Verify - Check each issue against codebase
- Evaluate - Technically sound for THIS codebase?
- Respond - Acknowledge valid, push back if wrong
- Implement - One fix at a time, test each
Processing Feedback
Categorize
From code-reviewer output, separate issues:
| Category | Action | Examples |
|---|---|---|
| Critical | Fix immediately | Security, data loss, broken functionality |
| Important | Fix before proceeding | Architecture, missing tests, error handling |
| Minor | Note for later | Style, optimization, documentation |
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:
- All unclear items clarified first - Partial understanding = wrong implementation
- Critical issues - Security, data loss, broken functionality
- Simple fixes - Typos, imports, obvious errors
- 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:
- Check: Technically correct for THIS codebase?
- Check: Breaks existing functionality?
- 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-revieweragent output