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.

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.

Review a Pull Request in JavaScript With Atlas (2026 Guide)

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.

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.

Step by step

01Run atlas where your package.json lives and let Atlas map your modules, npm scripts, and bundler config.
02Fetch 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.
03Read 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.
04For 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.
05Grep 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.
06Inspect the diff to package.json and the lockfile, since a new dependency changes what pnpm install produces on every other machine.
07Run 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.
08Report the findings as a todowrite list ordered by severity, with correctness bugs above missed callers above stale patterns above style.

Frequently asked questions

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.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Review a Pull Request with Atlas (2026 Workflow)

How to review a pull request with Atlas in 2026: bash produces the raw patch, read pulls whole files, the lsp tool's findReferences checks callers the diff never shows.

Atlas for JavaScript in 2026

In 2026, Atlas empowers JavaScript developers with a terminal-native AI coding agent. It indexes code by AST, uses local embeddings, and offers permission-gated tools for safe, efficient development.

Audit a JavaScript Repo with Parallel Subagents in 2026

In 2026, JavaScript developers use Atlas to sweep entire repositories for code issues. Leverage parallel subagents to audit pnpm projects, vitest configurations, and prettier formatting without blowing your main context

Plan a Multi-File Change Before Editing in JavaScript with Atlas in 2026

Plan a multi-file JavaScript change before editing in 2026. Atlas's plan agent denies edit outside .atlas/plans/*.md, and plan_exit gates the build agent handoff.

Document a JavaScript Module with a README Using Atlas (2026)

How Atlas writes a README for a JavaScript module in 2026: enumerate exports with the lsp tool, read the source, verify every sample with vitest and pnpm.

Run Atlas Headless in CI in a JavaScript Project (2026)

Run Atlas non-interactively in a JavaScript pipeline. `atlas run` sends one prompt, streams events to stdout, supports --format json, and exits when the session goes idle.

Locate Where a Behavior Is Implemented in JavaScript with Atlas in 2026

Find the exact JavaScript file and symbol behind a behavior in 2026. Atlas pairs codebase_search with grep over ripgrep and the lsp tool's findReferences.

Extract a shared helper from duplicated code in JavaScript with Atlas (2026)

Collapse copy-pasted JavaScript into one helper in 2026: Atlas finds semantic duplicates with codebase_search, writes the module, and swaps each copy with apply_patch.

Browse this resource hub