Skip to content
Back to blogPrivacy & Terms
8 min readCritique

Critique Checkpoint: stop slop at the gate

A deterministic PR trust gate that runs before review, before CI waste, and before Critique spends credits.

PR opened

Webhook received

Checkpoint

BLOCKED before review

Critique Review

Skipped - 0 credits burned

pull_request.opened -> account_age failed -> ai_slop pattern matched -> Critique review skipped

Critique reviews code. Checkpoint decides whether the pull request should reach review in the first place. That sounds like a small distinction until your repo gets flooded by accounts created yesterday, boilerplate PR descriptions, drive-by formatting diffs, and contribution spam that should never consume a human maintainer or an AI review lane.

The first version of Checkpoint is deliberately boring in the best way: deterministic rules, GitHub metadata, repository policy, and explicit maintainer overrides. No agents run inside Checkpoint. No model is asked to judge the change. It is a gate, not a reviewer.

Why this exists

Critique was built for deep pull request review: specialist lanes, sandbox evidence, policy enforcement, and merge-quality verdicts. That is powerful, but it is not the cheapest possible tool for every PR-shaped object that appears in an inbox. Some contributions fail before code understanding is even relevant.

A slop PR that trips obvious intake rules should not burn review credits. It should not start a sandbox. It should not page a maintainer. Checkpoint moves that decision upstream: PR opened, Checkpoint runs, and only then does Critique review begin if the gate allows it.

Before
PR opened→Critique review queues→Credits burn→Maintainer sees noise
With Checkpoint
PR opened→Checkpoint evaluates→Pass or block→Critique reviews only what clears the gate

What Checkpoint checks

The MVP ships with a rule catalog that covers identity, activity, and content shape. Maintainers can run rules in Dry Run, Warn, or Block mode, and can turn Critique review off after a pass when they want Checkpoint as a standalone intake product.

Identity signals
  • Account age threshold
  • Required profile picture
  • Profile README check
  • Public repository minimum
  • Fork freshness
Activity signals
  • Merged PR count
  • Max PRs per user per day
  • Prior blocked events
  • Allow and block lists
Content signals
  • AI slop patterns
  • Commit message quality
  • Max files changed
  • Diff coherence
  • Linked issue and test-shape rules

How it fits into Critique

Checkpoint lives inside the same GitHub App and dashboard as the rest of Critique. A repository policy controls the rule set, mode, allow list, block list, and whether a passing gate should queue a full Critique review. The event log shows exactly what happened for every PR: author fingerprint, values observed, thresholds configured, rules triggered, and the GitHub check action taken.

Checkpoint and Critique solve different parts of the PR pipeline
LayerQuestionMechanism
CheckpointPre-review gateShould this actor and PR shape reach review?Deterministic GitHub metadata and pattern rules
Critique ReviewDeep reviewShould this code ship?Multi-agent analysis, sandbox evidence, and repository policy
RemedyRepair loopCan Critique produce a patch for the finding?Bounded fix attempts with validation

Checkpoint is cheap and instant. Critique review is deeper and intentionally more expensive.

Modes matter

Recommended rollout
  1. 1
    Start in Dry Run
    See what would have been blocked without changing contributor behavior.
  2. 2
    Move noisy rules to Warn
    Publish the signal in GitHub while preserving review flow for active repositories.
  3. 3
    Use Block for high-confidence rules
    Fail the Checkpoint check and skip review for cases like explicit block-list matches or repeated slop patterns.
  4. 4
    Allow trusted contributors
    Use the event detail page or override list so known humans and bots move through cleanly.

The governance point

Contributor gates can be unfair when they are used bluntly. Profile pictures, public repo counts, and account age can penalize new developers, private contributors, or people who intentionally keep sparse public profiles. That is why Checkpoint ships with dry run, warn mode, transparent evidence, and maintainer overrides instead of pretending every trust signal is universal truth.

The right use is not to keep new contributors out. The right use is to make maintainers spend scarce attention on plausible contributions, while giving them a clear path to trust people who deserve it.

Standalone by design

Checkpoint can run without Critique review. That matters for repositories that want a cheap GitHub intake gate now, or open source projects that are not ready to run full AI review on every PR. Turn off "Run Critique review after pass" and Checkpoint still posts the GitHub check, stores the event, and gives maintainers the dashboard log.

Enable Checkpoint on a repository

Start in Dry Run, inspect the event log, then promote only the rules you trust to Warn or Block.

Open Checkpoint
← All essaysPrivacy & Terms

Ask about this essay

Nemotron-3-Super
Ask about the argument, the evidence, the structure, or how the post connects to Critique.
Not editorial advice · The essay above is the source of truth · Not saved to your account · OpenRouter privacy