AI review settings
Auto review and related repositories for each workspace.
On this page
The AI review tab holds two settings for the current workspace: Auto review, which reviews new pull requests without anyone pressing a button, and Related repos, which lets a review read code in the repositories a change depends on. Each workspace has its own settings. What a review does is explained in AI review; this page lists the switches.
#Auto review
When Review new PRs automatically is on, Limn reviews each new pull request a person opens in this workspace, with the provider chosen under Auto reviews use. It is off until you turn it on.
- Only pull requests a person opens after you turn it on are reviewed. Pull requests opened by bots are skipped.
- Drafts wait until they are marked ready.
- A reviewed pull request is reviewed again when new commits are pushed, or when a person or a review bot adds review comments. Limn’s own comments never start a review. Pushes and comments that arrive close together wait until the pull request has been quiet for 5 minutes (20 minutes at most).
- Re-reviews count towards the daily limit, auto reviews a day (UTC): 20 unless you change it (1 to 500). The rest wait for the next day. Reviews you start yourself are not limited.
More on how auto review decides when to run: Auto review.
Status on GitHub
Each auto review puts a status on the pull request’s latest commit, such as limn/review-claude. A teammate’s Limn then skips a commit someone is already reviewing with the same provider. This is always on. Without write access to the repository, Limn reviews without a status.
Auto reviews use
Claude + Codex (the default) runs both providers on the same commit at the same time, each on its own, then merges them into one review. The other choice (for example Claude only) runs the default provider only. If only one provider is signed in, that one runs alone. See Claude and Codex together.
When Claude and Codex disagree sets how one verdict is reached:
- Strict: approve only if both approve (the default).
- Relaxed: approve if one approves and the other raises nothing that blocks.
Either way, if one asks for changes, Limn does not approve.
#What happens when a review finishes
When an auto review finishes has two choices:
- Keep it in Limn: read it in the AI Review tab and post it yourself if you want.
- Post to GitHub (on by default): as soon as it finishes. Reviews you start yourself post only when you choose Review and post.
Which PRs
- Your own PRs, and PRs you are asked to review or have reviewed or commented on (the default).
- Every PR auto review covers.
A review request to a team does not make a pull request yours: Limn does not know which teams you are in.
What to post
Tick what goes into the posted review. Ticked by default unless marked:
- Blockers, Warnings
- Nits (off by default)
- Questions, on the line they ask about where possible
- CI failure reasons, in one PR comment
- SonarCloud issues: on the lines they flag where possible, the rest in the review’s summary
- Story gaps, on the PR they belong to
- Work the story did not ask for (off by default)
#Approve or request changes
With Approve or request changes for me on (the default), a posted review may approve or request changes instead of only commenting. It approves only with no blockers or warnings, only when your last review was a comment, and never on your own pull requests. When it does not approve, it says why, once per commit.
- Approve: tick High impact PRs, Medium impact PRs and Low impact PRs. Impact is the blast radius chip. A pull request at an impact you untick gets a comment-only review. A pull request whose impact Limn could not measure counts as High. See Pull requests.
- Approve with open findings: Only when nothing is left open, When only nits are left, or When only nits and questions are left (the default). Open blockers or warnings always stop an approval.
More detail: Verdicts and posting to GitHub.
#Resolving threads
- While posting is on, when a later auto review finds a posted comment fixed, Limn replies and resolves its thread. This is always on.
- Resolve my Limn threads when addressed (on by default): on your own pull requests, drafts too, when any review you run finds one of your Limn’s comments fixed, Limn replies “Addressed in” and the commit, then resolves the thread. It never touches a person’s thread or a teammate’s Limn thread.
Teammates’ Limn “changes requested”
When a teammate’s Limn posted “changes requested”, every point is fixed at the latest commit and your own review finds no blocker, your Limn dismisses that review and posts its own. This is always on. Whether your review approves is still decided by Approve or request changes for me and the impact boxes. A review someone wrote by hand is never dismissed. See Reviewing as a team.
#Auto AI Fix
Auto AI Fix on your own PRs (off by default) prepares one AI Fix after an auto review of a pull request you opened. It runs only after an auto review, so it is off while auto review is off. Other people’s pull requests are never fixed automatically. At most 3 auto fixes run per pull request a day, and none while a fix is running or waiting to be pushed.
- Always include: choose what the fix works on: Merge conflicts with the base branch (off by default), Limn’s findings (from Claude, Codex or both), earlier findings not fixed yet, Threads my agent says to fix, threads nobody has answered, CI failure reasons, SonarCloud issues, and style bot comments (off by default).
- With Merge conflicts with the base branch ticked, a pull request that conflicts with its base is merged first. Limn checks the merge before any push: two parents and no conflict markers left. A merge that fails the check is never pushed.
- Push automatically (off by default): pushes a finished fix to the pull request’s branch. It is not built or tested first. With it off, the fix waits in the AI Fix tab until you press Push.
See Push the fix, and auto fix.
#Design diagrams
Draw a design diagram after each review draws a design diagram after every review. Turning it off saves about a third of the review’s AI usage. See Design diagrams.
#Related repos
When a change in one repository depends on another (a front end and its API, for example), link them. When AI Review checks a pull request in one repository, it can then also read the code in its related repositories. A link works both ways.
- Under Related repos, select a repository.
- Select each repository its reviews should also read. Arrows show the links of the selected repository.
From each related repository, the review reads the first of these that exists:
- an open pull request on a branch with the same name;
- an open pull request that names the same ticket, such as PAY-142;
- a branch with the same name, with no pull request;
- the default branch, for reference.