To read someone else's diff with enough surrounding context to catch the bugs a line-by-line read would not, have Atlas get the diff and then leave the diff. Atlas uses bash to fetch the branch and produce the changed files and the raw patch, read to pull the full files rather than the hunks, and the lsp tool's findReferences operation to check whether a changed signature broke any caller the diff does not show. Atlas then greps for the patterns the change should have updated but did not, runs the tests with bash, and reports findings as a todowrite list ordered by severity. Every bash command is permission-gated before it runs.
How does Atlas review a pull request end to end?
Atlas reviews a pull request in 5 steps: bash fetches the branch and produces the raw patch, read pulls the changed files in full, the lsp tool's findReferences checks callers the diff never touched, grep hunts for what the change forgot, and todowrite reports findings by severity.
The defining move is the second one. A reviewer who stays inside the hunks sees only the lines the author chose to show, which is exactly where the missed caller and the stale constant hide. Atlas reads the changed files in full so context outside the diff is visible, and only then starts asking whether the change is correct. The review itself is read-only work: bash, read, lsp, and grep gather evidence, and todowrite records it. Nothing in a pull request review needs to modify the repository.
How do I get a pull request diff into Atlas with bash?
Atlas fetches the branch and produces the diff with bash. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so a single review session has the changed file list, the raw patch, and the commit history without leaving the terminal in 2026.
Having diffRaw alongside diff matters when a review question is about exact bytes: whitespace-only churn, a moved block that looks like a rewrite, a file mode change. Having commits matters when the review question is about intent, because the commit sequence often explains why an odd intermediate state exists. Every bash invocation is permission-gated against allow, ask, and deny rules before it runs, so a read-only review can safely put the git commands on allow while leaving anything else asking.
Why does Atlas read whole files instead of just the diff hunks?
Atlas reads the changed files in full with the read tool because a diff hides everything it did not touch. A three-line hunk can be individually correct and still wrong for its file, and the read tool is what puts the surrounding 300 lines back in front of the reviewer.
The bugs that survive a line-by-line read are almost always contextual. A new early return that skips a cleanup block further down. A field set in the hunk but consumed by a different branch above it. An invariant the file has maintained for two years and the patch quietly breaks. None of these are visible in the patch, and all of them are visible in the file. Reading full files costs context, which is why the read step is scoped to the changed files rather than the whole repository.
How do I find callers a pull request forgot to update?
For every changed function signature in a pull request, Atlas runs the lsp tool's findReferences operation to check callers the diff never touched. findReferences answers from the language server, so the caller set is the real one, not a guess, and 1 missed caller is all it takes to break main.
A signature change is the classic reason a pull request passes local review and breaks main. The author updated the callers they knew about, and the diff shows only those. findReferences asks the language server for every reference to the symbol, which returns callers in files the pull request never opened. Atlas cross-checks with grep for the usages a language server cannot see, such as reflective calls or symbol names stored in strings. Both are read-only steps that change nothing.
What does Atlas grep for during a pull request review?
Atlas greps for the patterns a pull request should have updated but did not: old constant names, stale copies, feature flags left in place. The hardest class of review bug is the omission rather than the commission, and in 2026 grep remains the tool that finds an omission fastest.
The grep step is deliberately negative. Instead of checking that the new code is right, Atlas checks whether the old code is gone. A renamed constant still referenced in a config file. A duplicated implementation the pull request updated in one location and not the other. A feature flag the change was supposed to retire. Each hit is a candidate finding, and each candidate is confirmed by reading the file, since a grep hit in a comment or a test fixture is not the same as a live one.
How does Atlas report pull request findings, and where do I approve?
Atlas runs the tests with bash and reports findings as a todowrite list ordered by severity, so a review of 40 changed files comes back as a triaged checklist rather than a wall of prose. The human approval point is every bash command, since bash is permission-gated before it runs.
Ordering by severity is what makes the review usable. A correctness bug found by findReferences and a nit about naming are not the same finding, and a flat list treats them as if they were. The todowrite list puts the caller that will break at the top. Because a pull request review with bash, read, lsp, grep, and todowrite never edits a file, there is no diff to approve: the approval surface is the commands Atlas asks to run. If a review turns into a fix, Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
Step by step
- 01Fetch the branch and produce the diff with bash. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data.
- 02Read the changed files in full with the read tool, not just the hunks, so context outside the diff is visible.
- 03For every changed function signature, run the lsp tool's findReferences operation to check callers the diff never touched.
- 04Grep for the patterns the change should have updated but did not: old constant names, stale copies, feature flags.
- 05Confirm each grep hit by reading the file, since a hit in a comment or a test fixture is not a live usage.
- 06Run the tests with bash and report the findings as a todowrite list ordered by severity.
Frequently asked questions
- how do I use an AI agent to review a pull request in the terminal
- Have Atlas fetch the branch and produce the diff with bash, read the changed files in full with the read tool, run the lsp tool's findReferences on every changed signature, grep for what the change forgot, then run the tests with bash and collect findings in a todowrite list.
- why should a code review read whole files instead of just the diff?
- A diff hides everything it did not touch. A hunk can be correct on its own and still break the file it lives in, through a skipped cleanup block or a broken invariant. Atlas reads changed files in full with the read tool so context outside the diff is visible.
- how do I find every caller of a function Atlas says I changed?
- Run the lsp tool's findReferences operation on the changed symbol. The answer comes from the language server, so it includes callers in files the pull request never opened. Cross-check with grep for dynamic or string-based usages the language server cannot see.
- can Atlas review a pull request without changing any files?
- Yes. The pull request review workflow uses bash, read, lsp, grep, and todowrite, none of which modify the repository. Every tool call is still permission-gated against allow, ask, and deny rules before it runs.
- what git data can Atlas see during a review?
- Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf. The VCS layer exposes status, diff, diffRaw, and commits over the same git data, so the changed file list, the raw patch, and the commit history are all available in one session.
- how does Atlas order its code review findings?
- Atlas reports findings as a todowrite list ordered by severity. A correctness bug found by findReferences sits above a naming nit, so the review reads as a triaged checklist instead of a flat wall of comments.
- does Atlas need permission to run git commands during a review?
- Yes. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, including every bash command. A read-only review typically puts the git commands on allow and leaves everything else asking.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Review a Pull Request in Flask with Atlas in 2026
In 2026, Flask developers use Atlas to review pull requests, leveraging its AI capabilities to understand context beyond the diff. Atlas integrates with Flask's toolchain, including pytest and ruff format, for
Review a Pull Request in Echo with Atlas in 2026
In 2026, Echo developers use Atlas to review pull requests, moving beyond simple diffs. Atlas leverages `go test (httptest)`, `go mod`, and `gofumpt` to find subtle bugs and ensure code quality in your Echo applications.
Review a Pull Request in Nuxt with Atlas in 2026
In 2026, Nuxt developers use Atlas to review pull requests, leveraging its AI to understand diffs with full context. Atlas integrates with `pnpm`, `vitest (@nuxt/test-utils)`, and `prettier` to ensure robust code
Review a Pull Request in PHP with Atlas in 2026
Streamline your PHP pull request reviews in 2026 with Atlas, the terminal-native AI agent. Leverage PHPUnit, Composer, and PHP-CS-Fixer for thorough, context-aware code analysis, catching bugs a line-by-line read would
Review a Pull Request in Spring with Atlas in 2026
In 2026, Spring developers use Atlas to review pull requests, leveraging its AI to analyze diffs, check `JUnit 5 via mvn test` results, and ensure code quality across controllers and services.
Review a pull request in Go with Atlas (2026)
How Atlas reviews a Go pull request in 2026: bash produces the diff, read pulls whole files, and lsp findReferences catches callers a changed interface broke off-diff.
Review a pull request in Apache Airflow with Atlas in 2026
Streamline Apache Airflow pull request reviews in 2026 with Atlas. Catch subtle bugs in DAG definitions, task dependencies, and top-level code using AI-powered context and real Airflow tools.
Review a Pull Request in Crystal with Atlas in 2026
In 2026, review Crystal pull requests with Atlas, the terminal-native AI coding agent. Leverage `crystal spec`, `shards`, and `crystal tool format` for deep, context-aware code analysis.