Nothing runs until you switch it on. Every capability on a new connection is off. Installing the GitHub App, connecting a GitLab token, or authorising a Bitbucket workspace gives Ankra access, and nothing more: no review is posted, no mention is answered, and no preview is deployed until an organisation admin turns the switch on for that connection or for a single repository.
Connect a provider
Each provider appears as its own card. Connecting one is an organisation admin action.- GitHub
- GitLab
- Bitbucket Cloud
Press Install GitHub App and pick the organisation or user account, then the repositories Ankra may see. You land back on this page with the installation listed.One account can carry several installations, and each is configured separately. See the GitHub integration for the permissions the App requests and how to change which repositories it covers.GitHub is the only provider that also offers PR preview environments.
AI mode: Ask or Agent
Every connection carries an AI mode that bounds what the AI may do when it is talked to from that repository. It is separate from the capability switches: the switches decide whether the AI answers, the mode decides how far the answer may go.
A connection in Agent mode is marked Can act. Automatic review events themselves stay read-only whatever the mode: a review comments, and a proposed fix arrives as a separate pull request you review like any other.
The repository table
Each connection expands into one table of every capability, with two kinds of row.- All repositories is the default row. It carries the connection-wide values, and every repository with no rule of its own follows it.
- A repository rule is one row per repository that should differ. Pick the repository (or type
<owner>/<repository>) and press Add rule; the new row starts as a copy of the default row. Removing the rule reverts that repository to the default row.
Rules are keyed by the repository path, lowercased. For GitLab, use the full project path including subgroups, up to 20 levels deep - for example
my-group/my-subgroup/my-project.What each column means
Review instructions
Customise review instructions, at the top of the section, opens your organisation’s own review prompt, with one field per connected installation. It is what the reviewer should keep in mind on this installation: which areas to weigh heavily, which conventions to enforce, what language to write in.- Up to 4,000 characters per installation. The counter turns red past the cap and Save stays disabled until you shorten it.
- The instructions steer what the review focuses on and how it is phrased. They cannot override the platform guardrails or the review format.
- Every repository on the installation inherits them. An application that overrode its own Pull request settings under Application AI settings keeps the instructions set there instead, because overriding a lane pins the whole lane.
- Only organisation admins can change them.
What a review posts
One comment per pull request, updated in place on every re-review, never a stream of new ones. Where a pipeline, a preview, or a promotion is also running, they share that comment as separate sections. The review section is laid out like this:
Findings carry a severity of high, medium, or low, and a review keeps to the issues that matter - at most eight. A finding that names a line is also posted as a comment pinned to that line, so it is read where the decision is made. Each inline comment carries an invisible fingerprint of its file and title, so re-reviewing a pull request never restates a finding it has already pinned, even if the line has drifted or the wording changed.
How the review reads a change
- Machine-written files are dropped before the diff is measured. Lockfiles, minified bundles, source maps, and generated protobuf never reach the model. Beyond keeping the cost down, this is what stops a large lockfile from crowding the real change out of the review. Set Ignore paths per repository under Application AI settings to drop more.
- Uncertain findings are settled, not guessed. When a finding rests on something the diff does not show, Ankra reads the file and either restates the finding as a definite defect or drops it. Where that check cannot run, the finding is posted with its uncertainty visible.
- A truncated answer says so. If the model runs out of output budget mid-answer, what arrived is posted under an explicit incomplete-review notice rather than as a finished review that found nothing.
- The diff is treated as text, never as instructions. An instruction planted in a diff or a pull request description asking the reviewer to act, change role, or reveal data is refused.
Talking to the review
Mention@ankraai in a pull request or merge request comment and the AI answers in the thread, with the change as context. This needs Mention replies on for that repository.
- Ask a question. “@ankraai does this handle the empty case?” gets an answer grounded in the diff, and a plain statement when the diff does not contain the answer.
- Ask under an inline comment and the question is read as being about that line.
- Ask for a review. A mention is a direct request from a human, so it is never filtered by draft state, branch scope, or the review budget. It runs even on a draft and even past the Auto reviews / PR cap.
Only
@ankraai summons the review. It is matched as a whole word, so @ankraai-bot and an address like [email protected] are ignored.When a review does not run
A skipped review is normal and costs nothing. These are the reasons:Per-application overrides
The table on this page sets your organisation’s defaults. An application connected to a repository can override them on its own Ankra AI panel, which also exposes the settings this page does not: branch patterns, ignore paths, daily budgets, input-character budgets, and the deeper lanes (code review, actions review, org skills review). The two surfaces read the same stored settings, so they can never disagree. What they differ in is reach: a value you set here goes on steering every repository that has not overridden that specific lane. See Application AI settings.Cost
A review is a model completion, billed to your organisation like any other AI usage. Four things keep it bounded, and all four are yours to set:- Every lane is off until you turn it on, per connection or per repository.
- Auto reviews / PR caps the reviews one pull request can accumulate.
- Review model picks what a review costs. The picker shows each model’s context window and price.
- Ignore paths and the input-character budget bound how much of a diff one review reads.
Permissions
Connecting a provider, disconnecting one, changing any switch, and editing the review instructions all require organisation admin. Members see the connections and their current settings, and the controls are disabled with the reason.Troubleshooting
Related
- AI Connections - every integration the AI communicates through
- Application AI settings - per-repository lanes, branch scope, ignore paths, and budgets
- PR preview environments - what the PR previews switch deploys
- GitHub, GitLab, Bitbucket Cloud - connecting each provider
- AI Skills - the conventions the org skills review checks a change against
ankra application pull-request-reviews- read posted reviews from the CLI