Review before it ships — against the spec and plan it was meant to follow.
Review Claude's work before it ships — against the spec and plan it was supposed to follow. lens runs inside the live session that produced the code, so it can ask the question no diff-only reviewer can: did this build what was actually asked, and did it follow the plan?
claude plugin install lens@apurvbazari-pluginsNo setup step required. Run /lens:review inside an active session to start a review.
Intent-grounded review across five dimensions
A bug-free implementation of the wrong spec is the failure no diff-only code review bot can catch. lens works on two axes — spec adherence and plan adherence — then layers in correctness, risk, and test gaps. Every finding is adversarially verified before it reaches the report.
Checks each spec item — met, partial, or missing. Flags spec gaps (requirements missed) and scope creep (unasked additions). Supports multiple specs via per-spec adherence fan-out.
Checks each plan step — followed or deviated. Emits a finding plus a review hotspot for every deviation. Supports multiple plans via per-plan adherence fan-out.
Scans for bugs, silent failures, edge cases, and security issues — confirming each against the real source. Only confirmed findings survive the adversarial verify pass.
Tags each changed file with a blast-radius risk class — auth, data, money, migration, concurrency, public-api, or none — and flags high-risk files that lack a test or guard.
Identifies new or changed code paths that lack test coverage and emits a finding per meaningful untested path. Owns the missing-test dimension — not brittle or overfit coverage.
Adversarial verification — the signal filter
Every candidate finding goes through an independent skeptic agent that tries to refute it against the real source. Only unrefuted findings make the final report. Correctness, security, and test claims default to refuted unless proven; spec and plan judgment calls are kept. This is what keeps the signal-to-noise ratio high.
Five stages, one structured review
/lens:review runs a fixed, linear pipeline. Each stage hands a structured artifact to the next. Click a stage for detail.
In-session task tracking gives you live visibility into each stage as it runs — a per-stage task list updates as lens progresses. State is tracked in .claude/lens/review-state.json, which records fixed, open, and new findings and severity trends across runs.
On first review, lens prompts you to set a default gitignore pattern and output path. Subsequent runs read from .claude/lens/settings.md and pick up where history left off.
lens is the brain — walkthrough is the eyes
The review pipeline is separated into two concerns: judgment (what's wrong and why) and rendering (making that legible). lens owns judgment; walkthrough owns rendering.
Runs finders, verifies findings, produces a structured review model (findings + severity + hotspots + verdict).
Receives the structured model from lens and renders it as an interactive HTML review document in the house style.
Interactive HTML when walkthrough is installed — or a self-contained markdown report with identical content when it isn't.
Graceful markdown fallback
lens does not require walkthrough to function. When walkthrough is absent, lens degrades to a self-contained markdown report — same structure, same findings, readable anywhere. Installing walkthrough upgrades the output automatically without changing the review workflow.
Optional adapters can tap into the pipeline. Other review tooling (such as pr-review-toolkit agents) can plug in as read-only adapters constrained to report-only — they can never edit, stage, commit, or block.
Four skills, five finders
lens exposes one user-facing skill and three internal skills. The five finder agents run as part of the pipeline — they are not invoked directly.
| Skill | Invocation | What it does |
|---|---|---|
| /lens:review [target] | user + auto | Intent-grounded review. Runs the full five-stage pipeline against the session diff (or an explicit target — a path, ref, or range). Sets up a per-stage task list for in-session visibility. Writes the review artifact and updates .claude/lens/review-state.json. |
| engine | The core review executor (user-invocable: false). Accepts the structured review context from /lens:review — scope, intent, task IDs — and runs the judgment pipeline: scope → intent → analyze → verify → dedup → rank. Returns a review-findings JSON object. Writes nothing, never prompts, never renders. |
|
| render-review | Pure, write-once render entrypoint (user-invocable: false, but model-invocable). Takes an already-computed review-findings object, reconciles in-memory, assembles the review-model, and renders via walkthrough:render — writing only the caller's output path. An orchestrator that owns persistence (e.g. matali) calls it after engine. |
|
| capability | The compatibility gate a programmatic caller runs before it sends a review (user-invocable: false). Answers which lens is installed and whether it supports a given feature — returning the manifest version (read live, never hardcoded), the advertised capability tokens, and the input keys a caller may rely on. Asking for a token lens does not advertise returns a named error rather than a silent partial run. |
The five built-in finders run in parallel during Stage 3: spec-adherence, plan-adherence, correctness, risk-classify, and test-gaps. Each emits structured findings tagged with its dimension. The verify stage then routes each finding to the verifier skeptic agent.
Settings live at .claude/lens/settings.md. Review state and finding history live at .claude/lens/review-state.json. These are the only files lens ever writes.
What lens is — and isn't
Knowing where lens fits (and doesn't fit) helps you get the most from it.
Reconstructs what the code was supposed to build from the spec and plan, then checks whether it did. No other automated tool reaches this question — spec adherence and plan adherence are its wedge.
lens is a session-time companion, not a pipeline blocker. It doesn't integrate with CI, doesn't run on push, and doesn't block merges.
lens never edits, stages, commits, or deletes code. Its only writes are the review artifact and review-state.json. Adapters are constrained to the same contract.
Linters check style, types, and patterns against fixed rules. lens checks intent: did this change do what the spec and plan required? Those are different questions.
Every finding is challenged by a skeptic agent before it reaches you. Low-confidence or unprovable findings are filtered out — the report reflects only what could be confirmed.
lens produces a review document — a list of findings with verdicts. It does not apply fixes, generate patches, or suggest rewrites. That's deliberate: you read, you decide.