Skip to main content
When several people open pull requests against the same code, review order matters. Graphify reads your open PRs, maps each diff onto the code graph, and shows how much each one touches and which PRs collide. Your team reviews the risky ones first and merges in an order that avoids surprise conflicts.

​
What you’ll build

  • A dashboard of open PRs with CI status and graph impact.
  • A list of PR pairs that touch the same communities.
  • A triage view that suggests what to review first.
This recipe runs against the open-source Graphify-Labs/graphify repository, which had 48 open PRs when this was written.

​
Setup

You need the GitHub CLI, signed in with gh auth login, and a graph of the repository:

​
Step 1: List open PRs with impact

Graphify detects the default branch (here v8) unless you pass --base. The impact column counts the graph nodes and communities a PR’s changed files reach. A PR that reaches 122 communities needs a different reviewer than one that reaches 8.

​
Step 2: Find colliding PRs

This adds the PRs that overlap in the graph, even when they edit different files. Two PRs that change different callers of the same function won’t conflict in git, but they can still break each other.

​
Step 3: Triage

Triage asks an LLM to order the queue so the team knows what to look at first. It uses GRAPHIFY_TRIAGE_BACKEND if set, otherwise the first backend with an API key (Claude, Kimi, OpenAI, then Gemini), and falls back to a local Ollama model. Add --wrong-base to flag PRs aimed at the wrong branch.

​
Step 4: Look at one PR

Pass a PR number to see its detail. Pair it with graphify affected from Plan a refactor on the functions it changes.

​
Step 5: Agree a merge order

For each colliding pair:
  1. Merge the smaller-impact PR first.
  2. Ask the other author to rebase and rerun their tests.
  3. Rebuild the graph with graphify update . and check the second PR’s impact again.

​
When it goes wrong

Error: gh ... and exit code 1. The command shells out to gh. Run gh auth status, and check that you can read the repository with gh pr list --repo OWNER/REPO. Impact shows –. The PR changed files that aren’t in the graph, such as docs or config, or the graph is stale. Rebuild with graphify update .. Triage failed: No module named 'openai'. The table still prints, but triage needs an LLM client. Install the extra for your backend, for example uv tool install "graphifyy[openai]", and set its API key. Wrong base branch. Pass --base main (or -b main) when your repository’s default branch isn’t the one PRs target.

​
Production patterns

  • Run graphify prs --triage at the start of a review session and share the output in your team channel.
  • Use --worktrees to see which PR branches are checked out locally.
  • Agents can call the same views over MCP: the local server exposes list_prs, get_pr_impact and triage_prs. See Self-host a shared MCP.
  • In Graphify, the hosted product, connected repositories get reviews on each PR, with colliding PRs flagged.

​
Complete example

​
What you built

Your team has a shared, graph-backed view of the PR queue: what each PR reaches, which ones collide, and a merge order that keeps the default branch green.

​
Next steps

Colliding pull requests

How Graphify detects PRs that touch the same code.

Graph impact comment on every PR

Post the impact on each PR automatically.

Try it in Graphify

We build and host the graph for you. Start with a 14-day Pro trial, then keep up to 3 repositories on Free. No card required.