# Self-review your working diff before committing in Phoenix with Atlas in 2026 > Phoenix developers can use Atlas to self-review uncommitted diffs, ensuring code quality with mix test (ExUnit) and mix format before committing. Phoenix developers in 2026 can effectively self-review their uncommitted diffs using Atlas to catch mistakes before they reach a reviewer or CI. Atlas integrates directly with your Phoenix codebase, allowing you to inspect changes, run mix test (ExUnit) for verification, and apply mix format for consistent styling, all within your terminal environment. ## Key takeaways - Atlas provides a unified diff view for your Phoenix project, ensuring comprehensive self-review of all uncommitted changes. - Use Atlas's `grep` tool to eliminate debugging artifacts like `IO.inspect` or skipped `ExUnit` tests from your Phoenix code. - Execute `mix test (ExUnit)` and `mix format` directly within Atlas, with permission prompts, for Phoenix code quality and consistency. - Atlas's session revert safely undoes unwanted changes in your Phoenix working tree, backed by snapshots, preventing accidental commits. - Atlas understands Phoenix contexts, LiveView sockets, and Ecto changesets for relevant code indexing and intelligent assistance. ## How Atlas helps Phoenix developers produce and read their working diff In 2026, Phoenix developers can use Atlas to produce and read their working diffs directly in the terminal, ensuring a thorough review of all uncommitted changes. Atlas reads git branches, status, and diffs, presenting a unified view of your modifications across 1 or more files. Atlas's VCS layer surfaces the raw diff for your Phoenix project, allowing you to see all uncommitted changes. This ensures you review the entire working diff, not just the files you remember modifying. Atlas presents a unified diff for every file edit, making it easy to check changes against their surroundings in `lib/_web` directories, Ecto schemas, or LiveView modules. The `read` tool in Atlas allows for end-to-end inspection of changed files, ensuring that every modification, no matter how small, is scrutinized before it progresses to a reviewer or CI. This comprehensive approach helps catch subtle errors that might otherwise be overlooked. ## Catching debugging leftovers in Phoenix code with Atlas Before committing your Phoenix changes, it is crucial to catch any debugging leftovers like temporary logging or skipped tests. Atlas, in 2026, provides a powerful `grep` tool that can scan your working diff for common debugging patterns, helping you clean up your code in under 1 minute. Phoenix developers often introduce temporary `IO.inspect` calls, `Logger.debug` statements, or commented-out code blocks during development. Atlas's `grep` tool can be used to search your working diff for these patterns, as well as skipped `ExUnit` tests (e.g., `skip: true` in a `test "..." do` block). This proactive check prevents accidental commits of debugging code that could impact production, confuse reviewers, or lead to unexpected behavior. For example, you can quickly search for `IO.inspect` within your `lib/_web` controllers or LiveView modules to ensure all temporary debugging output is removed. ## Running Phoenix tests and formatting with Atlas Ensuring your Phoenix codebase adheres to quality standards involves running `mix test (ExUnit)` and `mix format` before any commit. Atlas, by 2026, integrates these essential Phoenix toolchain commands, allowing you to execute them directly and verify your changes in 1 single workflow. After reviewing the diff and cleaning up debugging leftovers, the next critical step for any Phoenix developer is to validate changes with `mix test (ExUnit)`. Atlas can execute `bash` commands, allowing you to run `mix test` across your application, including new `LiveViewTest` cases or Ecto changeset validations. Every Atlas tool call, including `bash` commands, is permission-gated, so you approve `mix test` before it runs, ensuring controlled execution. Similarly, maintaining consistent code style is vital. Atlas can run `mix format` to automatically apply formatting rules defined in your Phoenix project, ensuring consistency across your `lib/_web` directory, Ecto schemas, and context modules, preventing formatting-related feedback during code review. ## Reverting unwanted Phoenix changes with Atlas's session revert If your self-review uncovers a change that should not be committed, Atlas offers a robust session revert mechanism. This feature, available in 2026, restores your Phoenix codebase from a snapshot, ensuring unwanted edits are undone safely and efficiently in less than 1 second. During self-review, you might identify changes to Phoenix contexts, LiveView sockets, or Ecto changesets that were accidental or incorrect. Atlas's session revert flow is backed by snapshots, allowing you to roll back unwanted changes rather than hand-reverting them. This feature restores your files to a previous state, effectively undoing edits made during the current session. Crucially, Atlas's revert mechanism refuses to run on a busy session, preventing a half-written turn from being rolled back mid-flight and ensuring data integrity. This provides a safe and reliable way to manage your working tree in a Phoenix project, especially when dealing with complex refactors or experimental code. ## Steps 1. Produce and read the working diff for your Phoenix project using Atlas's VCS layer to see all uncommitted changes.: atlas bash git diff 2. Review each changed Phoenix file in full, checking the modifications against its surroundings in files like `lib/my_app_web/controllers/my_controller.ex` or Ecto schemas.: atlas read --diff 3. Grep for debugging leftovers in your Phoenix code, such as `IO.inspect` calls, commented-out blocks, or `skip: true` in `ExUnit` tests.: atlas grep "IO.inspect" 4. Run `mix test (ExUnit)` through Atlas to verify all changes, including new `LiveViewTest` cases, ensuring your Phoenix application functions correctly.: atlas bash mix test 5. Apply `mix format` via Atlas to ensure code style consistency across your Phoenix codebase, including LiveView modules and contexts.: atlas bash mix format 6. If your self-review reveals an unwanted change, use Atlas's session revert to restore your Phoenix files from a snapshot.: atlas revert session 7. Stage your approved changes and create a commit for your Phoenix project using Atlas.: atlas commit --all -m "feat: my Phoenix feature" ## FAQ ### How does Atlas help me review my Phoenix diffs? Atlas's VCS layer surfaces the raw working diff for your Phoenix project, allowing you to read all uncommitted changes end-to-end and check them against their surroundings in files like `lib/_web/router.ex` or Ecto schemas. ### Can Atlas run mix test for my Phoenix application? Yes, Atlas can execute `bash` commands, including `mix test (ExUnit)`. Every tool call is permission-gated, so you approve the test run before it proceeds, ensuring your Phoenix tests are verified safely. ### How do I ensure my Phoenix code is formatted correctly with Atlas? Atlas can run `mix format` via its `bash` tool. This applies your project's formatting rules, ensuring consistency across your Phoenix LiveView modules, contexts, and Ecto changesets before committing. ### What if I make a mistake and need to undo changes in Phoenix using Atlas? Atlas provides a session revert feature, backed by snapshots. If you identify an unwanted change in your Phoenix codebase during self-review, you can use `atlas revert session` to restore files to a previous state, preventing a busy session from being rolled back. ### Does Atlas understand Phoenix-specific code structures? Yes, Atlas indexes code by AST declarations using tree-sitter, allowing it to understand Phoenix contexts, LiveView sockets, Ecto schemas with their changesets, and router pipelines, providing relevant insights for your Elixir application. ### Can Atlas help me find debugging code like IO.inspect in my Phoenix project? Absolutely. Atlas's `grep` tool can search your working diff for common debugging patterns such as `IO.inspect`, `Logger.debug`, commented-out code blocks, or `skip: true` in `ExUnit` tests, helping you clean up your Phoenix codebase. ### How does Atlas ensure safety when making changes to my Phoenix project? Atlas drafts a plan in a read-only agent and asks for approval before switching to a build agent. Every tool call is permission-gated, and it computes a unified diff for every file edit, surfacing it for approval before writing to your Phoenix files. --- Canonical HTML: https://runatlas.sh/resources/stacks/self-review-a-working-diff-before-committing-in-phoenix Source of truth: aeo_pages row `/resources/stacks/self-review-a-working-diff-before-committing-in-phoenix` (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.