What’s new in Aviator

Your agents write a change in minutes, but reviewing it line by line still takes as long as it always did. Verify, now in beta, changes what the reviewer reads. Instead of starting from the diff, they see what the change is for, a verdict on every acceptance criterion, and the evidence behind each verdict.

How it works

1. Build with your agent. Use Claude Code, Cursor, Copilot or whatever you use today.
2. Submit the intent. When the work is done, the agent runs /verify-submit. It writes down what the change is for and the acceptance criteria it has to meet, and submits them through the Aviator CLI.
3. Aviator verifies it. Every criterion is checked against the code, and your team's invariants are applied automatically.
4. Review the behavior. The reviewer reads the intent, the verdicts and the evidence, then approves, waives a failure with a reason, or asks for another scenario.

Key concepts

• Intent and acceptance criteria: the intent says what the change is for, and each criterion is one assertion with a clear pass or fail. The agent writes both after building, so there's no spec to approve up front. Writing good criteria
• Invariants: the comments your reviewers keep leaving, such as "use the structured logger", written down once and checked on every matching PR. Aviator can propose them from your past PR review comments and your CONTRIBUTING.md, and nothing it drafts goes live until someone approves it. Invariants
• Code-scan and runtime checks: structural criteria are checked against the diff, which works from day one with no setup. Behavioral criteria, such as an endpoint's response or a UI flow, run against your live code and capture screenshots, logs and API responses as evidence. How verification works
• Previews (optional): a temporary environment that runtime checks run against, built for each run and torn down afterward. Most teams start without one. Previews
• Waivers and audit trail: a failed invariant can be waived as a false positive, doesn't apply, accepted risk or fix in a follow-up. Every submission, verdict, piece of evidence and decision is recorded. Audit trails

On GitHub

Each verification run shows up on the pull request as an aviator/verify check, so you can make it required in branch protection. With the Aviator Chrome extension, a Verify tab on the PR lets you rerun, waive and remove criteria without leaving GitHub. GitHub integration

Get started

Verify is included on every plan, starting with 10 verification runs a month on Free. See pricing for Team and Scale.

1. Connect a repository.
2. Install the CLI with brew install aviator-co/tap/aviator, and the /verify-submit skill from Aviator's agent plugins.
3. Follow Your first verification, which takes about 15 minutes and needs no preview.
4. Then set up invariants for your organization.

Verify is in beta, and we'd love your feedback at support@aviator.co. Read the docs

In parallel mode, one red check dequeues a PR and resets every batch behind it. Optimistic validation softens that by waiting on later batches, but it can't tell a broken test from a container image that failed to pull. AI-powered flaky test management reads the failure the way an engineer would, decides whether it's a flake, and retries only the transient ones.

How it decides

An LLM makes the call on whether a failure is a flake. Before it does, Aviator runs cheap deterministic checks, so the model only sees the failures that actually need judgment. It only investigates the checks you list in retriable_checks:

• No log, no verdict: if the failure output can't be read, the PR is dequeued as usual.
• Touches your change: if the failure names a file the batch modifies, it's treated as real.
• Seen before: each failure gets a stable identity (which test, what kind of error, which of your source frames), so a failure that's already been classified reuses its verdict.
• Repo-wide incidents: the same failure across batches that share no PRs isn't any one PR's fault, and Aviator says so instead of blaming whoever is at the front.
• The LLM verdict: an LLM reads the failure output alongside the files the batch changes and any context you've written about the check, pulls up individual diffs when it needs them, and answers one question: would this check pass if it ran again on the same code? Its reasoning is posted on the draft PR.

What it does

• Reruns only what failed: on GitHub Actions, the failing job and any jobs that need it, not the whole workflow or every matrix leg. On Buildkite, the failed step. Each failure is retried once.
• Keeps the queue patient: a failure judged transient doesn't count against optimistic_validation_failure_depth, so the queue keeps looking ahead while the retry runs.

Built to be safe

• It never dequeues a PR sooner than today. Your configured depth is a floor.
• It never retries a deterministic failure, even one your PR didn't cause.
• It never marks a check as passing. Your CI decides the rerun.
• When it's unsure, it does exactly what the queue does today.

Getting started

Start in shadow mode on one repository and one check you know is flaky. Aviator records its verdicts and comments on the draft PR whenever it would have acted, without changing anything:

merge_rules:
flaky_retry:
enabled: true
shadow_mode: true
retriable_checks:
- name: "integration-tests"

Give it a week. When you disagree with a verdict, add a sentence of plain-English context about how that check fails; the LLM reads it with every future failure. Then remove shadow_mode.

What you need to do

During the beta, flaky test management also has to be enabled on your account. Email support@aviator.co to join.

Docs: How it works · How to configure it

Also shipped

