# Self-review your working diff before committing in Rust with Atlas (2026) > Atlas self-reviews a Rust working diff before commit: bash surfaces the raw diff, snapshots back a session revert, and cargo test plus rustfmt close the loop. 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. ## Key takeaways - Atlas can read its own working tree: the VCS layer surfaces status and the raw Rust diff through the bash tool. - Read the whole diff, including files you do not remember touching, because a session that fixed a borrow-checker error often also touched Cargo.toml. - Read each changed .rs file in full, since cargo build will happily compile a stray .unwrap() or an unintended .clone() in a hot path. - Grep for Rust leftovers specifically: dbg!, #[ignore], #[allow(dead_code)], todo!(), and unimplemented!(). - Atlas snapshots file changes as git patches, so session revert restores an unwanted edit rather than requiring a hand-revert. - Revert refuses to run on a busy session, which prevents a half-written turn from being rolled back mid-flight. ## 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. ## Steps 1. Run atlas in the crate with a Cargo.toml so it can see your modules, traits, and cargo workspace. 2. Produce 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. 3. Read 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. 4. Grep for debugging leftovers you introduced: dbg! and println! calls in src/, #[ignore] attributes on tests, #[allow(dead_code)], and todo!() or unimplemented!() panics. 5. Check 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. 6. 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, so a half-written turn is never rolled back mid-flight. 7. Run cargo test through Atlas's bash tool with a generous timeout in milliseconds, since a large workspace suite can be slow. 8. Run rustfmt over the changed files so the reviewer sees your logic rather than reflowed lines. 9. Let Atlas stage and create the commit only once cargo test is green and the diff reads the way you intend. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/self-review-a-working-diff-before-committing-in-rust Source of truth: aeo_pages row `/resources/stacks/self-review-a-working-diff-before-committing-in-rust` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.