PR risk check

Hud's PR risk check reviews each pull request against how the code it changes runs in production, and posts a verdict before you merge.

What it checks

When a PR changes code Hud has seen run in production, two reviewers go over it in parallel, using Hud's runtime data:

• Data shape: whether the change could break the data a function receives or returns, such as a contract its callers rely on.
• Load and latency: whether the change could slow down a busy function, overload what it calls, or make errors spread.

If the repository has reviewer guidelines (see step 4 below), a third reviewer checks the PR against them. If a PR only changes tests, documentation or repository files, nothing in production can change, so Hud skips the review and marks it Safe to merge.

Verdicts

If a PR only changes files Hud can't see run, such as infrastructure files or files it doesn't recognize, Hud can't review it. It posts a Not eligible for review comment listing those files, adds the hud-not-eligible-for-review label and finishes the check as Neutral.

Hud leaves some PRs alone, with no comment and no check: drafts, until they're marked ready for review; PRs into a branch other than the repository's default branch; and, if you set a trigger label in step 4, PRs without that label. Hud can also filter a repository's PRs by author, branch, title, the files they change or their size; contact support to set that up. A PR a filter leaves out gets no comment, and if it's left out because of what it changes, the Hud Reviewer check finishes as Neutral and says why. To review a draft or an unlabeled PR anyway, comment @hud review on it.

Where it shows on a PR

• A Hud comment with the verdict and findings, updated as the PR changes.
• Review comments on the lines involved.
• A label: hud-safe-to-merge, hud-review-required, hud-high-risk or hud-not-eligible-for-review. Labels are on by default; to turn them off for a repository, contact support.
• A GitHub check named Hud Reviewer, if you turn it on. Policy approval can require it.

Turn it on

Anyone in your Hud account can do steps 1 to 3. Step 4 needs an account admin: Settings → Members shows each person's role. To make someone an admin, or if you don't see Settings → Agentic Workflows, chat with our support team or email [email protected].

1. Connect GitHub to Hud

Hud reviews pull requests through its own GitHub App. It isn't in the GitHub Marketplace: you install it from Hud, which links the installation to your Hud account.

1. In the web app, go to Settings → Integrations.
2. On the GitHub card, select Connect to GitHub. GitHub opens the install page for Hud's app.
3. Pick the GitHub organization or account that owns your code.
4. Choose All repositories, or Only select repositories and pick the ones Hud should review.
5. Select Install & Authorize. GitHub sends you back to Hud, and the GitHub card now reads GitHub connected to Hud, with the number of repositories Hud can see.

Finish within 10 minutes of selecting Connect to GitHub, or start again from Hud. If you aren't an owner of the GitHub organization, GitHub asks an owner to approve the installation. A GitHub installation can be connected to one Hud account only. To add or remove repositories later, open the GitHub card's menu and select Manage access on GitHub.

2. Connect your AI provider

The review runs on Anthropic's Claude models through your own AI provider account.

1. Go to Settings → Agentic Workflows.
2. On the AI provider card, select Connect provider.
3. Choose Claude Code and paste an Anthropic API key, or Claude Code on Bedrock and connect Amazon Bedrock with an API key or an IAM role. Then select Save.

AI provider has the steps for each option, including the AWS permissions Bedrock needs.

3. Link your services to the repository

Hud reviews a PR against how the code it changes runs in production, so it needs to know which of your services run each repository's code.

1. In Settings → Agentic Workflows, find the repository under Repository workflow and select Configure. Every repository Hud's GitHub App can see shows up there, except empty ones. If one is missing, add it with Manage access on GitHub (step 1).
2. Under Services in this repository, select every service that runs code from this repository.
3. Select Save.

A service is linked to one repository at a time. If you pick a service that's already linked to another repository, Hud warns you, and saving moves it to this one.

If a service also runs code from other repositories, such as a shared library, add them under Related repositories in the same panel (up to 19), so the review accounts for changes across repositories.

4. Turn on the review

In the same panel, under Hud PR reviewer:

1. Turn on Hud PR reviewer.
2. Optional: turn on Hud reviewer check to add the Hud Reviewer GitHub check, which branch protection and Policy approval can require.
3. Optional: turn on Run review only when PR is labeled and enter a label, such as needs-hud-review. Hud then reviews only the PRs that have that label.
4. Optional: edit the Reviewer guidelines, the rules this repository's PRs are checked against. Hud's default is "Never approve PRs that include migrations". While the box holds Hud's default, Hud keeps it current as the default improves; once you edit it, your text stays as you wrote it. Select Restore default to go back to it, or clear the box to turn this part of the review off.
5. Select Save.

The repository's PR analysis column now shows Enabled. From then on, Hud reviews each PR when it's opened and again on every push, so a PR that was already open gets its first review on its next push. To review a PR right away, or to run the review again, comment @hud review on it.