Using Veripsa Core alongside your merge queue

A merge queue and Veripsa Core both touch the path from open PR to merged commit, but they act at different moments and inspect different things.

The gap: a merge queue catches CI-level conflicts when PRs land — but only after review is done and the queue starts running. Veripsa Core surfaces likely cross-PR overlap earlier, while there is still room to change the land order without re-doing work.

Install Veripsa Core once, then keep your existing queue workflow. Checks and comments appear automatically; the controls below are optional choices, not extra installation steps.

• While the PR is open, read the Veripsa check. If it is Clear, carry on. If it is Heads up or Wait in line, look at which other PR(s) are related and prefer the suggested land order — you rebase once instead of redoing work after both land out of order.
• Optionally record a deliberate override with veripsa-ack. Normal advisory use requires no acknowledgement. Use the label only if your team wants an auditable record that a human reviewed this collision snapshot and chose to land. It is not a review approval or a routine per-PR action.
• Let the merge queue serialize the actual merge step. Veripsa Core does not re-run CI in order or guard the final merge commit — that is the queue's job. Once your normal review and queue requirements allow the PR to proceed, the queue does what it does. Only teams that explicitly make Veripsa a required check turn its state into a queue prerequisite.
• If you mark the Veripsa check required, keep merge-queue compatibility enabled. Veripsa Core can render an advisory verdict for GitHub Merge Queue's batched merge candidate. On the merge group it is titled Merge queue: clear, Merge queue: review overlap, or Merge queue: not analyzed. That is how a required Veripsa check stays compatible with the queue rather than stalling it.
• On private repos, marking required needs a paid GitHub plan. Branch protection on private repos is available on Pro / Team / Enterprise. On Free private repos the Veripsa check remains advisory — visible on the PR page but not gated. See Docs §9.

Terse facts about each merge-queue / merge-workflow tool, sourced from each vendor's own public docs. The point is to be specific about where Veripsa Core sits relative to each — we do not editorialise about the tools themselves.

GitHub Merge Queue

The native queue built into GitHub. It serializes the merge step on the protected branch and re-runs the required checks on a merge-group commit. Available in organization-owned public repos; private repos require an organization on GitHub Enterprise Cloud. GitHub docs: managing a merge queue.

With Veripsa Core: the Veripsa check sits earlier (on the open PR); the merge queue runs later (on the batched merge candidate). Veripsa Core can render an advisory verdict for that candidate too — that is what lets a team optionally make the Veripsa check required without deadlocking the queue.

Mergify

A merge queue plus rule-based PR automation. Free for OSS and small private teams; its paid tiers are listed on Mergify's own public pricing page. Mergify docs · Mergify pricing.

With Veripsa Core: Mergify's queue inspects the merge commit and CI; Veripsa surfaces a content-free likely-overlap signal while PRs are still open. If you want the Mergify queue to wait on the Veripsa check, list it among the queue's required conditions on the open PR — Veripsa stays advisory unless you do that.

Aviator

A merge queue built for large monorepos with batched CI. Its paid tiers are listed on Aviator's own public pricing page. Aviator docs · Aviator pricing.

With Veripsa Core: Aviator focuses on getting many PRs through the merge step efficiently via batching; Veripsa focuses on the pre-merge step of choosing a safe land order across the open PRs. Aviator also offers monorepo / cross-service coordination features on its side; Veripsa Core today coordinates within a single repository owned by one account (cross-repo on roadmap, not a present claim).

Trunk Merge Queue

Trunk ships a merge queue alongside its CI and code-quality products. Its public pricing is committer-based, with a free tier and custom enterprise options. Trunk Merge Queue docs · Trunk pricing.

With Veripsa Core: Trunk's queue serializes and batches the merge step; Veripsa Core surfaces the cross-PR collision earlier so you do not pay the round-trip of two PRs landing out of order. The two run in different windows of the lifecycle.

Graphite

Graphite is primarily a stacked-PR review workflow; it also ships a merge queue and AI review add-ons. Its paid tiers are listed on Graphite's own public pricing page. Graphite docs · Graphite pricing.

With Veripsa Core: Graphite's queue still operates at merge time. Veripsa sits earlier: it gives an advisory signal about open PRs that may need ordering attention before they enter a queue.

A few patterns that we've seen create confusion or extra work. None of these are critical — they are just things to know going in.

• Treating Veripsa Core as a merge-queue replacement. Veripsa does not run CI, does not serialize the merge step, and does not produce a merge-group commit. If your repo needs a queue, you still need a queue — Veripsa sits earlier, not in the same slot.
• Treating a merge queue as a substitute for pre-merge collision warning. A queue catches CI-level conflicts when PRs land in order. It does not look across the other open PRs to warn that two of them may need landing-order review before either is approved — that is the question Veripsa Core is built for.
• Marking the Veripsa check required without a branch-protection plan. On private repos, branch protection requires GitHub Pro / Team / Enterprise. On Free private repos the Veripsa check is still useful as an advisory signal on the PR page, but it cannot gate the merge.
• Marking it required before reviewing the signal on your repo. Leave the check advisory first — read several verdicts, see when they are useful and when they are noisy, and only then add it to the required-check list. See Docs §12 for the broader setup notes.
• Expecting Veripsa to coordinate across repositories. Veripsa Core coordinates PRs within a single repository owned by one GitHub account today. Work in separate repositories does not warn across repository boundaries yet. Cross-repository coordination is on the roadmap and is not a present claim.
• Expecting Veripsa to comment on bugs or style. Veripsa Core stores content-free operational metadata, not file bodies, and never comments on code quality. If you want that, pair it with an AI reviewer (see Compare).

• Compare — the broader positioning across merge queues and AI code review.
• Docs — canonical mechanics, including the four verdicts, the event surface, and GitHub-plan dependency.
• Getting started — first check, soft-pause label, and when (if ever) to mark the check required.
• Install Veripsa Core — free to install; works alongside the merge queue you already run.
• What's new — dated public updates when visible Veripsa behavior changes.