Cross-repo work often lands as several pull requests with separate CI runs. Polygraph keeps those PRs and checks tied to the same session so reviewers can see the full change, not only one repo's diff.
What sessions track
Section titled “What sessions track”A session can track:
- Branches pushed from each repo
- Draft PRs opened for related repo changes
- Existing PRs associated with the session
- CI status for the related PRs
- PR readiness across the full set of repos
- Session descriptions and links that explain why the PRs belong together
Create and link PRs
Section titled “Create and link PRs”The agent can push branches and open draft PRs for each repo in the session. Ask an agent to do it or use polygraph git push-branch and polygraph git create-pr when you want to drive that flow from the CLI.
Draft PRs keep related changes reviewable before the full cross-repo set is ready.
Polygraph syncs the status of each PR in the session, so you get the same view from the Polygraph web app or from an agent using the Polygraph CLI.
Associate existing PRs
Section titled “Associate existing PRs”Not every PR has to be created by Polygraph. If a PR already exists, use polygraph git associate-pr to attach it to the session, or ask an agent to do it. That keeps manual PRs, agent-created PRs, and follow-up PRs in the same cross-repo record.
Track CI across repos
Section titled “Track CI across repos”Cross-repo changes are not ready until the related CI runs pass together.
Polygraph can treat the CI executions for a session as one cross-repo signal. When one repo fails, the agent can inspect whether the fix is local to that repo, whether the shared change is incompatible with a downstream consumer, or whether more repos need to be added to the session to address the failure.
Ask the agent to wait for CI and handle failures:
Wait for CI for this Polygraph session and address any failures.Test downstream repos before release
Section titled “Test downstream repos before release”Polygraph brings a monorepo-style validation loop to a polyrepo setup. In a monorepo, you can change a shared library and run tests for downstream projects before landing the library change. With Polygraph, you can do the same across separate repos.
For example, if you change a design system, the agent can install the unpublished version into an application that depends on it and run the application's CI before the design-system PR merges. For package-based validation, the agent can use pack_and_copy to pack the publisher and install the tarball into the consumer repo inside the session.
Can you pack and copy <package-name> package and update <app-name> to use it?Review the whole change
Section titled “Review the whole change”Each linked PR carries session context. Reviewers can open the session to see related repos, agent decisions, validation steps, CI state, and sibling PRs before approving their part of the change.