---
name: code-review
description: Multi-perspective code review before completing any slice or milestone. Launches specialized review lenses (correctness, security, test coverage, contracts, architecture) and scores issues by confidence and impact. Use before declaring a slice done, before merging a PR, or when asked to review code.
---

# Code Review: Multi-Lens, Evidence-Based

Run structured code review before declaring work complete. Uses specialized review angles and filters noise by scoring confidence and impact.

---

## When to Run

- Before marking a slice as done
- Before creating a PR
- When explicitly asked to review code
- When `verification-before-completion` flags uncertainty

---

## Phase 1: Scope

Identify what to review:
- Changed files (from `git diff --name-only HEAD~1` or the slice's scope)
- Entry points and integration boundaries
- Test files corresponding to changed code

Print a one-line scope summary: "Reviewing N files in [area]: [list]"

---

## Phase 2: Specialized Lenses

Apply each lens in sequence. For each finding, record:
- **Location**: file:line
- **Description**: what the issue is
- **Confidence**: 0–100 (how certain is this a real problem?)
- **Impact**: 0–100 (how bad if it ships?)

### Lens 1: Bug Hunter (Correctness)
- Off-by-one errors, nil/null dereferences, integer overflow
- Race conditions, uninitialized state, incorrect error handling
- Logic inversions, missing edge cases (empty input, max values)
- Unchecked return values, swallowed errors

### Lens 2: Security Auditor
- User input not validated at system boundaries
- SQL not parameterized, template injection risks
- Secrets or credentials in code or logs
- Auth checks missing on sensitive paths
- Unsafe deserialization, path traversal

### Lens 3: Test Coverage Reviewer
- Missing test for the changed behavior
- Happy-path only — no error cases, no edge cases
- Tests that mock everything (false confidence)
- Test name doesn't describe what it proves
- Missing integration test when components cross a boundary

### Lens 4: Contract Reviewer
- Function signature changed but callers not updated
- Return type inconsistency (sometimes error, sometimes not)
- Silent breaking change to an interface
- Missing documentation of preconditions or invariants

### Lens 5: Architecture Reviewer
- New coupling introduced between modules that shouldn't know about each other
- Business logic leaking into HTTP handlers or storage layer
- Duplicate logic that should be shared
- Shallow module added where a deeper one was possible

---

## Phase 3: Score and Filter

After all lenses, produce a findings table:

| # | Lens | Location | Description | Confidence | Impact | Severity |
|---|------|----------|-------------|-----------|--------|----------|
| 1 | Bug | file:42 | nil pointer on empty result | 90 | 85 | Critical |
| 2 | Test | file_test.go | no test for error path | 95 | 60 | High |
| 3 | Arch | service.go | handler contains DB query | 80 | 55 | High |

Severity mapping:
- **Critical**: Impact 81–100 (blocks merge)
- **High**: Impact 61–80 (fix before merge)
- **Medium**: Impact 41–60 (fix in follow-up)
- **Low**: Impact < 40 (advisory only)

Filter: only report findings with Confidence ≥ 70. Below that, mention as "low-confidence observation" at the end.

---

## Phase 4: Verdict

End with a clear verdict:

```
VERDICT: [BLOCK / APPROVE WITH FIXES / APPROVE]

Critical: N issues (list them)
High: N issues (list them)
Action required: [what must be fixed before merge]
```

- **BLOCK**: any Critical issue
- **APPROVE WITH FIXES**: High issues only — can merge after fixes
- **APPROVE**: Medium/Low only — can merge, fix in follow-up

---

## Rules

- **Evidence required** — every finding needs a file:line citation
- **No vague complaints** — "this could be better" is not a finding
- **Confidence gates noise** — if you're not 70%+ sure, say so explicitly
- **Don't restate the code** — describe the risk, not what the line does
- **Critical means critical** — don't inflate severity; save it for things that will cause real failures

---

## Sources

- NeoLabHQ/context-engineering-kit — multi-agent review, confidence+impact scoring
- Trail of Bits — audit-context-building, anti-rationalization rules
- Addy Osmani — 5-axis code review framework
