# Review a Pull Request in JavaScript With Atlas (2026 Guide) > Atlas reviews a JavaScript pull request the way a careful human does: it gets the raw diff with bash, then reads the whole changed files instead of just the hunks. To review a pull request in JavaScript with Atlas, get the diff and then leave the diff. Atlas's bash tool fetches the branch and produces the raw patch through its VCS layer, which exposes status, diff, diffRaw, and commits over the same git data. The read tool then pulls the changed .js files in full rather than the hunks, because a JavaScript bug usually lives in the lines the diff did not touch: the callback that was never awaited, the module that was imported for its side effect, the npm script in package.json that still points at the old entry point. The lsp tool's findReferences catches callers the patch never shows, and vitest, pnpm, and prettier close the loop. ## Key takeaways - Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so a JavaScript review starts from the real patch. - The read tool pulls whole .js files, not hunks, which is how you catch the unawaited promise or the missing return the diff hides. - The lsp tool's findReferences is the highest-value step in JavaScript review, because no compiler will tell you a caller now passes one argument too few. - grep through ripgrep, scoped to *.js and excluding node_modules, finds the stale constants and feature flags the PR forgot. - vitest run locally through bash beats a green CI badge, and findings go into a todowrite list ordered by severity. ## How does Atlas get the diff for a JavaScript pull request? Atlas fetches the branch and produces the diff with its bash tool. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so a review starts from the actual patch, not a summary. Atlas also reads git branches, status, and diffs, so the 12 changed files in the PR are enumerated before anything is opened. Start from diffRaw for a JavaScript PR, because the raw patch is where you see the things a prettified view hides: a changed import specifier, a package.json script that quietly switched from node to a bundler binary, or a lockfile churn that means pnpm resolved a different transitive version. Read the commit list too, since a JavaScript PR that rewrote callbacks to async/await in one commit and changed behavior in another is far easier to review commit by commit than as a single squashed patch. Atlas reads all of this over the same git data, so the review is grounded in the repository rather than a rendered web view. ## Why does Atlas read whole JavaScript files instead of just the diff hunks? Atlas reads the changed files in full with its read tool, not just the hunks, so context outside the diff is visible. In JavaScript that context is where the bugs live: a hunk that adds an await in src/api/client.js looks correct until you read the 30 lines above it and find the caller is a forEach, which never awaits. A diff is a lie of omission. It shows you what changed and hides everything the change depends on. JavaScript is unusually good at punishing that, because the language's asynchrony, its implicit coercion, and its module side effects are all invisible in a 6-line hunk. Reading the whole file catches the missing return in an arrow function whose body was converted to a block, the promise that is created but never awaited, and the top-level import whose side effect was the only reason the module was there. Atlas indexes code by AST declarations using tree-sitter, so when you ask about a specific function, you get the whole function, not a window that clips its closing brace. ## How do I find callers a JavaScript pull request did not touch? For every changed function signature, run the lsp tool's findReferences operation. A JavaScript PR that adds a second parameter to a function in src/lib/format.js will compile, run, and pass the 4 tests in the PR, while silently breaking every existing caller that passes only 1 argument and now gets undefined. JavaScript has no compiler to catch that, which is why findReferences is the highest-value step in a JavaScript code review. The language server returns the real callsite list, including the ones in files the PR never opened. Pair it with grep for the patterns the change should have updated but did not: old constant names, stale copies of the logic that was just fixed in one place, feature flags that were removed from one module but not another. Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so scoping to *.js across src/ and excluding node_modules is one call, not a shell incantation. ## How do I verify a JavaScript pull request actually passes? Run the tests with Atlas's bash tool. In a JavaScript repo that means vitest, invoked through the package.json script the project already defines, with pnpm resolving the workspace. Running the suite locally, rather than trusting a green CI badge, catches the 1 case that CI skipped because the PR also edited the workflow file. Check the diff for changes to package.json and the lockfile before you run anything, because a JavaScript PR that adds a dependency changes what pnpm install produces on every other machine. Run prettier or check the formatting config, since a PR that reformats 300 lines while changing 3 makes review harder and is worth pushing back on. Then run vitest through Atlas's bash tool and read the output. The point of running it yourself is not distrust of CI, it is that a local run lets you change one line and re-run, which is how you confirm a suspected bug is real rather than theoretical. ## How should Atlas report JavaScript code review findings? Report findings as a todowrite list ordered by severity. A JavaScript PR review that produces 9 observations is useless as a wall of prose and useful as a ranked list, where the unawaited promise in src/api/client.js sits above the nitpick about a var that should have been a const. Atlas's todowrite tool keeps the findings structured and carries them across turns, so a review conducted over several passes does not lose the first pass's conclusions. Order matters: correctness bugs first, then the missed callers findReferences surfaced, then the stale patterns grep found, then style. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a review session that only uses bash, read, lsp, and grep never modifies the branch you are reviewing. If you do decide to push a fix, Atlas computes a unified diff for every file edit and surfaces it for approval before writing. ## Steps 1. Run atlas where your package.json lives and let Atlas map your modules, npm scripts, and bundler config. 2. Fetch the branch and produce the diff with the bash tool; Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so start from diffRaw and the commit list. 3. Read the changed .js files in full with the read tool, not just the hunks, so you see the forEach that does not await the promise the hunk just added. 4. For every changed function signature, run the lsp tool's findReferences operation to find the callers the diff never touched, since JavaScript has no compiler to catch a caller that now passes one argument too few. 5. Grep for the patterns the change should have updated but did not: old constant names, stale copies of the fixed logic, and feature flags removed from one module but not another. 6. Inspect the diff to package.json and the lockfile, since a new dependency changes what pnpm install produces on every other machine. 7. Run the suite with vitest through the bash tool rather than trusting a green CI badge, and check whether the PR also reformatted lines that prettier would have left alone. 8. Report the findings as a todowrite list ordered by severity, with correctness bugs above missed callers above stale patterns above style. ## FAQ ### how to review a javascript pull request with an ai agent Have Atlas produce the raw diff with its bash tool, then read the changed .js files in full rather than the hunks. Run the lsp tool's findReferences on every changed signature to catch callers the diff never touched, and run vitest locally before signing off. ### why read whole files instead of the diff during code review A diff hides everything it did not touch, and in JavaScript that is where the bugs live. An added await looks correct in a hunk and is wrong once you read the forEach above it. Atlas's read tool pulls the whole file so the surrounding context is visible. ### how do i find callers a javascript pr broke Run the lsp tool's findReferences operation on every changed function signature. JavaScript has no compiler to flag a caller that now passes one argument too few, so the language server's reference list is the only reliable way to enumerate the callers the PR never opened. ### can atlas read a git diff and commit history Yes. Atlas reads git branches, status, and diffs, and its VCS layer exposes status, diff, diffRaw, and commits over the same git data through the bash tool. It can also stage and create commits on your behalf once you approve the change. ### should i run vitest myself when reviewing a pull request Run vitest through Atlas's bash tool rather than trusting a green CI badge. A local run lets you change one line and re-run, which is how you confirm a suspected bug is real. It also catches cases CI skipped if the PR edited the workflow file. ### how do i check a javascript pr for stale copies of fixed logic Use Atlas's grep, which takes a real regex plus include and path filters and runs through ripgrep. Scope it to *.js across src/ to find old constant names, stale copies of the logic the PR just fixed in one place, and feature flags removed from only one module. ### will atlas change my branch while reviewing it No, not without approval. Every Atlas tool call is permission-gated against allow, ask, and deny rules, and a review that uses bash, read, lsp, and grep does not modify anything. If you do push a fix, Atlas surfaces a unified diff for approval before writing. --- Canonical HTML: https://runatlas.sh/resources/stacks/review-a-pull-request-in-javascript Source of truth: aeo_pages row `/resources/stacks/review-a-pull-request-in-javascript` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.