Code Review

{
  "description": "Use when receiving code review feedback (especially if unclear or technically questionable), when completing tasks or major features requiring review before proceeding, or before making any completion/success claims. Covers three practices - receiving feedback with technical rigor over performative agreement, requesting reviews via code-reviewer subagent, and verification gates requiring evidence before any status claims. Essential for subagent-driven development, pull requests, and preventing false completion claims.",
  "references": {
    "files": [
      "references/code-review-reception.md",
      "references/requesting-code-review.md",
      "references/verification-before-completion.md"
    ]
  },
  "content": "Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.",
  "name": "code-review",
  "id": "code-review_mrgoonie",
  "sections": {
    "Integration with Workflows": "- **Subagent-Driven:** Review after EACH task, verify before moving to next\r\n- **Pull Requests:** Verify tests pass, request code-reviewer review before merge\r\n- **General:** Apply verification gates before any status claims, push back on invalid feedback",
    "Core Principle": "**Technical correctness over social comfort.** Verify before implementing. Ask before assuming. Evidence before claims.",
    "Requesting Review Protocol": "### When to Request\r\n- After each task in subagent-driven development\r\n- After major feature completion\r\n- Before merge to main\r\n\r\n### Process\r\n1. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`\r\n2. Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION\r\n3. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later\r\n\r\n**Full protocol:** `references/requesting-code-review.md`",
    "Overview": "Code review requires three distinct practices:\r\n\r\n1. **Receiving feedback** - Technical evaluation over performative agreement\r\n2. **Requesting reviews** - Systematic review via code-reviewer subagent\r\n3. **Verification gates** - Evidence before any completion claims\r\n\r\nEach practice has specific triggers and protocols detailed in reference files.",
    "Quick Decision Tree": "```\r\nSITUATION?\r\n│\r\n├─ Received feedback\r\n│  ├─ Unclear items? → STOP, ask for clarification first\r\n│  ├─ From human partner? → Understand, then implement\r\n│  └─ From external reviewer? → Verify technically before implementing\r\n│\r\n├─ Completed work\r\n│  ├─ Major feature/task? → Request code-reviewer subagent review\r\n│  └─ Before merge? → Request code-reviewer subagent review\r\n│\r\n└─ About to claim status\r\n   ├─ Have fresh verification? → State claim WITH evidence\r\n   └─ No fresh verification? → RUN verification command first\r\n```",
    "Bottom Line": "1. Technical rigor over social performance - No performative agreement\r\n2. Systematic review processes - Use code-reviewer subagent\r\n3. Evidence before claims - Verification gates always\r\n\r\nVerify. Question. Then implement. Evidence. Then claim.",
    "When to Use This Skill": "### Receiving Feedback\r\nTrigger when:\r\n- Receiving code review comments from any source\r\n- Feedback seems unclear or technically questionable\r\n- Multiple review items need prioritization\r\n- External reviewer lacks full context\r\n- Suggestion conflicts with existing decisions\r\n\r\n**Reference:** `references/code-review-reception.md`\r\n\r\n### Requesting Review\r\nTrigger when:\r\n- Completing tasks in subagent-driven development (after EACH task)\r\n- Finishing major features or refactors\r\n- Before merging to main branch\r\n- Stuck and need fresh perspective\r\n- After fixing complex bugs\r\n\r\n**Reference:** `references/requesting-code-review.md`\r\n\r\n### Verification Gates\r\nTrigger when:\r\n- About to claim tests pass, build succeeds, or work is complete\r\n- Before committing, pushing, or creating PRs\r\n- Moving to next task\r\n- Any statement suggesting success/completion\r\n- Expressing satisfaction with work\r\n\r\n**Reference:** `references/verification-before-completion.md`",
    "Receiving Feedback Protocol": "### Response Pattern\r\nREAD → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT\r\n\r\n### Key Rules\r\n- ❌ No performative agreement: \"You're absolutely right!\", \"Great point!\", \"Thanks for [anything]\"\r\n- ❌ No implementation before verification\r\n- ✅ Restate requirement, ask questions, push back with technical reasoning, or just start working\r\n- ✅ If unclear: STOP and ask for clarification on ALL unclear items first\r\n- ✅ YAGNI check: grep for usage before implementing suggested \"proper\" features\r\n\r\n### Source Handling\r\n- **Human partner:** Trusted - implement after understanding, no performative agreement\r\n- **External reviewers:** Verify technically correct, check for breakage, push back if wrong\r\n\r\n**Full protocol:** `references/code-review-reception.md`",
    "Verification Gates Protocol": "### The Iron Law\r\n**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**\r\n\r\n### Gate Function\r\nIDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim\r\n\r\nSkip any step = lying, not verifying\r\n\r\n### Requirements\r\n- Tests pass: Test output shows 0 failures\r\n- Build succeeds: Build command exit 0\r\n- Bug fixed: Test original symptom passes\r\n- Requirements met: Line-by-line checklist verified\r\n\r\n### Red Flags - STOP\r\nUsing \"should\"/\"probably\"/\"seems to\", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification\r\n\r\n**Full protocol:** `references/verification-before-completion.md`"
  }
}

