To review a TypeScript pull request, Atlas reviews the way a careful human does: it gets the diff, then leaves the diff. The bash tool produces the changed files and the raw patch, read pulls the full .ts files rather than the hunks, and the lsp tool's findReferences operation checks whether a changed function signature broke a caller the diff never shows. Running vitest and reporting findings as a todowrite list ordered by severity closes the review.
How do I review a TypeScript PR with more context than the diff shows?
Atlas gets the TypeScript diff, then leaves the diff. The bash tool produces the changed files and the raw patch across the 4 git views Atlas exposes, status, diff, diffRaw, and commits, and read pulls each .ts file in full, so the code above and below a hunk is visible.
A diff is a lossy view of a change. A modified function in src/services/billing.ts can be perfectly correct in isolation and still be wrong given the guard clause forty lines above it that the patch left alone. Atlas reads the full file rather than the hunks, so the type narrowing, the early returns, and the surrounding generics are all in context. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so fetching the branch and producing the patch does not require leaving the terminal.
How do I check whether a changed TypeScript signature broke its callers?
For every changed function signature in a TypeScript PR, Atlas runs the lsp tool's findReferences operation to check callers the diff never touched. 1 parameter that became optional, or a return type that gained undefined, can break a call site in a package the pull request never opened.
TypeScript's structural typing means a signature change propagates in ways a reviewer cannot hold in their head, especially across a pnpm workspace with path aliases in tsconfig.json. findReferences returns the true caller list from the language server, so a widened union or a newly nullable field is checked at every consuming site rather than at the ones the author happened to update. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so the callers come back as real declarations you can open and read.
What should I grep for when reviewing a TypeScript pull request?
Atlas greps a TypeScript PR for the patterns the change should have updated but did not: old constant names, stale copies of a type, and feature flags left behind. Those 3 misses are why a PR that renamed a config key in src/config.ts but missed the string in a test fixture still passes a line-by-line read.
The absence of a change is invisible in a diff, which is why grep is a review tool and not just a search tool. A TypeScript change often needs matching updates in places the type system does not reach: an environment variable name, a route string, a key in a JSON fixture, a duplicated literal union that should have gained the new member. Grepping for the old value proves the sweep was complete. Because Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, a semantically similar but textually different stale copy also surfaces.
How does Atlas run the TypeScript test suite during a review?
Atlas runs vitest through its bash tool during a TypeScript review, with pnpm resolving the workspace's dependencies. The bash tool records the process exit code in its metadata alongside the output, so an exit code of 1 from vitest is a hard fact, not an impression formed by scrolling output.
Running the tests is the part of review most people skip and most often regret skipping. pnpm installs and links the workspace packages, so vitest exercises the same module graph the pull request will merge into. Prettier over the changed files confirms the PR is not carrying formatting churn that hides real changes. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so running vitest during a review of someone else's branch is a deliberate, approved act.
How do I report findings from a TypeScript code review?
Atlas reports TypeScript review findings as a todowrite list ordered by severity, so a nullable field that will throw at runtime sits above a naming nit. Each item points at 3 things, a file, a symbol, and a specific consequence, which is why a structured list beats a wall of prose.
Severity ordering is what makes a review actionable. The findings that come out of reading the full .ts files, checking callers with findReferences, and grepping for stale copies are exactly the ones a line-by-line read would miss, so they deserve the top of the list. Atlas reads git branches, status, and diffs, so each finding can cite the commit and the file it belongs to. Reviewing a pull request in Atlas changes nothing on the branch: read, lsp, grep, and bash test runs leave the author's code exactly as they wrote it.
Step by step
- 01Run atlas in a project with a tsconfig.json and let Atlas read your type definitions, path aliases, and strictness settings.
- 02Fetch the branch and produce the diff with bash; Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data.
- 03Read the changed .ts files in full with the read tool, not just the hunks, so context outside the diff is visible.
- 04For every changed function signature, run the lsp tool's findReferences operation to check callers the diff never touched.
- 05Grep for the patterns the change should have updated but did not: old constant names, stale copies of a type, and feature flags.
- 06Run the tests with vitest through bash, with pnpm resolving the workspace dependencies.
- 07Check that prettier leaves the changed files unchanged, so the PR is not carrying formatting churn.
- 08Report findings as a todowrite list ordered by severity, each pointing at a file and a symbol.
Frequently asked questions
- how to review a typescript pull request with an AI agent
- Have Atlas produce the raw diff with bash, then read each changed .ts file in full rather than the hunks. Atlas checks changed signatures with the lsp tool's findReferences and runs vitest before reporting findings.
- can atlas find callers a typescript pr broke but did not touch
- Yes. For every changed function signature, the lsp tool's findReferences operation returns the true caller list from the language server, including call sites in packages the pull request never opened.
- why read the whole file instead of the diff when reviewing typescript
- A hunk can be correct in isolation and wrong given a guard clause or type narrowing outside it. Atlas reads the changed .ts files in full so the surrounding context, not just the patch, informs the review.
- does atlas run vitest when reviewing a branch
- Atlas runs vitest through its bash tool with pnpm resolving the workspace dependencies. The bash tool records the process exit code in its metadata, so a red run is unambiguous.
- what does atlas need to review a typescript codebase
- Run atlas in a project with a tsconfig.json. Atlas reads your type definitions, path aliases, and strictness settings, and can tighten types, remove any, or generate typed API clients with the diff shown for approval.
- does reviewing a pr with atlas change the author's branch
- No. A review uses bash, read, lsp, grep, and todowrite, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the branch is left exactly as the author wrote it.
- how should an AI report code review findings
- As a todowrite list ordered by severity, each item naming a file and a symbol. A nullable field that will throw at runtime belongs above a naming nit, and a structured list is easier to act on than prose.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated 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 TypeScript in 2026
In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.
Automate GitHub Issue and Pull Request Triage in TypeScript with Atlas (2026)
Wire the atlas github command into a TypeScript repo's Actions workflow in 2026: set MODEL in provider/model form, gate on write permission, verify with vitest.
Add a Regression Test for a Bug Fix in TypeScript with Atlas (2026)
Red first, then green: how Atlas adds a TypeScript regression test in 2026, proving it fails with vitest, applying the fix with edit, and re-running the same command.
Rename a symbol across the repo in TypeScript with Atlas (2026)
Rename a TypeScript symbol across the whole repo in 2026 with Atlas: findReferences for the true callsite list, grep for strings the compiler cannot see, then vitest.
Run the Test Suite and Triage the Failures in TypeScript with Atlas (2026)
Turn a wall of red vitest output into a ranked list of root causes in 2026: Atlas truncates at 2000 lines, saves the full log, and greps it into a todowrite triage list.
Write Unit Tests for Untested Code in TypeScript with Atlas (2026)
How Atlas writes vitest unit tests for untested TypeScript in 2026: lsp documentSymbol enumerates exports, grep copies your conventions, and pnpm vitest actually runs them.
Extract a Shared Helper From Duplicated Code in TypeScript With Atlas (2026)
How to extract a shared helper from duplicated TypeScript code with Atlas in 2026: codebase_search finds the copies, apply_patch swaps them, vitest proves it.