how to review a C# pull request with an AI agent

Have Atlas produce the raw diff with bash, read the changed .cs files in full rather than the hunks, run the lsp tool's findReferences on every changed method signature, grep for stale constants and appsettings keys, then run `dotnet test` and report findings as a triaged todowrite list.

can Atlas find C# callers that a pull request forgot to update

Yes. The lsp tool's findReferences operation returns every callsite of a changed method, including callers in dependent projects the pull request never touched. That list is the highest-severity review finding in most C# solutions.

does Atlas run dotnet test during a code review

Yes, through the bash tool. `dotnet test` executes the xUnit suite across the solution, and `dotnet format --verify-no-changes` separates formatting noise from behavior so the review is about the actual change.

why read whole files instead of the diff in a C# review

A diff hides everything it did not touch. In C# that means the class's other members, its constructor injection and service lifetime, its IDisposable implementation, and the xUnit tests that cover it, all of which decide whether a changed method is actually correct.

can an AI reviewer edit my C# code by accident

Not if you deny the edit tools. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and bash, read, the lsp tool, and grep, which are the whole review toolset, keep working with edits denied.

what should I check in a .csproj during a C# pull request review

Check for a quietly added NuGet PackageReference, a version bump on an existing one, and any change to TargetFramework or Nullable. Those change compilation and behavior for the whole project and no .cs hunk will show them to you.

how do I review a very large C# pull request

Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large solution can be reviewed project by project in parallel while you read the core change yourself. Collect the results into one severity-ordered todowrite list.

how do I start Atlas in a C# project

Run atlas in a solution with a .csproj or .sln. Atlas reads your namespaces, project references, and NuGet packages, and you can ask it to add xUnit tests or refactor async code, reviewing the diff before dotnet build.

Review a Pull Request in C# With Atlas (2026)

Atlas reviews a C# pull request the way a careful human does: it gets the diff, then leaves the diff. Atlas's bash tool produces the changed files and the raw patch, and its VCS layer exposes status, diff, diffRaw, and commits over the same git data. read then pulls the full .cs files rather than the hunks, because a diff hides everything it did not touch, and the lsp tool's findReferences checks whether a changed method signature broke a caller in a project the diff never shows. Findings come back as a todowrite list ordered by severity, and `dotnet test` runs the xUnit suite before you sign off.

How do you get a C# pull request's diff into an AI reviewer's context?

Fetch the branch and produce the diff with Atlas's bash tool. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so a C# pull request touching 9 .cs files across 3 projects in the .sln lands in context as a real patch rather than a summary.

Start with the raw patch, not a description of it. Run the fetch and the diff through bash, and read what actually changed: the modified method bodies, the new NuGet package references in the .csproj, and any change to a `<TargetFramework>` or `<Nullable>` setting, which alters compilation for the whole project and is easy to skim past. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the review session is anchored to the real working tree. Note which projects in the solution are affected: a change in a shared library project referenced by 4 others has a blast radius the diff alone will not show you, and that is the number the rest of the review is about.

Why should a C# reviewer read whole files instead of just the diff hunks?

Atlas reads the changed C# files in full with its read tool, not just the diff hunks, because a hunk that adds an `await` inside a method says nothing about whether the enclosing class is registered as a singleton in Program.cs. In 2026 that combination is still where a real .NET bug lives.

A diff is a lossy view. In C# the loss is specific and dangerous: the hunk shows a changed method but not the class's other members, not the `IDisposable` implementation it must respect, not the constructor injection that decides its lifetime, and not the `[Fact]` and `[Theory]` attributes on the xUnit tests that cover it. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so reading a file gives you whole method and class declarations rather than a window cut through a `switch` expression. Read the .csproj too. A quietly added NuGet package reference, or a `PackageReference` version bump, can change behavior in ways no .cs hunk reveals, and reviewers skip it almost every time.

How do you find C# callers a pull request did not touch?

Atlas runs its lsp tool with the findReferences operation on every changed method signature, which is step 3 of the documented review workflow, to name the callers the diff never touched. In a C# solution, a signature change in a shared library project breaks compilation in dependent projects the pull request does not include.

The C# compiler will eventually catch a broken caller, but only if the caller is in the solution and only when someone builds it. findReferences gives you the list during the review, before merge, which is when it is cheap to fix. Pay closest attention to changed optional parameters and changed default values: adding a parameter with a default keeps every caller compiling while silently changing behavior at each one, and that is a review finding no compiler will hand you. Then grep for the patterns the change should have updated but did not: old constant names, stale copies of a modified helper, feature flag strings, and appsettings.json keys. Atlas's grep takes a real regex plus include and path filters, so scoping to `**/*.cs` while including `appsettings*.json` is one pass.

How do you run and report on a C# pull request's tests?

Atlas runs the tests with its bash tool using `dotnet test`, which executes the xUnit suite across the solution, then reports findings as a todowrite list ordered by severity. In 2026 a pull request that adds a method but no `[Fact]` for it is a review finding, and a green `dotnet test` is a floor for approval, not proof of correctness.