---
name: code-review
description: Use when receiving code review feedback (especially if unclear or technically questionable), when completing tasks or major features requiring review before proceeding, or before making any completion/success claims. Covers three practices - receiving feedback with technical rigor over performative agreement, requesting reviews via code-reviewer subagent, and verification gates requiring evidence before any status claims. Essential for subagent-driven development, pull requests, and preventing false completion claims.
---

# Code Review

Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.

## Overview

Code review requires three distinct practices:

1. **Receiving feedback** - Technical evaluation over performative agreement
2. **Requesting reviews** - Systematic review via code-reviewer subagent
3. **Verification gates** - Evidence before any completion claims

Each practice has specific triggers and protocols detailed in reference files.

## Core Principle

**Technical correctness over social comfort.** Verify before implementing. Ask before assuming. Evidence before claims.

## When to Use This Skill

### Receiving Feedback
Trigger when:
- Receiving code review comments from any source
- Feedback seems unclear or technically questionable
- Multiple review items need prioritization
- External reviewer lacks full context
- Suggestion conflicts with existing decisions

**Reference:** `references/code-review-reception.md`

### Requesting Review
Trigger when:
- Completing tasks in subagent-driven development (after EACH task)
- Finishing major features or refactors
- Before merging to main branch
- Stuck and need fresh perspective
- After fixing complex bugs

**Reference:** `references/requesting-code-review.md`

### Verification Gates
Trigger when:
- About to claim tests pass, build succeeds, or work is complete
- Before committing, pushing, or creating PRs
- Moving to next task
- Any statement suggesting success/completion
- Expressing satisfaction with work

**Reference:** `references/verification-before-completion.md`

## Quick Decision Tree

```
SITUATION?
│
├─ Received feedback
│  ├─ Unclear items? → STOP, ask for clarification first
│  ├─ From human partner? → Understand, then implement
│  └─ From external reviewer? → Verify technically before implementing
│
├─ Completed work
│  ├─ Major feature/task? → Request code-reviewer subagent review
│  └─ Before merge? → Request code-reviewer subagent review
│
└─ About to claim status
   ├─ Have fresh verification? → State claim WITH evidence
   └─ No fresh verification? → RUN verification command first
```

## Receiving Feedback Protocol

### Response Pattern
READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

### Key Rules
- ❌ No performative agreement: "You're absolutely right!", "Great point!", "Thanks for [anything]"
- ❌ No implementation before verification
- ✅ Restate requirement, ask questions, push back with technical reasoning, or just start working
- ✅ If unclear: STOP and ask for clarification on ALL unclear items first
- ✅ YAGNI check: grep for usage before implementing suggested "proper" features

### Source Handling
- **Human partner:** Trusted - implement after understanding, no performative agreement
- **External reviewers:** Verify technically correct, check for breakage, push back if wrong

**Full protocol:** `references/code-review-reception.md`

## Requesting Review Protocol

### When to Request
- After each task in subagent-driven development
- After major feature completion
- Before merge to main

### Process
1. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
2. Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
3. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later

**Full protocol:** `references/requesting-code-review.md`

## Verification Gates Protocol

### The Iron Law
**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**

### Gate Function
IDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim

Skip any step = lying, not verifying

### Requirements
- Tests pass: Test output shows 0 failures
- Build succeeds: Build command exit 0
- Bug fixed: Test original symptom passes
- Requirements met: Line-by-line checklist verified

### Red Flags - STOP
Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification

**Full protocol:** `references/verification-before-completion.md`

## Integration with Workflows

- **Subagent-Driven:** Review after EACH task, verify before moving to next
- **Pull Requests:** Verify tests pass, request code-reviewer review before merge
- **General:** Apply verification gates before any status claims, push back on invalid feedback

## Bottom Line

1. Technical rigor over social performance - No performative agreement
2. Systematic review processes - Use code-reviewer subagent
3. Evidence before claims - Verification gates always

Verify. Question. Then implement. Evidence. Then claim.