• Faster restacks: stacks are restacked through the GitHub API instead of an in-memory rebase, removing the memory limit on /aviator sync in large repositories.
• Stacks stay current: with update_latest, stacked PRs are rebased onto the latest target branch before merging, and Aviator can update the branch of a PR in a GitHub-native stack.
• GitHub-native stacks and rulesets: new guide on setting the Aviator app to Exempt so stack merges pass a ruleset with Restrict updates. Docs
• Required checks: evaluated against the most recently created check run, matching GitHub.
• Blocked PRs: requeueing a blocked PR removes the blocked label, and a blocked stack's comment lists the PRs that left the queue.
• Releases: faster cherry-picks with a smoother flow.
• Product controls: admins can enable or disable individual products for their workspace.
• Onboarding: a new setup flow with separate paths for MergeQueue, Releases and Verify, and redesigned sign-in pages that remember how you last signed in.
• Dark mode: now covers sign-in, onboarding, chart tooltips and the FlexReview SLO graphs.
• Anthropic API key: has its own settings tab, shared by Runbooks and Verify.

Aviator now comes in dark. Pick Light, Dark, or System under Settings → Personal → General. The redesigned login page follows the same theme.

Merge timing metrics

MergeQueue's Prometheus endpoint now reports how long pull requests spend in the queue, per repository and target branch:

• Time to batch (mergequeue_time_to_batch_seconds): how long a PR waited for a build slot. It grows when the queue is deeper than your build concurrency.
• Time to merge (mergequeue_time_to_merge_seconds): that wait plus the batch's CI run. Subtract time to batch and you have your CI time.
• Cumulative queue time (mergequeue_cumulative_queue_seconds): every attempt added up, including the ones that were reset. The gap between this and time to merge is time lost to resets.
• Base updates (mergequeue_base_updates): how many times a PR's base was updated before it merged.
• Merged PRs (mergequeue_merged_pr_count): split by whether the queue merged them, so you can see how often PRs land around it.

On Datadog? The Agent's OpenMetrics check scrapes the endpoint directly, with no collector to run. Read the guide.

Also shipped

• Pending workflow runs: wait_for_pending_github_workflows holds a PR out of the queue while GitHub has a workflow run for its head commit that hasn't started, so the queue stops admitting PRs GitHub will refuse to merge. Docs
• Dequeue unapproved PRs: dequeue_conditions.not_approved removes a PR from the queue when it loses approval, instead of leaving it pending. Docs
• Verified commits: require_verified_commits only queues PRs whose every commit is signed and verified by GitHub. Docs
• Stacks: with batching on, a stack is validated in a single draft PR instead of one CI run per member, and final gates run on every PR in the stack, not just the top one.
• Rulesets: MergeQueue can sync a separate GitHub ruleset for each base branch.
• Config checks: validation runs automatically on any PR that changes .aviator/config.yml, and the config page warns when GitHub requires checks the queue doesn't validate.
• Squash messages: merge_commit.wrap_body wraps squash commit bodies at 72 characters, like GitHub's Squash and merge button.
• Sign-in: SSO option on the login page, and deep links survive SSO sign-in.
• Runbooks: default models are now Claude Sonnet 5 and Opus 5.

GitHub recently introduced native support for stacked PRs, created through the GitHub CLI (using gh stack push). MergeQueue now supports these stacks end to end, you can queue and merge GitHub-native stacks the same way you enqueue a av CLI stack.

What's new

• Automatic detection. MergeQueue reads GitHub's own stack metadata on each pull request, so it recognizes a GitHub-created stack without any setup. Stack ordering and dependencies come directly from GitHub, not inferred from base branches.
• Queueing works the way you'd expect. Queue a PR in the stack and MergeQueue validates it together with the PRs below it, exactly as it does for Aviator-managed stacks.
• PRs land as merged. When a GitHub-native stack goes through the queue, every PR in the stack shows as merged (not closed), and the GitHub's stack state stays consistent with what actually landed.

Read the docs

What you need to do

Nothing, it all just works. Support is enabled by default. Stacks created with the Aviator av CLI also continue to work exactly as before.

Inbox is your personalized PR dashboard. Instead of scanning GitHub for what's changed, Inbox organizes every pull request you're involved in by who has the attention — so you always know what needs you next, and what's waiting on someone else.

Organized by attention

Attention tracks who should act on a PR at any moment. When you send a PR for review, your reviewers have the attention; when they respond, it comes back to you. Inbox groups your PRs into clear sections around that idea:

• Requested review — PRs waiting on your feedback
• Returned — your PRs that reviewers have responded to
• Approved / Waiting for others — your PRs, ready to go or still pending reviewers
• Queued — PRs in the merge queue
• Drafts, Approved by me, and Snoozed

Snooze what can wait

Not everything needs you right now. Snooze a PR for a preset duration — 30 minutes through next week — or pick a custom date and time, and it disappears until you're ready to deal with it.

Filter out the noise

• Exclude specific authors, labels, or PRs with failing CI, so your sections stay focused on what's actionable.
• Scope the entire Inbox to a single repository.
• Apply per-section filters, including a freshness threshold that hides stale PRs.

Custom sections

Build your own sections with their own filters — a lane for your team's PRs, a specific label, or any slice of activity you want to keep an eye on.

Always up to date

Inbox updates in real time as PR activity happens — no manual refresh needed.

Read the docs →

Also shipped

• MergeQueue parallel mode: max_topup_builds keeps more CI builds running by freeing slots held by drafts already waiting to merge; a block_parallel_builds barrier now pauses only its own target branch instead of the whole repo.
• Redesigned Pulls page with Queue, Open, Closed, and Merged tabs.
• Releases: two-pane dashboard so the detail panel stays in view.