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:
- Receiving feedback - Technical evaluation over performative agreement
- Requesting reviews - Systematic review via code-reviewer subagent
- Verification gates - Evidence before any completion claims
Each practice has specific triggers and protocols detailed in reference files.
Core Principle
Always honoring YAGNI, KISS, and DRY principles.
Be honest, be brutal, straight to the point, and be concise.
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
- Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) and HEAD_SHA=$(git rev-parse HEAD)
- Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
- 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
- Technical rigor over social performance - No performative agreement
- Systematic review processes - Use code-reviewer subagent
- Evidence before claims - Verification gates always
Verify. Question. Then implement. Evidence. Then claim.
1---2name: code-review-273description: Code review practices with technical rigor and verification gates. Practices: receiving feedback, requesting reviews, verification gates. Capabilities: technical evaluation, evidence-based claims, PR review, subagent-driven review, completion verification. Actions: review, evaluate, verify, validate code changes. Keywords: code review, PR review, pull request, technical feedback, review feedback, completion claim, verification, evidence-based, code quality, review request, technical rigor, subagent review, code-reviewer, review gate, merge criteria. Use when: receiving code review feedback, completing major features, making completion claims, requesting systematic reviews, validating before merge, preventing false completion claims.4---5
6# Code Review
7
8Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.
9
10## Overview
11
12Code review requires three distinct practices:
13
141. **Receiving feedback** - Technical evaluation over performative agreement
152. **Requesting reviews** - Systematic review via code-reviewer subagent
163. **Verification gates** - Evidence before any completion claims
17
18Each practice has specific triggers and protocols detailed in reference files.
19
20## Core Principle
21
22Always honoring **YAGNI**, **KISS**, and **DRY** principles.
23**Be honest, be brutal, straight to the point, and be concise.**
24
25**Technical correctness over social comfort.** Verify before implementing. Ask before assuming. Evidence before claims.
26
27## When to Use This Skill
28
29### Receiving Feedback
30Trigger when:
31- Receiving code review comments from any source
32- Feedback seems unclear or technically questionable
33- Multiple review items need prioritization
34- External reviewer lacks full context
35- Suggestion conflicts with existing decisions
36
37**Reference:** `references/code-review-reception.md`
38
39### Requesting Review
40Trigger when:
41- Completing tasks in subagent-driven development (after EACH task)
42- Finishing major features or refactors
43- Before merging to main branch
44- Stuck and need fresh perspective
45- After fixing complex bugs
46
47**Reference:** `references/requesting-code-review.md`
48
49### Verification Gates
50Trigger when:
51- About to claim tests pass, build succeeds, or work is complete
52- Before committing, pushing, or creating PRs
53- Moving to next task
54- Any statement suggesting success/completion
55- Expressing satisfaction with work
56
57**Reference:** `references/verification-before-completion.md`
58
59## Quick Decision Tree
60
61```
62SITUATION?
63│
64├─ Received feedback
65│ ├─ Unclear items? → STOP, ask for clarification first
66│ ├─ From human partner? → Understand, then implement
67│ └─ From external reviewer? → Verify technically before implementing
68│
69├─ Completed work
70│ ├─ Major feature/task? → Request code-reviewer subagent review
71│ └─ Before merge? → Request code-reviewer subagent review
72│
73└─ About to claim status
74 ├─ Have fresh verification? → State claim WITH evidence
75 └─ No fresh verification? → RUN verification command first
76```
77
78## Receiving Feedback Protocol
79
80### Response Pattern
81READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
82
83### Key Rules
84- ❌ No performative agreement: "You're absolutely right!", "Great point!", "Thanks for [anything]"
85- ❌ No implementation before verification
86- ✅ Restate requirement, ask questions, push back with technical reasoning, or just start working
87- ✅ If unclear: STOP and ask for clarification on ALL unclear items first
88- ✅ YAGNI check: grep for usage before implementing suggested "proper" features
89
90### Source Handling
91- **Human partner:** Trusted - implement after understanding, no performative agreement
92- **External reviewers:** Verify technically correct, check for breakage, push back if wrong
93
94**Full protocol:** `references/code-review-reception.md`
95
96## Requesting Review Protocol
97
98### When to Request
99- After each task in subagent-driven development
100- After major feature completion
101- Before merge to main
102
103### Process
1041. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
1052. Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
1063. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later
107
108**Full protocol:** `references/requesting-code-review.md`
109
110## Verification Gates Protocol
111
112### The Iron Law
113**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**
114
115### Gate Function
116IDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim
117
118Skip any step = lying, not verifying
119
120### Requirements
121- Tests pass: Test output shows 0 failures
122- Build succeeds: Build command exit 0
123- Bug fixed: Test original symptom passes
124- Requirements met: Line-by-line checklist verified
125
126### Red Flags - STOP
127Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification
128
129**Full protocol:** `references/verification-before-completion.md`
130
131## Integration with Workflows
132
133- **Subagent-Driven:** Review after EACH task, verify before moving to next
134- **Pull Requests:** Verify tests pass, request code-reviewer review before merge
135- **General:** Apply verification gates before any status claims, push back on invalid feedback
136
137## Bottom Line
138
1391. Technical rigor over social performance - No performative agreement
1402. Systematic review processes - Use code-reviewer subagent
1413. Evidence before claims - Verification gates always
142
143Verify. Question. Then implement. Evidence. Then claim.
majiayu000