Docs

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.

Permission profile: review-write — can read the repo and post review comments, but cannot push code.

Pipeline

Review judge the diff Post inline comments

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.