Read what the xUnit tests actually assert, not just whether they are green. A test that mocks the dependency it should be exercising will pass regardless of the change under review. Run `dotnet format --verify-no-changes` too, so formatting noise is separated from substantive changes and the review is about behavior. Then report findings as a todowrite list ordered by severity, so the pull request author gets a triaged list rather than a wall of comments: broken callers found by findReferences first, missing xUnit coverage next, then style. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large C# pull request can be reviewed project by project in parallel while you read the core change yourself.

How does Atlas keep a C# code review read-only and safe?

Atlas gates every tool call against 3 rule types, allow, ask, and deny, before it runs, which is how a C# review stays read-only. Deny the edit tools and bash, read, the lsp tool, and grep all keep working, and that is the entire toolset a pull request review needs.

A reviewer should not be able to fix the code by accident. Atlas also drafts a plan in a read-only plan agent and asks before switching to a build agent, which is a natural fit for review: gather findings with no write capability, and only switch to a build agent if you decide to push a fix yourself. If you do edit, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and Atlas snapshots file changes as git patches so any change can be diffed and rolled back. For a private .NET solution, Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so reviewing proprietary C# does not mean shipping it to a vendor's index.

Step by step

01Run atlas in the C# solution root, the directory with the .sln or the top-level .csproj, so every project in the solution is in scope.
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 .cs files in full with read, not just the hunks, so class members, constructor injection, and IDisposable implementations outside the diff are visible.
04Read the .csproj as carefully as the source, checking for a quietly added NuGet PackageReference or a changed TargetFramework or Nullable setting.
05For every changed method signature, run the lsp tool's findReferences operation to check callers in dependent projects the pull request never touched.
06Grep for the patterns the change should have updated but did not: old constant names, stale copies of a modified helper, feature flags, and appsettings.json keys.
07Run `dotnet test` with bash to execute the xUnit suite, and run `dotnet format --verify-no-changes` so formatting noise is separated from behavior.
08Report findings as a todowrite list ordered by severity: broken callers first, missing xUnit coverage next, then style.

Frequently asked questions

how to review a C# pull request with an AI agent: Have Atlas produce the raw diff with bash, read the changed .cs files in full rather than the hunks, run the lsp tool's findReferences on every changed method signature, grep for stale constants and appsettings keys, then run `dotnet test` and report findings as a triaged todowrite list.
can Atlas find C# callers that a pull request forgot to update: Yes. The lsp tool's findReferences operation returns every callsite of a changed method, including callers in dependent projects the pull request never touched. That list is the highest-severity review finding in most C# solutions.
does Atlas run dotnet test during a code review: Yes, through the bash tool. `dotnet test` executes the xUnit suite across the solution, and `dotnet format --verify-no-changes` separates formatting noise from behavior so the review is about the actual change.
why read whole files instead of the diff in a C# review: A diff hides everything it did not touch. In C# that means the class's other members, its constructor injection and service lifetime, its IDisposable implementation, and the xUnit tests that cover it, all of which decide whether a changed method is actually correct.
can an AI reviewer edit my C# code by accident: Not if you deny the edit tools. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and bash, read, the lsp tool, and grep, which are the whole review toolset, keep working with edits denied.
what should I check in a .csproj during a C# pull request review: Check for a quietly added NuGet PackageReference, a version bump on an existing one, and any change to TargetFramework or Nullable. Those change compilation and behavior for the whole project and no .cs hunk will show them to you.
how do I review a very large C# pull request: Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large solution can be reviewed project by project in parallel while you read the core change yourself. Collect the results into one severity-ordered todowrite list.
how do I start Atlas in a C# project: Run atlas in a solution with a .csproj or .sln. Atlas reads your namespaces, project references, and NuGet packages, and you can ask it to add xUnit tests or refactor async code, reviewing the diff before dotnet build.

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 C# in 2026

Atlas is a terminal-native AI coding agent for C# and the .NET SDK in 2026. Run it in a solution with a .csproj or .sln and approve every diff before dotnet build.

Plan a Multi-File Change Before Editing in C# with Atlas (2026)

Design a C# refactor across many files in 2026 before touching one line. Atlas plan mode denies every edit tool, writes a plan, then hands off with plan_exit.

Locate Where a Behavior Is Implemented in C# with Atlas (2026)

Find the exact C# file and symbol behind a behavior in 2026: Atlas attacks a .sln from three angles with codebase_search, grep through ripgrep, and the lsp tool.

Automate GitHub Issue and Pull Request Triage in C# with Atlas in 2026

Automate GitHub issue and pull request triage for C# projects in 2026 using Atlas. Safely manage workflows, enforce trusted user access, and integrate with dotnet tools like xUnit and NuGet.

Migrate a deprecated API across every callsite in C# with Atlas in 2026

Migrate deprecated C# APIs across your entire codebase with Atlas in 2026. Safely replace every callsite, leveraging `dotnet test` and `NuGet` for verified, complete refactoring.

Research a third-party API before integrating it in C# with Atlas (2026)

Use Atlas websearch and webfetch to pull a live API doc into context before writing C# integration code in 2026, then verify with dotnet format and dotnet test.

Write Unit Tests for Untested Code in C# with Atlas (2026)

Add real xUnit coverage to an untested C# class. Atlas enumerates public members with the lsp tool in 2026, copies your repo conventions, and runs dotnet test.

Browse this resource hub