PR Review

How Critique reviews pull requests on GitHub — triggers, pipeline stages, verdicts, and what gets posted back.

Critique installs as a GitHub App. When a pull request on a connected repository is opened or updated, Critique runs a structured review and publishes results on the PR.

How a review is triggered

Trigger	What happens
Automatic	`pull_request` events (open, sync, reopen, ready for review) on connected repos
Manual	`@critique /review` in a PR comment
Dashboard	Rerun from a review run page (if policy allows)

GitHub delivers webhooks to Critique; Critique acknowledges quickly and processes work asynchronously so GitHub never times out waiting for models or sandboxes.

Pipeline at a glance

flowchart TD
  A[PR event] --> B[Evidence gathering]
  B --> C[Parallel specialists]
  C --> D[Synthesis and verdict]
  D --> E[GitHub check + comments]

Evidence gathering collects the diff, relevant files, repository guidance (for example AGENTS.md, README, architecture notes), and risk hints (auth, billing, API paths, test coverage signals).

Specialists run in parallel, each focused on one concern:

Specialist	Focus
Security	Auth, injection, secrets, trust boundaries
Tests	Coverage gaps, missing assertions, risky changes without tests
Architecture	Module boundaries, client/server mistakes, coupling
Performance	Obvious regressions, async pitfalls, expensive patterns

Each lane combines fast deterministic signals with model analysis where configured. See Specialists for more detail without implementation internals.

Synthesis merges overlapping findings, assigns severities, and locks a verdict according to your policy strictness.

When sandbox analysis is enabled for a repository, long-running work (clone, collectors, optional in-sandbox authoring) runs in an isolated environment; if that path is unavailable, Critique falls back to GitHub API–based analysis so a review still completes.

Verdict levels

Verdict	Meaning
`PASS`	No blocking findings under your strictness setting
`WARN`	Findings exist; check may warn without blocking merge
`FAIL`	At least one finding meets your fail threshold — check can block merge if required in branch protection

Default strictness is FAIL: only high-severity findings fail the check; lower severities may still appear as warnings. Loosen strictness to WARNING or INFO when you want advisory-only reviews.

What appears on GitHub

Check run — Status in the PR Checks tab; can be required in branch protection.
Summary comment — Verdict, highlights, link to the full run in Critique.
Inline annotations — File and line comments where findings map to the diff.

Signed-in users can open the same run from the dashboard or the public review-run link in the comment.

Customising behavior

Per installation or repository you can configure:

Which specialists run
Strictness and path-based escalations (force extra specialists on sensitive paths)
Optional model overrides for lead, specialists, and Remedy
Whether dashboard reruns are allowed

See Policy fields.

Re-trigger a review

Type @critique /review in any PR comment to queue a fresh run. Each full rerun consumes credits like an automated review.

Credits

Full pipeline runs consume credits based on models used and work performed. Lightweight bot mentions cost less. See Billing & credits.

Getting started
@critique bot
Event-driven pipeline — async processing overview