Cross-Repository Review

Closed beta. Cross-repository review is part of AI code review, which is in closed beta and enabled per organisation on request. Contact support to have it turned on for your organisation.

A diff on its own hides the most valuable class of finding: you changed this, and the code that depends on it is not in front of you. The AI code review pulls that code in before it answers, so it can raise the finding instead of leaving it to whoever greps for it later. This page covers what the review reads beyond the diff, how to tell it which repositories belong together, and how to declare which pull request has to merge first.

Callers in the same repository

For each declaration the diff changes, Ankra searches the repository for the other places that name appears and reads the best candidates into the prompt, at the reviewed commit. That is what lets a review say “three of this function’s five callers are in files this pull request does not touch” - a finding the diff alone cannot support.

Repositories deployed alongside this one

A pull request can be correct, green, and still break a different repository: it removes a route, and the client that calls it lives elsewhere with its own pipeline that has never heard of this change. Neither side disagrees until the deploy. So for names this diff removes, and for contracts it changes, Ankra searches the repositories your organisation relates to this one and shows the review any file that still refers to them. A removal is reported as a possible breaking change on the line that does the removing; a changed contract is reported only where the file shows a real dependency on what changed.


Which repositories	Three sources, combined. Two need no configuration at all: applications Ankra installs on the same cluster, and repositories tagged on that cluster under Settings → AI Context. The third you state yourself - see Relating two repositories directly below.
What triggers it	A removal: a route path, a serialised field name or a constant’s quoted value that a removed line carried and no added line carries. A changed contract: a serialised field whose declaration line changed while its name survived (a type, a nullability, an `omitempty`), or an exported declaration whose line changed (a function gaining a parameter, a version constant moving). An added route or a new field breaks nobody, so an additive change consults nothing and costs nothing, and a line that merely moved or was re-indented is not a change. Removals are searched first, up to four terms per review.
Scope	Up to five related repositories per review. GitHub only, code search being the mechanism.
What is read	Whole files at a named commit of the repository’s default branch, quoted into the prompt as untrusted material under review - never as instructions, exactly like the diff. Code search indexes default branches only, so this pass alone cannot see a fix that is still on a branch; that is what the other half of the change below is for. When the repository has an open companion pull request, the same file is read on that branch too, and the review is told whether the name survives there.

The repository set is read from your organisation’s own rows, never from the model and never from the text of the pull request. A pull request cannot name a repository to have it read, and a search result pointing outside the set is discarded.

Silence here is not an all-clear. The search is best effort. A rate limit, a failed request, a provider without code search, or an organisation with nothing co-installed all produce no section at all rather than one reading “nothing else uses this” - because a review that conflated those would tell you a removal is safe on the strength of a request that failed. Absence of a cross-repository finding is not evidence that nothing is affected.

The other half of the change

A cross-repository change is almost never one pull request. The API removes a route in one repository and the client stops calling it in another, and the second half sits on a branch until the first has landed. Code search cannot see that branch, so on its own the pass above would say “the client still calls this” about a repository whose fix is already open. So the review also reads the companion pull requests of the one under review, and shows each as it stands on its own branch:


Declared	A line in this pull request’s description reading `Depends-on: owner/repository#number` (or the full pull request URL). It is the same line merge order is declared with, read with the same grammar, so the review and the merge hold can never disagree about what it names.
Linked	A pull request in a related repository whose description or a comment links this one. GitHub records the link on this pull request’s timeline, and the review reads it from there - so pasting the other half’s URL into the description is enough.
What is shown	Up to three companions: state (open, merged, or closed without merging), whether it is a draft, its head commit, its base branch, and its diff, bounded, as untrusted material like everything else in the prompt. A companion closed without merging is shown by state alone, because it changes nothing.
Which repositories	Only the reviewed repository itself and the related set above. A declaration or a link naming any other repository is not read: a pull request may choose which pull request in the set the review looks at, never widen the set.
On the companion’s branch	Where the pass above found a file on a related repository’s default branch, and that repository has an open companion, the review reads the same file at the companion’s head and states what it found: the file still mentions the name, no longer mentions it, or no longer exists there. That verdict is computed, not inferred.

