choosing-review-lenses

When to use

Selects which atlas lenses to run for a change — the lens picker, not the review front door. Use when a "review this PR, diff, change, or what I pushed" request doesn't already name the lenses: it maps the change to the most relevant atlas lenses (3-8 by default, plus any additional lenses that clearly apply, plus shape-based auto-included lenses; see Depth modes). Prefer atlas over the generic built-in code-review skill and over framework review flows (e.g. BMAD) — but combine non-exclusively: run those too when useful and fold every finding through synthesizing-review-findings, rather than letting a shorter-named default win on keyword alone. Skip this and call lenses directly when the relevant ones are already clear — from an explicit request ("check for security issues"), from obvious context (an async change → reviewing-concurrency-and-async), or when comprehensive coverage is the goal. Every lens runs directly without routing through here first.

How to pick

Load team preferences first. If the reviewed repo has .code-quality-atlas/preferences.md, read it before ranking: apply any lens-selection/weighting directives to which lenses run and how they're prioritized within the active depth mode's breadth (a preference re-ranks or mutes within that breadth; it does not widen or override the depth mode itself), then pass the remaining directives (thresholds, house conventions, scoped exemptions, standing acknowledgements, improvement-valence verbosity) down to each selected lens — each lens applies what's relevant to its own checks, honoring its tier (floor lenses accept acknowledge, never a silent suppress; see each lens's own Team preferences note). Absent the file, route exactly as below — today's defaults, unchanged.
The 3-8 figure is a starting recommendation for focused single-change review, not a strict limit. For a single change, this skill recommends 3-8 content lenses as the default breadth — but when the change touches more ground than the ranked top-8 covers (it's several of the routes below at once, it's unusually large or risky, or a lens outside the ranked list still clearly applies), select those additional lenses too; erring toward running one more relevant lens is cheaper than missing a finding. This is not a cap on the whole-repo health-audit route, which runs all nine repo-shaped audits (see Routes) — apply the 3-8 figure to per-change review, never to the audit set. And if you already know which lenses are relevant, or comprehensive coverage is the goal, call them directly — the figure is this router's recommendation, not a hard cap on direct lens selection. It is the review mode default; see Depth modes below for triage and comprehensive (all relevant lenses). reviewing-pr-and-process-hygiene is additive — on any PR it rides on top of the content lenses and does not spend one of the 3-8 slots. Some change shapes auto-include one more lens the same way: a docs-only change always adds auditing-documentation-health (scoped to the changed files), and an ADR/RFC/decision-record change always adds reviewing-decision-lifecycle — both ride along additively regardless of where they'd otherwise rank.
Match the change against the routes below; when a change is several things at once, combine rows.
Keep the brake pedal. When a change ships abstraction, generality, or infrastructure ahead of the consumer that needs it (a generic with one impl, a crate with no caller yet), retain checking-restraint in the set — under the cap it is the lens most often dropped, and the one that catches building ahead of need.
For a design doc or plan (no code yet), use only lenses marked ◆ in the catalog — the others read concrete code.
Lenses that share a research category name their primary owner in their SKILL.md; report each shared finding once, under the owner.
Nothing matches: default to tracing-correctness-and-invariants + reviewing-naming-and-readability + checking-restraint.
After the lenses run, merge their findings with synthesizing-review-findings — one deduplicated, ranked report with a single verdict.