huuanh20 Code Review
Apply code review practices with technical rigor, evidence-based claims, and verification over performative responses.
References
| Practice | When to load | File |
|---|---|---|
| Receiving feedback | Unclear/questionable feedback, conflict with reviewer | references/code-review-reception.md |
| Requesting review | After each task, before merge — use /code-review |
references/requesting-code-review.md |
| Verification gates | Before any completion/success claim | references/verification-before-completion.md |
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
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
- Suggestion conflicts with existing decisions
Requesting Review
Trigger when:
- Completing tasks in subagent-driven development (after EACH task)
- Finishing major features or refactors
- Before merging to main branch
- After fixing complex bugs
Use /code-review (local) or /code-review <PR> (PR mode). ck:cook, ck:quality, and ck:test remain separate gates; run final code review after their required artifacts are current.
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
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? → Run /code-review (or it's automatic in cook/fix)
│ └─ Before merge? → Run /code-review <PR-number>
│
└─ 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: search for usage before implementing suggested features
Full protocol: references/code-review-reception.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
Red Flags — STOP
Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports.
Full protocol: references/verification-before-completion.md
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.