---

name: code-review description: Use when requesting code review after completing tasks, or when receiving and responding to code review feedback

Code Review

Overview

Code review has two phases: requesting review and handling feedback.

Core principle: Review early, review often. Verify before implementing. Technical correctness over social comfort.

---

Part 1: Requesting Review

When to Request

Mandatory:

• After each task in plan-execution (subagent mode)
• After completing major feature
• Before merge to main

Optional but valuable:

• When stuck (fresh perspective)
• Before refactoring (baseline check)

How to Request

1. Get git SHAs:

CopyBASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

1. Dispatch code-reviewer subagent using template at ./code-reviewer.md

2. Provide:

   • What was implemented
   • Plan or requirements it should meet
   • Base and head SHAs
   • Brief description

3. Act on feedback:

   • Fix Critical issues immediately
   • Fix Important issues before proceeding
   • Note Minor issues for later
   • Push back if reviewer is wrong (with reasoning)

---

Part 2: Receiving Feedback

The Response Pattern

1. READ - Complete feedback without reacting
2. UNDERSTAND - Restate requirement in own words (or ask)
3. VERIFY - Check against codebase reality
4. EVALUATE - Technically sound for THIS codebase?
5. RESPOND - Technical acknowledgment or reasoned pushback
6. IMPLEMENT - One item at a time, test each

Forbidden Responses

Never say:

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

Instead:

• Restate the technical requirement
• Ask clarifying questions
• Push back with technical reasoning if wrong
• Just start working (actions > words)

Handling Unclear Feedback

If ANY item is unclear: STOP. Ask for clarification on ALL unclear items before implementing anything.

Items may be related - partial understanding = wrong implementation.

When to Push Back

Push back when:

• Suggestion breaks existing functionality
• Reviewer lacks full context
• Violates YAGNI (unused feature)
• Technically incorrect for this stack
• Conflicts with architectural decisions

How: Technical reasoning, not defensiveness. Reference working tests/code.

Implementation Order

For multi-item feedback:

1. Clarify anything unclear FIRST
2. Implement in order: blocking issues → simple fixes → complex fixes
3. Test each fix individually
4. Verify no regressions

Acknowledging Correct Feedback

Copy✅ "Fixed. [Brief description]"
✅ "Good catch - [issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

❌ Any gratitude expression
❌ "You're absolutely right!"

---

Red Flags

When requesting:

• Skipping review because "it's simple"
• Proceeding with unfixed Critical/Important issues

When receiving:

• Performative agreement
• Blind implementation without verification
• Avoiding pushback when reviewer is wrong
• Implementing partial feedback while items remain unclear

---

Integration

Used by:

• plan-execution - Review after each task (subagent mode) or batch

GitHub threads: Reply in comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not top-level PR comment.