review

# Code Review with Confidence Filtering

## Overview

Review code thoroughly but only report issues you're confident about.
Filter out noise - stylistic preferences and uncertain concerns don't belong in reviews.
Focus on bugs, security issues, and clear violations.

**Core principle:** Only report issues with >= 80% confidence.

**Announce at start:** "I'm using the review skill to review this code."

## When to Request Review

**Mandatory:**
- After completing a feature
- Before merging to main
- After fixing complex bugs

**Optional but valuable:**
- When stuck (fresh perspective helps)
- Before major refactoring
- After implementing unfamiliar patterns

## The Review Process

### Step 1: Gather Context

**Get the diff:**
```bash
BASE_SHA=$(git merge-base HEAD main)  # or specific commit
HEAD_SHA=$(git rev-parse HEAD)
git diff $BASE_SHA..$HEAD_SHA
```

**Check existing patterns:**
```bash
kodo query "code style"      # Project conventions
kodo query "error handling"  # Error patterns used
```

### Step 2: Review for Issues

**Priority categories:**

| Priority | Confidence | Action | Examples |
|----------|------------|--------|----------|
| Critical | >= 90% | Must fix before merge | Security holes, data loss, crashes |
| Important | >= 80% | Should fix | Logic bugs, missing error handling |
| Minor | >= 80% | Nice to fix | Performance, readability |

**DO report (>= 80% confidence):**
- Clear bugs with specific line numbers
- Obvious security issues
- Missing error handling that will cause failures
- Logic errors you can prove with example input

**DO NOT report (< 80% confidence):**
- Stylistic preferences ("I would have done X")
- Uncertain concerns ("This might cause issues")
- Opinions without evidence
- Things that "feel wrong" but you can't explain why

### Step 3: Document Findings

**Report format:**

```markdown
## Code Review: [Feature/PR Name]

**Commits reviewed:** `BASE_SHA..HEAD_SHA`
**Files changed:** X files, +Y/-Z lines

### Strengths
- [What's