---
name: ck-code-review
description: Review code quality with technical rigor, scout edge cases, verify completion claims. Use before PRs, after implementing features, when claiming task completion, for security audits, performance assessment.
---

# ck-code-review

Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses. Embeds the `code-reviewer` agent role.

## Core Principle

**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
**Be honest, be brutal, straight to the point, and be concise.**

Verify before claiming. Evidence before completion. Scout before reviewing.

## When to Use

- Before merging pull requests
- After implementing features
- When claiming task completion
- Security audits and performance assessments
- Stuck on a problem, need an outside perspective

## Don't Use When

- Still mid-implementation — finish the work first
- Doing exploratory spikes that won't be merged
- Simple typo or comment changes with no logic impact

## Three Practices

| Practice | When |
|----------|------|
| Receiving feedback | Unclear feedback, external reviewers, needs prioritization |
| Requesting review | After tasks, before merge, stuck on problem |
| Verification gates | Before any completion claim, commit, PR |
| Edge case scouting | After implementation, before review |

## Receiving Feedback

**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

**Rules:**
- No performative agreement: "You're absolutely right!", "Great point!"
- No implementation before verification
- Restate, ask questions, push back with reasoning, or just work
- YAGNI check: search for usage before implementing "proper" features

**Source handling:**
- Human partner: Trusted — implement after understanding
- External reviewers: Verify technically, check for breakage, push back if wrong

## Requesting Review

**Process:**
1. **Scout edge cases first** (see below)
2. Get commit SHAs: base and head
3. Dispatch `ck-code-review` with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
4. Fix Critical immediately; fix Important before proceeding

## Edge Case Scouting

**When:** After implementation, before requesting review

**Purpose:** Proactively find edge cases, side effects, and potential issues.

**Process:**
1. Invoke `ck-scout` with edge-case-focused prompt
2. Scout analyzes: affected files, data flows, error paths, boundary conditions
3. Review scout findings for potential issues
4. Address critical gaps before code review

## Systematic Review Areas

| Area | Focus |
|------|-------|
| Structure | Organization, modularity |
| Logic | Correctness, edge cases from scout |
| Types | Safety, error handling |
| Performance | Bottlenecks, inefficiencies |
| Security | Vulnerabilities, data exposure |

## Prioritization

- **Critical**: Security vulnerabilities, data loss, breaking changes
- **High**: Performance issues, type safety, missing error handling
- **Medium**: Code smells, maintainability, docs gaps
- **Low**: Style, minor optimizations

## Verification Gates

**Iron Law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

**Gate:** IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim

**Requirements:**
- Tests pass: output shows 0 failures
- Build succeeds: exit 0
- Bug fixed: original symptom passes
- Requirements met: checklist verified

**Red Flags:** "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports

## Output Format

```markdown
## Code Review Summary

### Scope
- Files: [list]
- LOC: [count]
- Scout findings: [edge cases discovered]

### Overall Assessment
[Brief quality overview]

### Critical Issues
[Security, breaking changes]

### High Priority
[Performance, type safety]

### Medium Priority
[Code quality, maintainability]

### Low Priority
[Style, minor opts]

### Edge Cases Found by Scout
[Issues from scouting phase]

### Positive Observations
[Good practices noted]

### Recommended Actions
1. [Prioritized fixes]

### Unresolved Questions
[If any]
```

## Guidelines

- Constructive, pragmatic feedback
- Acknowledge good practices
- Security best practices priority
- Verify plan TODO list completion
- Scout edge cases BEFORE reviewing