code-review

name	code-review
description	Comprehensive multi-lens code review with presets and a synthesized, prioritized verdict. Use this skill whenever you want existing changes assessed - review PRs, branches, diffs, or sets of changed files with multiple independent lenses (correctness, performance, security, etc).

Code Review — multi-lens convoy

A single read-through finds whatever the reader happened to be thinking about. Real review coverage comes from looking at the same diff through several independent lenses, then merging the findings. This skill runs that convoy and synthesizes one prioritized review.

Step 1 — Resolve the target and scope

Figure out what's under review:

• PR number → gh pr view <n> and gh pr diff <n> for the diff and changed files.
• Branch → diff against the base branch (usually main): git diff main...<branch>.
• File glob → the matching files / their working-tree diff.

Note the scope: how many files, how many lines, what kind of code (core path? security surface? pure refactor?). Scope drives both the preset and the execution mode below.

Step 2 — Pick a preset

Presets select which lenses run. Each lens is fully specified in references/review-lenses.md — read that file before reviewing.

Preset	Lenses	When
gate	wiring, security, smells, test-quality	Fast pre-merge gate; light automatic flow
full	correctness, performance, security, elegance, resilience, style, smells, wiring, commit-discipline, test-quality	Major feature; thorough review (default for large changes)
security-focused	security, resilience, correctness, wiring	Auth, crypto, input handling, sensitive changes
refactor	elegance, smells, style, commit-discipline	Reviewing a refactor (behavior unchanged)
custom	user-specified subset	User names the lenses they want

If the user didn't specify, infer: small/quick ask → gate; "thorough"/large feature → full; security-sensitive → security-focused; pure refactor → refactor. State which preset you chose and why.

Step 3 — Execute (adaptive)

Match effort to scope — running ten subagents on a three-line diff wastes the user's time and tokens; reading a 4000-line diff single-threaded misses things.

• Small scope (a few files, modest diff) — run the selected lenses yourself, sequentially, in one pass. You hold the whole diff in context; spawning subagents would only add latency.
• Large scope (many files / large diff, or the full preset on a substantial change) — fan out: spawn one subagent per lens in parallel (one message, multiple Task calls), each given that lens's prompt from references/review-lenses.md plus the diff/target. Each subagent writes its findings to a file (e.g. .reviews/<id>/<lens>-findings.md). Parallelism is the point — the lenses are independent, so they should run concurrently.

Each lens produces findings structured as: Summary, Critical Issues (P0, must fix before merge), Major Issues (P1, should fix), Minor Issues (P2, nice to fix), Observations (non-blocking). Every issue carries a specific file:line reference and a suggested fix. Findings without a location aren't actionable.

Step 4 — Synthesize

Combine all lens findings into one review. Do not just concatenate them:

• Deduplicate — issues found by multiple lenses are reported once, noting which lenses flagged them (that's a strength signal, not redundancy).
• Prioritize — by impact then effort. P0s first, regardless of which lens found them.
• Decide — give an explicit merge recommendation.

Output (always use this structure):

# Code Review: <target>

## Executive Summary
Overall assessment and explicit merge recommendation (merge / merge after P0s / do not merge).

## Critical Issues (P0 — must fix before merge)
- `file:line` — issue, impact, suggested fix. (lenses: …)

## Major Issues (P1 — should fix before merge)
- grouped by theme

## Minor Issues (P2 — nice to fix)
- briefly listed

## Wiring Gaps
Dependencies/config added but not actually used (from the wiring lens).

## Commit Quality
Notes on commit atomicity and messages.

## Test Quality
Whether the tests meaningfully verify behavior (coverage numbers lie).

## Positive Observations
What's done well — worth saying, and it calibrates the rest.

## Recommendations
Concrete, ordered next steps.

Working on a beads issue

When the change under review is tracked by a beads issue (the user names one — "review proj-7f" — or the PR is bead-linked), record the review on that bead: put the verdict and the blocking items in its notes so the outcome lives with the work, not just in a chat reply.

That's the only beads-specific behavior here. This skill doesn't manage beads itself — a separate skill covers bd usage and any follow-up issue filing — and doesn't require it: with no bead in play, the Step 4 synthesized markdown is the deliverable.

Reference

• references/review-lenses.md — the full prompt for each of the 10 lenses and the preset definitions. Read it before Step 3.