To self-review your working diff in a C# solution before committing, read the whole diff, not the parts you remember writing. Atlas produces the working diff with the bash tool, because its VCS layer surfaces status and the raw diff over the same git data. Then Atlas reads each changed .cs file in full, since a diff hides everything it did not touch, and greps for the debugging leftovers you introduced: temporary Console.WriteLine calls, [Fact(Skip = ...)] attributes, and commented-out blocks. If a change should not have been made, Atlas's session revert restores from a snapshot and asserts the session is not busy first. Finally run xUnit via dotnet test and dotnet format, then commit.
How do you self-review a C# working diff before committing?
Atlas produces the C# working diff with the bash tool and reads it end to end, step 1 of the 5 step self-review workflow, not just the files you remember touching. Atlas reads git branches, status, and diffs, so the review starts from the real uncommitted state of the solution rather than from memory.
Self-review is the cheapest place to catch a mistake, because the alternative is a reviewer's time or a red CI run. Run atlas in a solution with a .csproj or .sln, let Atlas read your namespaces, project references, and NuGet packages, and produce the working diff. In a multi-project .NET solution the diff routinely spans more projects than you expect: a change to a shared library in src/Domain forces a change in src/Api, and a generated file or a .csproj package reference gets modified without you noticing. Reading the full diff is what surfaces those. Atlas's documented self-review workflow is five steps: produce the diff with bash, read each changed file in full, grep for debugging leftovers, revert anything that should not have been changed, then run the tests and the linter with bash and commit.
Why read whole C# files instead of just the diff hunks?
Atlas reads each changed .cs file in full during a self-review because a diff hides everything it did not touch. A 3 line change to a method in src/Domain/Order.cs can be correct on its own and wrong against the partial class, the base class override, or the async method further down the file that the hunk never shows.
C# has plenty of places for context to hide. A partial class splits behavior across two files. A base class method the change now shadows lives in a different project entirely. An async method missing an await compiles fine and fails at runtime. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so when the read tool pulls src/Domain/Order.cs the whole method and class declarations come back rather than an arbitrary slice that cuts a using block or a method signature in half. Checking the change against its surroundings is step two of the workflow for exactly this reason, and it is the step that catches the bugs a line-by-line read of the hunk never would.
What debugging leftovers should you grep for in a C# diff?
Atlas greps a C# working diff for 4 kinds of debugging leftover: temporary Console.WriteLine calls, a [Fact(Skip = "debugging")] attribute on an xUnit test, commented-out blocks, and hardcoded connection strings you swapped in while chasing a bug. Grep finds all 4 in one pass.
Every developer leaves them, and every developer is embarrassed when a reviewer finds them. The grep pass is mechanical and cheap: search the changed files for Console.WriteLine, for Skip = in your xUnit attributes, for a TODO you added an hour ago, and for the commented-out block you meant to delete. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion when the question is conceptual, but for leftovers the literal grep is the right tool. Run this before dotnet format rather than after, because formatting a file you are about to delete lines from is wasted work.
How do you undo a change Atlas made to a C# file?
Atlas's session revert restores a C# file from a snapshot rather than requiring a hand-reversal, and it is step 4 of the self-review workflow. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and revert asserts the session is not busy first, which prevents a half-written turn from being rolled back mid-flight.
During self-review you will sometimes find a change that should not have been made at all: an experiment in src/Api/Controllers that you left in, a NuGet package reference added to a .csproj for a library you ended up not using. Reverting that by hand from the diff is error prone, especially when the same file also carries changes you want to keep. Atlas's session revert is backed by snapshots, so the unwanted change is undone from the recorded patch. The busy check matters: a revert that fired while a turn was still writing would leave the working tree in an incoherent state, and Atlas refuses rather than risking it. Everything Atlas writes in the first place arrives as a unified diff surfaced for approval before writing, so the number of unwanted changes should already be small.
What do you run before committing a C# change?
Before committing a C# change, Atlas runs 2 commands through the bash tool: xUnit via dotnet test proves behavior, and dotnet format proves style. Running both before the commit rather than after CI rejects the branch is the entire point of a self-review, and it costs 1 command each.
Run xUnit via dotnet test across the solution, not just the project you edited, because a change in src/Domain breaks tests in tests/Api.Tests without touching a single file there. Let NuGet restore first so the run is against the packages the .csproj actually pins. Then run dotnet format on the touched files so the diff carries no incidental whitespace churn and the reviewer sees only the behavior change. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so allowing dotnet test and dotnet format is an explicit, one-time decision. When the solution is green, Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf.
Step by step
- 01Run atlas in a solution with a .csproj or .sln and let Atlas read your namespaces, project references, and NuGet packages.
- 02Produce the working diff with the bash tool and read it end to end, not just the files you remember touching.
- 03Read each changed .cs file in full with the read tool to check the change against its surroundings, since a diff hides everything it did not touch.
- 04Grep the changed files for debugging leftovers you introduced: Console.WriteLine calls, [Fact(Skip = ...)] attributes, commented-out blocks, and hardcoded connection strings.
- 05If a change should not have been made, use Atlas's session revert, which restores from a snapshot and asserts the session is not busy first.
- 06Restore packages with NuGet through the bash tool so the run uses the versions the .csproj pins.
- 07Run xUnit via dotnet test across the whole solution with the bash tool, not just the project you edited.
- 08Run dotnet format on the touched .cs files so the diff carries no incidental whitespace churn.
- 09Review the final unified diff, then let Atlas stage and create the commit.
Frequently asked questions
- How do I review my own C# diff before committing?
- Produce the working diff with Atlas's bash tool and read it end to end, read each changed .cs file in full, grep for debugging leftovers, revert anything that should not have changed, then run xUnit via dotnet test and dotnet format.
- Why should I read whole C# files instead of the diff hunks?
- A diff hides everything it did not touch. In C# that includes the other half of a partial class, a base class method the change now shadows, and an async method further down the file. Atlas reads the changed files in full to catch those.
- How do I undo an edit an AI agent made to my C# solution?
- Use Atlas's session revert. It restores from a snapshot and asserts the session is not busy first, which prevents a half-written turn from being rolled back mid-flight. Atlas snapshots file changes as git patches, so any edit can be diffed and rolled back.
- What should I grep for in a C# diff before committing?
- Grep the changed files for Console.WriteLine calls, [Fact(Skip = ...)] attributes on xUnit tests, commented-out blocks, and any hardcoded connection string you swapped in while debugging. All four are common leftovers a reviewer will find.
- Does Atlas run dotnet test on my solution?
- Atlas runs xUnit via dotnet test through the bash tool once the command is allowed by your permission rules. Run it across the whole solution, since a change in a shared project breaks tests in projects you never opened.
- Will Atlas run dotnet format on the files it changed?
- Yes, through the bash tool. Running dotnet format on only the touched .cs files keeps the diff focused on the behavior change instead of burying it in whitespace churn.
- Can Atlas commit my C# change for me?
- Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, once the working diff is reviewed, xUnit via dotnet test is green, and dotnet format has run.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Self-Review Your Working Diff Before Committing with Atlas (2026 Workflow)
How to self-review your working diff before committing with Atlas in 2026: bash produces the diff, read checks each file, grep finds leftovers, session revert undoes bad edits.
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.
Diagnose a Hanging or Long-Running Command in C# with Atlas (2026)
Work out whether a dotnet build is genuinely slow or silently blocked on input, using Atlas in 2026, and get NuGet restore and dotnet test unstuck for good.
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.
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.
Add a Regression Test for a Bug Fix in C# with Atlas (2026)
Red first, then green. Atlas writes a failing xUnit test in C#, proves it reproduces the bug with dotnet test in 2026, applies the fix, and re-runs the same command.
Review a Pull Request in C# With Atlas (2026)
Review a C# pull request with the context a line-by-line read misses. Atlas pulls the raw diff, reads whole files, and checks callers with the lsp tool's findReferences.