Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cubic.dev/llms.txt

Use this file to discover all available pages before exploring further.

Cross-repo reviews allow cubic to read selected repositories during PR review. Use them when changes in one repository affect another, such as frontend/backend APIs, shared schemas, docs, or companion releases. Add repository links to choose which repositories are available as context. Both repositories must be installed in the same cubic GitHub installation.
Cross-repo reviews are available on every plan during beta. Plan access may change at general availability.

​
How it works

When you link two repositories and open a pull request in either one, cubic:
  1. Checks whether the link applies - Uses the changed files and your guidance to decide whether the linked repository matters for this PR.
  2. Reads the linked repository on demand - If the link applies, code review agents inspect the shared surface being changed.
  3. Posts cross-repo findings - Issues that affect the linked repository appear as comments on the original PR, with citations to the affected files.
  4. Tracks companion PRs - If you reference a PR in the linked repository from the original PR description, cubic watches it and updates findings once the companion PR pushes a fix.

​
Setting up cross-repo reviews

Cross-repo reviews card in AI review settings with several configured links
  1. Open AI review settings and select the repository you want to configure.
  2. Find the Cross-repo reviews card and click Add.
  3. Choose the related repository from the picker. Only repositories in the same installation appear.
  4. Write 1-2 sentences describing what the repositories share and what changes need coordination, then click Link repository.
Repository links are bidirectional. Configure a pair once, and code review agents can use the link from either repository.

​
Constraints

  • Each repository can link to up to 3 other repositories. To link more, contact us.
  • Guidance is capped at 80 words. Aim for around 50. Code review agents read guidance verbatim, so concise text works best.
  • Both repositories must be in the same GitHub installation. Cross-installation links are not supported.
  • Archived repositories, repositories cubic no longer has access to, and repositories that have moved installations show an inaccessible badge and are skipped during review.

​
Writing good guidance

Guidance tells code review agents when another repository matters. Name the shared surface and the kinds of changes that need coordination.

​
Good examples

Frontend and backend share an HTTP API; route or response-shape changes need coordinated updates on both sides.
Both services read from the same Postgres database. Schema migrations and column renames require matching updates in both repositories.
The shared @acme/types package is consumed by both repositories. Breaking changes to exported types require updates wherever they’re imported.

​
What doesn’t work

They’re related.
This is too vague to be useful. cubic may skip the linked repository or check it too often.
Name the shared surface (API, schema, types, events) and the coordination rule (what changes need a companion PR). Specific guidance makes relevance checks more accurate.

​
Referencing companion PRs

When your change spans two repositories, link the companion PR in the original PR description. cubic recognizes two formats:
  • Full URL: https://github.com/myorg/backend/pull/456
  • Shorthand: myorg/backend#456
The referenced PR must be in a repository linked from Cross-repo reviews. Bare #456 shorthand is intentionally not matched because same-repo references cannot be companions. Editing the PR description re-runs discovery, so you can add or remove companion references at any time.

​
What you’ll see in reviews

A cross-repo finding comment on a PR citing files in three related repositories Cross-repo findings appear inline on the original PR, the same way other AI review comments do. Each finding includes a citation pointing at the affected file in the linked repository, so you can jump to the code that needs a matching change. When the companion PR pushes new commits that address the cited issue, cubic edits the original comment to show the addressed state along with the commit SHA that fixed it. If a comment cites multiple cross-repo concerns and only some are addressed, the comment notes partial resolution so you know what’s still outstanding.

​
Troubleshooting

cubic decided the repository link does not apply to this PR. Check that your guidance names the surface that’s actually changing in the PR — for example, guidance that only mentions “API routes” does not apply to a CSS-only change. If guidance is already specific, the linked repository may not be affected by this PR.
Confirm two things: the referenced PR is in a linked repository, and the reference in the original PR description uses one of the recognized formats (full GitHub URL or owner/repo#number). Bare #number shorthand is ignored because it can’t point at another repository.