In the Safeguard web app, open your project, go to the PR Guard tab, pick a pull request and click Run Review. You get a score, a summary and severity-ranked comments tied to files and lines. Tick Post to GitHub to put them on the pull request. For a hard merge block, pair this with a policy gate in CI.
The docs describe PR Guard as AI code review that runs against a pull request's diff. This post follows the documented path in the app at app.safeguard.sh. The app is chat first, but the PR Guard docs describe the tab and its Run Review button, not a chat command, so that is what we use here.
What do you need first?
PR Guard's current implementation is wired to GitHub pull requests. If a project's connected repository is not on GitHub, the tab shows a notice that a GitHub project is required, and review actions are disabled. Connect the project through a GitHub-backed integration before you start.
How do you run a review?
- Open the project and select the PR Guard tab. It sits alongside tabs such as Findings.
- Look at the pull request list. Each row shows the number, title, status (draft, merged, open or closed), branches, author, last update and the additions and deletions. A state filter defaults to open pull requests.
- Click a row to open the review view.
- Decide whether to post to the pull request. The Post to GitHub checkbox sits next to the Run Review button. Leave it unchecked for a private first look. Check it if you want comments on the pull request where reviewers already work.
- Click Run Review. The run starts as queued, then moves through running to completed. The app shows the current step and a progress bar, and polls about every two and a half seconds.
If a run fails, the progress panel shows an error message. A run stuck in queued or running should be given a few cycles before you worry.
What do the results contain?
A completed run returns:
- a score for the pull request and a short summary,
- per-file results, with the diff for each file and a reason when a file was skipped,
- comments, each with a severity (critical, high, medium, low or info), a category (such as security, bug, reliability, performance, maintainability, test, documentation or architecture), a file and line, a title and body, and sometimes a suggested fix and a confidence value.
The Overview tab rolls these into a risk breakdown, and the History tab lists past runs so you can reopen an earlier review without running it again.
What should you check before trusting a result?
- Look at the source of the run. The docs say a completed run can carry a source value of sample fallback if live analysis could not complete and the fallback option was set. In that case the score and comments are illustrative, not an analysis of your diff. Rerun once the underlying problem is fixed.
- Check publishing separately from analysis. Publishing to GitHub can finish after the rest of the run. The app shows "GitHub publish requested" until the review is posted, then "Posted to GitHub." Individual comments carry their own published flag.
How do you turn a review into a gate?
PR Guard produces findings and comments. It is a review aid, and the docs do not describe it as a merge blocker. A gate is something else. Safeguard's policy and gate documentation says policies evaluate scan results and can be advisory or blocking, and gates are checkpoints that enforce them. Each policy has an action: block makes the gate fail, warn passes with a warning, and notify passes and sends a notification. The docs describe a CI command that waits for a scan and fails the job when a named gate fails, once policy outcomes are on for your workspace.
A practical setup:
- Use PR Guard for reviewer attention: what to look at in the diff.
- Use a policy gate for rules that must hold, such as no critical vulnerabilities in dependencies.
- Make the CI job that evaluates the gate a required check in your repository's branch rules, so a failing gate blocks the merge.
- Write down the exception path: who can approve, and for how long.
Open the full walkthrough at /demos/gate-pull-request.
What are the limits?
- GitHub only, per the docs, at the time of writing.
- AI review can miss issues and can flag issues that are not real. Treat it as a second reader.
What to do
- Confirm the project is connected through GitHub.
- Run a review on a recent merged pull request with Post to GitHub unchecked, and compare the comments with what your human reviewers said.
- Tune what you act on: start with critical and high comments.
- Define one or two policies for the rules that must never be broken, and set their action to block.
- Make the gate job a required check, and test it with a deliberate failing change.
- Review the exceptions monthly.
Quick check
Does PR Guard block merges by itself?
The docs describe it as review that returns a score and comments, with optional posting to GitHub. Blocking comes from policy gates evaluated in CI and required checks in your repository.
Will comments appear on the pull request automatically?
Only if Post to GitHub was checked for that run. Publishing can finish a little after the analysis, so look for the posted status.
Sources
Last reviewed: 18 October 2026.
