From the ticket to the merge: everything Auditor does now

Until this week Auditor started when a pull request opened and stopped when it was reviewed. The work on either side of that, deciding what to build from a ticket, answering the questions a reviewer has, getting tests written and getting the branch mergeable, was still yours.

All of the features below shipped on November 4, 2026, for every team with Auditor. Each section says what it does and links its docs page.

Working from the issue

Most work starts as an issue, so this is where Auditor now starts too.

In Linear. Connect Linear under Add-ons › Issue trackers on the Auditor page, then mention @Auditor in a comment on an issue, or assign the issue to it. Linear opens an agent session, and Auditor shows it's working within a few seconds. Ask it whether the pull request is ready to merge, have it write a plan, or have it make the change: it opens a pull request ending Fixes ENG-412, which Linear links back to the issue. Each Linear issue is one conversation, so a follow-up continues from the earlier work.

Anyone in the workspace can get answers and plans. Who can also have it change code is your choice: anyone, people on an allow list (your team's members, email domains or addresses you name), or no one. Each reply has a spending limit, and there's a monthly limit on top.

On GitHub issues. Mention @auditor on an issue and say what you want, as you would to a teammate. @auditor how would you approach this? gets a plan: what changes, which files and functions, what it leaves out, how it's tested, and its questions. @auditor fix this, keep the old endpoint gets the change, checked in a sandbox before the pull request opens with Fixes # the issue. When it can't tell whether you want the change made, it plans and asks. Push back on the plan, then say go ahead.

Both run as your team's Issue assistant, an automation created the first time someone uses it, so you can change its instruction, model and budget, and every conversation is listed on the Automations tab.

The ticket check, on the ticket. Reviews already compare a pull request with the issue it names and list up to three things the issue asks for that the change doesn't do. With Linear connected, that finding can be posted on the Linear issue too, so whoever wrote the ticket sees it without opening GitHub. It's one comment per pull request, edited on later reviews, and it never fails the check.

Asking about a pull request

Any comment on a pull request that mentions @auditor and isn't a command is now a question: @auditor what else calls chargeCustomer?, or is this migration safe to run on a live table, @auditor?. Auditor reads the pull request, its diff, the conversation and its open findings, then reads and searches the repository at the pull request's head and cites the files it relied on. On a line of the diff, "this" means the code on that line.

A question never changes code. To have findings fixed, @auditor fix still does that.

Merge checks in plain English

Some rules apply to the pull request itself, not to the code in it: a migration needs a rollback note, the title has to say what changed. Merge checks let you write those in plain English:

mergeChecks:
  - name: Rollback note
    instructions: A change to a migration says in the description how to roll it back.
    paths:
      - migrations/**
    mode: error
  - name: Clear title
    instructions: The title says what changed, not only a ticket number.

Auditor checks them on every push and every edit of the title or description, and reports them as a GitHub check of their own, Auditor merge checks, with a one-line reason for each. A failed error check fails it; warnings and checks it couldn't decide leave it neutral. Require it in branch protection to block merging. @auditor checks runs them again.

Tests and merge conflicts on request

@auditor tests writes unit tests for what the pull request changes, following how the repository already tests. You can add what to focus on, as in @auditor tests the retry path. It only creates and edits test files, never the code under test, and runs them in an isolated sandbox with Vitest, Jest or pytest, or your own command. If they fail, it fixes the tests and tries again, up to three rounds in all. Passing tests go where your fixes go. Tests that still fail come as a draft pull request with the output, never onto your branch.

@auditor resolve conflicts merges the base branch in. A file that only one side changed takes that side. A file both sides changed is merged line by line, and only the lines that still conflict go to the model, along with the pull request's description and the base branch's commit messages, so it can keep both changes. The result is a real merge commit on your branch, and each file's resolution is explained in the reply. If any conflict needs a decision only a person can make, nothing is committed, and the reply says which files need you.

Settings that live in the repository

A repository can keep its review settings in .auditor.yaml at its root, so changing them goes through review like any other change: when reviews run, what fails the check, review depth, skip rules, merge checks, and whether questions are answered. Auditor reads the file from the default branch, so a pull request can't loosen its own review. Anything that costs money or reaches outside the repository stays on the Auditor page: models, spend caps, trackers and Shopify settings.

Seeing what it did

The new Analytics tab shows, over 7, 30 or 90 days, how often your team acts on findings, how many were posted, what each pull request cost and how long it took to merge, each compared with the period before. What lands lists each kind of finding by how often it's acted on. A repository's page adds every way Auditor was started there (each event, command, question and reply), who started it, what came of it and what it cost, along with every setting in effect and where it comes from.

What it costs

None of this has a seat price or a fee of its own. Every model call goes on your team's Auditor key like a review, and counts toward the same spend caps. The Issue assistant has its own budget for each reply and an optional monthly one. Only people with write access to the repository can run commands or ask questions on GitHub. Anyone else gets a 👎, and nothing is billed.