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:

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

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

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.