PR review

PR review reads the PR diff in full context and reasons about it statically — this is a pure code review: it does not install, build, or run the code (CI validates that the change actually works). It runs in two phases: an agent phase judges the diff and records its findings, then a deterministic phase posts one formal review with each finding as an inline comment anchored to its diff line (with an applyable suggestion where a concrete fix fits). A finding whose line isn't in the diff is folded into the review summary instead.

The review is precision-first: only high-signal Critical and Important findings are posted — each with a concrete impact (what breaks, for which input) and put through a self-refutation confidence gate — while lower-value suggestions and nits are dropped, because a noisy reviewer gets muted. A clean PR is approved with few or no comments.

Pipeline

What it checks

• Implementation correctness against the PR description
• Test coverage for changed code
• Security vulnerabilities (OWASP top 10)
• Code style and naming consistency
• Error handling and edge cases

Triggers

When a review runs is an operator (and per-repo) decision — review.trigger, which ships after-checks. Every route below crosses the same gate, so the mode has one meaning everywhere.

• GitHub webhook: pr.opened / pr.synchronize / pr.reopened, and Ready for review on a draft — under eager. Under after-checks these defer and the review instead runs once the head SHA's checks settle, either colour
• By request: the review.requestLabel label, an @last-light review comment, a review requested from the bot, or Re-run on the last-light/review check. An explicit request always runs — it overrides the mode, the draft skip and the "already reviewed this commit" check
• Cron sweep: every 30 minutes, including when webhooks are configured. It is the only route that reaches a PR whose fix chain stopped without pushing a commit, since no further check-suite event will fire for it
• Slack: review cliftonc/repo
• CLI: npm run cli -- review owner/repo

Skipped without a run: draft PRs (review.skipDraft, matching what the sweep has always done), a commit we already reviewed, and a PR another Last Light run is currently working on — reviewing a tree a fix run is rewriting produces a review that is stale before it lands. All three are read off one resolved snapshot of the pull request, and the last-light/review check each decision leaves behind differs; see the PR state model.

How much review a re-review is owed

A second review of the same pull request is priced by how much the change actually moved, not by the fact that the commit did. Three tiers, and the first two ship on:

• No review. A push whose own diff against the base is byte-identical to the one we already reviewed — a merge from main, a rebase that preserves the tree, an empty force-push — is skipped, and the standing verdict is repeated on the new commit. So is a push that touched only generated files. See review.skipUnchangedDiff and review.generatedPaths.
• A light review. For a real but small delta, one cheap pass decides the rest of the run is not worth re-deriving, and the reviewer makes a single focused pass over what changed since the last review — a new defect, a flagged point the delta claims to fix but does not, and one it genuinely fixed. See review.triage.
• The full review. Everything else, and every uncertain case: a large or spread-out delta, anything touching an interface, a schema, auth or error handling, and any answer the triage pass was unsure about.

A first review of a pull request is never affected by any of this, and an explicit @last-light review always buys the full one.