Atmos Pro has always reported the status of your infrastructure plans back to GitHub through check runs and a rolled-up PR comment. That tells you what happened, but it stops short of saying "this is safe to merge" or "do not merge this yet." A green check is a hint. A reviewer's signature is a decision.
Today Atmos Pro starts making that decision. Whenever Atmos Pro's check suite reaches a terminal state on a pull request, it now also leaves a formal GitHub PR review — approving when every check passes, and requesting changes when any of them fail. The review body lists the affected stacks and instances and explains why the request was rejected, so reviewers can drill straight into the failure without having to chase logs through the Actions tab.
The review reflects exactly what Atmos Pro saw, in three flavors.
When a pull request doesn't touch any components, Atmos Pro approves it immediately with a one-line message: "There were no affected stacks, therefore this is approved by Atmos Pro." No-op PRs are common — README edits, CI tweaks, documentation. Atmos Pro can confidently rubber-stamp them so they don't sit waiting for a separate "infra approval."
When the affected components all plan cleanly, Atmos Pro approves the PR with a summary of the components that passed. The same identity (atmos-pro[bot]) that you already see posting check runs and comments now shows up as an approving reviewer.
When any affected component fails — a non-zero plan exit code, a workflow dispatch error, or a config error — Atmos Pro requests changes. The review body opens with a > [!CAUTION] callout and a Markdown table listing every failing (stack, component) pair, the status, and a link to the workflow run logs. If Atmos Pro could not even dispatch the workflow (a missing workflow file, an invalid input), the dispatch error gets surfaced inline so the reviewer sees the real cause without leaving the PR.
The behavior is enabled per repository on the Settings tab. New installs and existing repositories ship with auto-review on, because the most common case — a passing PR getting a quick approval — is universally helpful. If your team prefers Atmos Pro to remain quiet on reviews, flip the toggle off and Atmos Pro reverts to the prior behavior: check runs and PR comments only.
The toggle is workspace-admin gated. Members can see the setting; only owners and admins can change it. Toggling produces an audit log entry so you can see who turned it on or off and when.
The review write happens at the exact moment Atmos Pro updates the GitHub check suite. There's a single helper that all three terminal-state code paths call: the "no affected stacks" branch on the affected-stacks pipeline, the rolled-up comment update, and the per-event finalizer. That means there is one mental model — "updating the check suite also updates the review when the toggle is on" — instead of a parallel "review system" that drifts away from the check run over time.
The submission is idempotent. Each (owner, repo, pr_number, head_sha, conclusion) is recorded in a pr_review_submissions table with a unique index. Re-running the same workflow on the same SHA does not produce a second review. Pushing a new commit to the PR creates a new SHA, which produces a fresh review on that commit — and GitHub's reviewer-state semantics resolve any prior REQUEST_CHANGES from atmos-pro[bot] automatically when the new commit comes back clean.
For Atmos Pro's approval to count toward GitHub's "Require approvals" branch protection rule, the atmos-pro[bot] identity needs to have access to review the protected branch. The simplest path is to add the bot to your CODEOWNERS file for the paths Atmos Pro is responsible for. Once it's listed, an Atmos Pro approval satisfies a required code-owner review the same way a human approval would.
Two GitHub-side limitations worth calling out: the bot cannot approve a PR that the same App's installation token opened (GitHub blocks self-review with a 422), and required-reviewer rules with explicit user lists need the bot added to that list to count. Atmos Pro handles the self-review case gracefully — it logs and moves on — so there's nothing to clean up if it ever encounters one.
If your team has been treating Atmos Pro's check run as the de-facto signal — green means safe, red means broken — you can now lean on it more directly. Required-reviewer rules can include atmos-pro[bot], your merge queue can wait on its approval, and the pull request page becomes the single place where the infrastructure verdict lives, rather than something a reviewer has to translate from a check status into an approve click.
If your team prefers a human to be the final approver, the auto-review setting is a single repository-wide boolean — turning it off disables all three behaviors at once (no-affected-stacks approval, passing-PR approval, and failing-PR change requests). Either way, when auto-review is on the failing-stacks review body now puts the diagnostic information one click closer to the reviewer than it was yesterday.
To turn it off for a specific repository, open Atmos Pro, go to that repo, click Settings, and toggle "Pull Request Auto-Review" off.
