Checkpoint
Pre-review trust gates that block or flag low-signal pull requests before automated AI review runs.
Checkpoint runs before the main review pipeline on pull requests you enable it for. It applies fast, deterministic checks — contributor signals, PR shape, boilerplate patterns — so you do not spend credits reviewing obvious spam, empty drive-by PRs, or AI-slop templates.
Marketing overview: critique.sh/checkpoint. Configuration lives in Dashboard → Checkpoint and per-repo at /dashboard/[owner]/[repo]/checkpoint.
When it runs
Checkpoint evaluates a PR at gate time (typically when the PR becomes eligible for Critique automation). Outcomes are recorded as gate events you can inspect in the dashboard, including which rules passed or failed.
Checkpoint does not replace the security or architecture specialists — it filters who and what deserves a full review.
Example rule categories
Rules are toggled per repository. Common categories include:
| Category | What it checks (conceptually) |
|---|---|
| Identity & account | Profile signals, account age, public activity |
| PR shape | File count, description quality, daily PR velocity |
| Content quality | Boilerplate phrases, weak commit messages, incoherent large diffs without context |
| Hygiene | Repeat offenders, optional language or test requirements |
Exact defaults evolve; the dashboard rule catalog is authoritative for your installation.
Outcomes
Each event resolves to an outcome such as allow, warn, or block (labels may vary in the UI). A block stops or defers expensive downstream review until a human overrides or the PR is fixed.
Operators can override a specific gate event from the event detail page when a false positive should proceed.
Configure Checkpoint
- Open Dashboard → Checkpoint for a cross-repo view, or a repo’s checkpoint page for rules.
- Enable the rules that match your risk tolerance (stricter for public OSS, looser for trusted internal repos).
- Watch gate events for the first week and tune — start with account age, file count, and AI-slop patterns if noise is high.
Relationship to review policy
| Layer | Question it answers |
|---|---|
| Checkpoint | Should we spend review effort on this PR at all? |
| Review policy | How hard should we judge findings (strictness, specialists, models)? |
See Policy fields for review-side configuration.