review-lenses

Review lenses

You are the review orchestrator. You are the brain; the reviewers are headless workers. Your job: turn a request (prose) into a review plan — a set of jobs, each one (lens × target) — dispatch them, and collate one report.

Review is self-serve. This skill isn't only for when a human types a review request — any agent should invoke it on its own work before handing it back: before finalizing a change, after anything security-sensitive, whenever unsure. It's cheap and read-only, and the report comes back structured so a calling agent can act on the findings directly. Reach for it proactively; you don't need to be asked.

Two axes, kept independent: a lens = what to look for (a file in .review-lenses/); a target = what to look at (a diff, a class, a plan phase, a whole plan, a design doc, an idea). Any lens applies to any target. A job is one lens on one target. See reference/lens-format.md for the lens file format and reference/reviewer-brief.md for the brief you hand each reviewer.

Step 1 — Resolve the request into a plan

Read the request and produce { jobs: [{lens, target, context, level}], mode }. You clarify here because reviewers can't — they run headless. Only ask when genuinely ambiguous; otherwise infer and proceed (use AskUserQuestion for real forks like "phase 3 — the evaluator or the migration?"). AskUserQuestion only works when you're the main-loop agent — if this skill was invoked from inside a subagent (an agent self-reviewing its work), infer and proceed, leaning on UNRESOLVED findings for anything you can't settle.

Find the lenses. The lens directory is $REVIEW_LENSES_DIR if that environment variable is set, otherwise .review-lenses/ at the repo root:

echo "${REVIEW_LENSES_DIR:-.review-lenses}"

REVIEW_LENSES_DIR lets a project point at a custom location; how you set an env var depends on your harness (e.g. in Claude Code, add it to .claude/settings.json under "env"). Read the frontmatter of every *.md in that directory except README.md — take concern, triggers, level. If no lens directory exists yet, say so and point the user at the examples shipped with this skill.

• Directed request ("review the testing of X") → the named lens(es), regardless of triggers.
• Auto request ("review this branch") → triggers are a starting point, not the whole selection. Do two passes:
  1. Triggers matched → run it. Any lens whose triggers globs match a changed path is in — that's the floor.
  2. Concern reads relevant → also run it. Go through the rest of the lenses and read each one's concern; if a lens's concern is clearly relevant to this change even though no glob fired, add it. concern is what you judge relevance on — a lens with narrow or no triggers still applies when its concern fits. Some concerns (comment quality, simplicity) apply to any code-bearing diff — include them whenever code changed.