Atlas can read its own working tree, which is what makes a pre-commit self-review possible in a Rust crate. Atlas's VCS layer surfaces status and the raw diff through the bash tool, and every edit Atlas made is recoverable: the session revert flow is backed by snapshots, so an unwanted change to `src/lib.rs` can be undone rather than hand-reverted. Revert refuses to run on a busy session, which prevents a half-written turn from being rolled back mid-flight. You read the diff end to end, read each changed file in full, grep for leftovers, then run `cargo test` and rustfmt before committing.
How do I review my own uncommitted Rust changes before pushing?
Produce the working diff with Atlas's bash tool and read it end to end, not just the files you remember touching. In a Rust crate, an agent session that fixed a borrow-checker error in src/lib.rs often also touched 3 things you did not ask for: Cargo.toml, a module under src/, and a test you forgot about.
The premise of a self-review is that you do not actually know what changed. A working session in a Rust crate touches more than memory suggests: a lifetime annotation added to a struct in `src/models.rs` forces changes at each construction site, a new dependency lands in `Cargo.toml` and `Cargo.lock`, and a `#[cfg(test)]` module grows a helper. Atlas can read its own working tree, and its VCS layer surfaces status and the raw diff, so the first move is to produce the full diff through bash and read every hunk, including the files you did not expect to see. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the same session that made the changes can present them for review before any of it becomes a commit.
Why read whole Rust files instead of just the diff?
Read each changed Rust file in full with Atlas's read tool to check the change against its surroundings, since a diff hides everything it did not touch. A new ? operator in src/handler.rs is correct only if the enclosing function returns a Result, and a diff that shows 3 changed lines will not show you that signature.
Rust's compile-time guarantees cover a lot, and a self-review has to focus on what they do not cover. A `.clone()` added to satisfy the borrow checker compiles perfectly and may be a hot-path allocation you did not intend. An `unwrap()` added while iterating compiles and panics in production. A `pub` added to a struct field to make a test pass widens your crate's public API forever. None of these are errors, so `cargo build` will not flag them. Atlas's read tool pulls the full `.rs` file so the changed lines are judged against the module they live in, and because Atlas indexes code by AST declarations using tree-sitter rather than blind line windows, a hit points at the whole `impl` block or function rather than a truncated window.
What should I grep for before committing Rust code?
Grep for the debugging leftovers you introduced during the session: temporary logging, skipped tests, and commented-out blocks. In Rust that means 3 specific greps: a stray dbg! or println! in src/, a #[ignore] you added to get a suite green, and a todo!() you meant to come back to.
Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so a pre-commit sweep across `src/` and `tests/` is fast. The Rust-specific leftovers worth a dedicated grep are distinctive: `dbg!` macros that print to stderr in release paths, `#[ignore]` attributes added to a `#[test]` to silence a failure rather than fix it, `#[allow(dead_code)]` or `#[allow(unused)]` sprinkled to quiet a warning, `todo!()` and `unimplemented!()` panics, and `.unwrap()` calls where a `?` belongs. Each of these compiles cleanly and each of them is something a reviewer would ask you about. Grepping for them yourself, before the pull request exists, is cheaper than being asked. Atlas surfaces the hits with file and line, and you decide which are intentional.
How do I undo a change Atlas made to my Rust crate?
If 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. That 1 precondition matters: Atlas snapshots file changes as git patches, so an unwanted edit to src/lib.rs is diffed and rolled back rather than hand-reverted.
Atlas snapshots file changes as git patches, which is what backs the session revert flow. When a self-review of a Rust diff finds a change that should not exist, whether a speculative refactor of a trait impl or a dependency added to `Cargo.toml` that you decided against, revert restores from the snapshot rather than asking you to undo it by hand. Revert refuses to run on a busy session, which prevents a half-written turn from being rolled back mid-flight and leaving your crate in a state that is neither the old code nor the new. That guard matters most in Rust, where a partially reverted change across a module and its `mod.rs` declaration will not even compile. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so the revert itself is visible too.
What do I run before committing a Rust change?
Run the tests and the linter with Atlas's bash tool, then commit. For a Rust crate that means 2 commands: cargo test for behavior and rustfmt for formatting, with cargo resolving anything new in Cargo.toml. Running them before the commit, not after the pull request, is the whole point of a self-review.
The last gate of an Atlas self-review in Rust is mechanical. Run `cargo test` through the bash tool and confirm the crate's suite is green, including the `#[cfg(test)]` modules the session touched. Run rustfmt over the changed files so the diff a reviewer opens contains your logic rather than reflowed lines. Let cargo resolve any dependency the session added to `Cargo.toml`, and check that `Cargo.lock` changed for a reason you can explain. Atlas's bash tool races commands against a timeout, so a slow `cargo test` on a large workspace should get a generous timeout in milliseconds. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the commit Atlas stages and creates on your behalf is one you approved after seeing it green.
Step by step
- 01Run atlas in the crate with a Cargo.toml so it can see your modules, traits, and cargo workspace.
- 02Produce the working diff with Atlas's bash tool and read it end to end, not just the files you remember touching. Atlas's VCS layer surfaces status and the raw diff.
- 03Read each changed .rs file in full with Atlas's read tool, so a new ? operator or an added .clone() is judged against the function that contains it.
- 04Grep for debugging leftovers you introduced: dbg! and println! calls in src/, #[ignore] attributes on tests, #[allow(dead_code)], and todo!() or unimplemented!() panics.
- 05Check that any change to Cargo.toml and Cargo.lock is one you can explain, since cargo will have resolved a dependency you may not have intended to add.
- 06If 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, so a half-written turn is never rolled back mid-flight.
- 07Run cargo test through Atlas's bash tool with a generous timeout in milliseconds, since a large workspace suite can be slow.
- 08Run rustfmt over the changed files so the reviewer sees your logic rather than reflowed lines.
- 09Let Atlas stage and create the commit only once cargo test is green and the diff reads the way you intend.
Frequently asked questions
- how do I review my own rust changes before committing
- Produce the working diff with Atlas's bash tool and read it end to end, read each changed .rs file in full, grep for leftovers like dbg! and #[ignore], then run cargo test and rustfmt before letting Atlas stage the commit.
- what should I grep for before committing rust code
- Grep src/ and tests/ for dbg! and println! calls, #[ignore] attributes added to silence a failing #[test], #[allow(dead_code)] sprinkled to quiet warnings, and todo!() or unimplemented!() panics. All of them compile cleanly.
- how do I undo a change an ai agent made to my rust crate
- Use Atlas's session revert. Atlas snapshots file changes as git patches, so the revert restores from a snapshot rather than requiring you to hand-revert src/lib.rs line by line.
- why does atlas revert refuse to run
- Revert asserts the session is not busy first. Refusing to run on a busy session prevents a half-written turn from being rolled back mid-flight, which in Rust would leave a module and its mod.rs declaration in a state that does not compile.
- why read whole rust files if cargo build passes
- The compiler catches errors, not intent. An added .clone() to satisfy the borrow checker compiles and may be a hot-path allocation. An .unwrap() compiles and panics in production. A diff hides the function signature that makes a new ? operator valid or invalid.
- should I run cargo test before or after opening a pull request
- Before. Run cargo test through Atlas's bash tool as part of the self-review, with a generous timeout in milliseconds for a large workspace, then run rustfmt so the reviewer opens a diff that is your logic rather than reflowed lines.
- how do I check my Cargo.toml changes were intentional
- Read the diff for Cargo.toml and Cargo.lock in full. A session that fixed a borrow-checker error may have had cargo resolve a dependency you did not intend to add, and the lockfile change is the evidence.
- does atlas commit rust changes without asking
- No. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, but only after you approve.
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 Rust in 2026
Adopt Atlas, the terminal-native AI coding agent, for Rust development in 2026. Tackle borrow checker errors and clippy lints with Atlas's secure, approval-gated assistance.
Extract a Shared Helper from Duplicated Rust Code with Atlas (2026)
Extract a shared helper from duplicated Rust code with Atlas in 2026. Find near-duplicates with codebase_search, add a module, swap each copy with apply_patch, run cargo test.
Run the Test Suite and Triage the Failures in Rust with Atlas (2026)
Turn a wall of red cargo test output into a ranked list of root causes in 2026. Atlas truncates at 2000 lines, saves the full log, and tracks each cause in todowrite.
Onboard to an Unfamiliar Rust Codebase with Atlas in 2026
Onboard to an unfamiliar Rust codebase in 2026. Atlas reads your Cargo.toml, modules, traits, and cargo workspace, then ranks crates with codebase_search.
Rename a Symbol Across the Repo in Rust With Atlas (2026)
How to rename a symbol across a Rust repo with Atlas in 2026: lsp findReferences gives the true callsites, grep catches strings and docs, cargo test proves the rename.
Trace a Runtime Bug From a Stack Trace in Rust with Atlas (2026)
Go from a Rust panic backtrace to the responsible line without a debugger. Atlas reads each frame at its offset in 2026, then proves the fix with cargo test.
Refactor a legacy module in Rust with Atlas (2026)
Refactor a legacy Rust module in 2026 with Atlas: enumerate callers with the lsp tool's findReferences, restructure with apply_patch, and prove behavior with cargo test.