Linked Pull Requests
One change often spans several repositories. You update an API in one pull request and its consumers in others, and the three only make sense together. Reviewed one at a time, each looks fine on its own, and the mismatch between them stays invisible until something breaks in production.
Codity can review those pull requests as one change. When it reviews a pull request, it finds the sibling pull requests that belong to the same piece of work, reads the parts of their diffs that define a contract, and flags places where the two sides disagree.
What This Catches
Say acme/orders adds a required region field to the order payload, and acme/billing reads that payload with a strict check on the exact set of keys it expects.
Reviewed separately, both pull requests look correct. Reviewed together, Codity reports:
Cross-PR: acme/orders#412: acme/orders#412 adds a required `region` field to every
order returned by GET /v1/orders/{id}. This pull request validates the payload against
an exact key set that does not include `region`, so once both land, every call will
raise ValueError and reconciliation will fail for all orders.
The same applies to a renamed field, a removed enum value, a new required header, a schema change without the code that reads it, or an environment variable one side needs and the other never sets.
Linking Pull Requests
There are three ways Codity connects them. You only need one.
1. A link in the description
Add the other pull request to the description when you open yours:
Depends-on: https://github.com/acme/orders/pull/412
Related-PRs:, Linked-PRs: and Stacked-on: work the same way. A plain link to a pull request anywhere in the description also counts, though a labelled line is treated as the stronger signal, because a bare link is often just "similar to this one".
2. A shared ticket
Put the same Jira, Linear or ClickUp reference in both pull request titles, descriptions or branch names:
PAY-142 Add region to the order payload
PAY-142 Update billing reconciliation
The reference has to resolve to a real ticket. A branch name that merely looks like a key will not group anything.
3. A link recorded in your tracker
If Jira or Linear already has both pull requests attached to the same issue, Codity finds them from there. Neither description needs to mention the other. This is common when your tracker creates those links automatically.
What You Get
Findings on the pull request being reviewed. Anything that crosses a repository boundary is reported inline and marked with the sibling it conflicts with, so you can see which other pull request to look at.
A comment on siblings already reviewed. Pull requests in one change rarely open at the same moment. When a later one is reviewed, each earlier sibling receives a single comment naming the new pull request, listing the group, and quoting only the findings that concern that particular pull request. You get one comment per new sibling, never a repeat.
Running a Review Again
If you add a link after opening the pull request, editing the description does not start a review on its own. Descriptions get edited constantly, and running a full review for every edit would be slow and noisy.
Comment this instead:
@codity review
That runs the review again with the sibling context included. No commit needed.
The same command is useful whenever a sibling has moved and you want the current picture.
What It Costs
Nothing extra when nothing has changed. Codity treats the set of siblings and their latest commits as part of the review identity:
| Situation | What happens |
|---|---|
| The pull request has no siblings | Behaves exactly as before |
| Siblings exist but none have changed | No new review runs |
| A sibling opens, or a sibling gets new commits | A fresh review runs with the updated context |
So a repeated @codity review on an unchanged change is free, while a genuine change on either side produces a real review.
What Codity Reads
Only the parts of a sibling diff that can break you: routes and endpoints, schemas and models, exported signatures, database migrations, message contracts, and environment variables. Documentation, tests and unrelated edits are left out, which keeps the review focused and the cost down.
Codity reads at most three siblings for any one pull request, and only from repositories connected to the same organisation. A link pointing anywhere else is ignored before anything is fetched, so a link pasted into a description can never pull code from a repository your organisation has not connected.
A sibling that was closed without merging is skipped, since it describes a contract nobody adopted. A merged sibling is included and labelled as merged.
Turning It Off
The setting lives under Settings > Review, and can be set for your whole organisation or for a single repository. A repository with no explicit value follows the organisation setting.
Good Practice
Add the link when you open the pull request, or give both pull requests the same ticket reference. Either way the first review already has the full picture, and you avoid a round trip.
Write the description so it says what changed in the contract. Codity reads it alongside the diff, and a clear sentence about a renamed field or a new required value gives the review more to work with than the diff alone.