The review uses this to say which side has to merge first, and to stop asking you to confirm what the platform can read. A mention reply (@ankraai) sees the same companions, so “the other half is in that pull request” is checked rather than taken on your word.

A companion absent from the review is not evidence that none exists. Only declared lines and links GitHub recorded are read, up to three, and a companion that could not be read is left out rather than shown as unchanged.

Relating two repositories directly

The two automatic sources only know what is deployed on the same cluster. A client and the API it calls, a shared library, or a client that runs outside Ankra have no cluster in common, so state those relationships directly: AI → Settings → Connections → Source control & AI review, open a GitHub connection, and use Related repositories at the bottom of its panel. This adds to the automatic sources; it does not replace them.

Pick both repositories

Both are chosen from drop-downs listing the repositories that GitHub App installation can reach. The review reads them with that installation’s token, so a repository it cannot reach would contribute nothing and is refused. If one is missing, add it to the GitHub App installation first.

Relate them

The pair is saved immediately and appears in the list above, shown as repo-a ↔ repo-b.


Direction	None. Reviews of either repository consider the other, and adding a pair you already have in the other order changes nothing.
Where it applies	The GitHub App installation you added it under. Two installations on one organisation keep separate lists.
Who can change it	Organisation admins. Everyone else sees the list read-only.
Removing one	The ✕ on the row. Removing a relationship stops future reviews consulting it; it changes nothing about reviews already posted.

The list is not portal-only, and both other surfaces hold the same rules: organisation admin, one installation, both repositories reachable by it.

ankra org ai-review related-repos list
ankra org ai-review related-repos add my-org/portal my-org/api
ankra org ai-review related-repos remove my-org/portal my-org/api

The CLI finds the installation from your GitHub App credential, so you name one only when the organisation has several: --credential github-app-my-org. remove also takes a relationship’s ID from list, and it removes the pair whichever order it was stated in. Over MCP the three are list_related_repositories, relate_repositories and unrelate_repositories. They are addressed by the GitHub App installation’s numeric id, which list_credentials reports for every GitHub App credential. The two writes need the mcp:write scope and an organisation admin’s token: the MCP surface does not carry the chat lanes’ permission gate, so the tools check admin themselves.

Declaring merge order

Where a removal or a contract change is genuinely breaking, the risk is often the deploy sequence rather than the change, and the review will suggest declaring the order with a line in the pull request description:

Depends-on: my-org/my-api#1722

Ankra reads the line only when it starts a line, so ordinary prose mentioning “depends on” cannot hold anything. It accepts the short owner/repository#number form or a full pull request URL, up to five per pull request. Order is declared rather than inferred on purpose: inferring which side is the producer means guessing whether the change is additive or breaking, a judgement the author has already made, and two halves each waiting for the other is a deadlock. The line does two things. The review reads it on every turn and shows the declared pull request as the other half of the change, so the finding that suggested it is answered by the next review rather than by you. And merge-when-green holds this merge until the declared pull request has merged.

The merge hold needs Merge when green on the installation, off by default and switched on next to the AI mode control on the installation’s row, or over the API - see Merge when green. With it off, the line holds nothing and you sequence the merges yourself; the review still reads it either way.

Switch the review on and choose what it posts in AI code review.

Get Started

Concepts

Provision & Import

Operate

Security & Compliance

Deliver

Platform

AI

Kubernetes Resources

Reference

Integrations

Callers in the same repository

Repositories deployed alongside this one

The other half of the change

Relating two repositories directly

Declaring merge order

Next

​Callers in the same repository

​Repositories deployed alongside this one

​The other half of the change

​Relating two repositories directly

​Related repositories from the CLI or MCP

​Declaring merge order

​Next

Callers in the same repository

Repositories deployed alongside this one

The other half of the change

Relating two repositories directly

Related repositories from the CLI or MCP

Declaring merge order

Next