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.

Agent orchestration (API)

When coding agents open PRs at high volume, use Checkpoint as a cheap filter and the Merge Gate API for the expensive judgment pass.

Step	Mechanism
1. PR opened (by human or agent)	GitHub → Critique (automatic) or your orchestrator
2. Checkpoint evaluates	Webhook `checkpoint.gate.evaluated` if subscribed
3. On allow/warn (your policy)	`POST /api/v1/reviews` or wait for automatic review
4. On block	Stop merge loop; override in dashboard if false positive

`checkpoint.gate.evaluated` webhook payload (summary)

Delivered to installation webhook endpoints (Critique-Lifecycle-Webhook/1.0) when Checkpoint runs:

Field	Meaning
`outcome`	Gate result (allow / warn / block — exact strings in payload)
`mode`	Checkpoint mode for the repository
`actionTaken`	What Critique did (for example deferred review, posted check)
`pullRequest.number`, `pullRequest.headSha`	PR identity

Subscribe via POST /api/v1/webhook-endpoints with events: ["checkpoint.gate.evaluated"]. See Merge Gate API — Checkpoint first.

Orchestrator pseudocode:

on checkpoint.gate.evaluated:
  if outcome == block: halt agent merge pipeline
  elif outcome == warn: queue POST /api/v1/reviews
  elif policy.requiresReviewOnAllAgentPrs: queue review anyway

Merge Gate API — full webhook and queue reference
PR review — what runs after Checkpoint passes
Policy fields — review strictness (separate from Checkpoint rules)

Checkpoint

On this page