# Review a pull request in Phoenix with Atlas in 2026 > Atlas helps Phoenix developers review pull requests by fetching the full context of changed files, checking Ecto changesets, and running `mix test (ExUnit)` to catch subtle bugs. Atlas empowers Phoenix developers in 2026 to review pull requests comprehensively, moving beyond line-by-line diffs to understand the full impact of changes on contexts, LiveView sockets, and Ecto changesets. It leverages the Phoenix toolchain, including `mix test (ExUnit)` for testing, `Hex (mix deps.get)` for dependencies, and `mix format` for code style, ensuring a thorough and idiomatic review process. ## Key takeaways - Atlas provides full file context for Phoenix reviews, not just diff hunks. - It uses `lsp` to verify Phoenix function signature changes across the entire codebase. - Atlas runs `mix test (ExUnit)` with permission prompts for robust validation. - It leverages `grep` to find missed updates in Phoenix configuration and code. - Every Atlas action in Phoenix is permission-gated and requires explicit approval. - Atlas helps maintain `Ecto.Changeset` and `LiveView` integrity during reviews. ## How Atlas fetches a Phoenix pull request for review Atlas streamlines the initial step of reviewing a Phoenix pull request by directly interacting with your Git repository in 2026. It uses its VCS layer to fetch the specific branch and generate a raw patch, ensuring you have the exact changes from the pull request ready for analysis within seconds. When you initiate a pull request review, Atlas first uses its `bash` tool to interact with Git, fetching the target branch and producing a raw diff. This is crucial for Phoenix projects, where changes might span across `lib/_web/router.ex` for new routes, `lib//accounts/user.ex` for schema updates, or `priv/repo/migrations/` for database changes. Atlas's VCS layer exposes `status`, `diff`, `diffRaw`, and `commits` operations, allowing it to precisely identify all modified files and their changes. This foundational step ensures that the subsequent analysis is based on the most accurate and up-to-date version of the code, mirroring how a human developer would start by pulling the branch and inspecting the `git diff`. ## Reading full Phoenix files for complete context To catch bugs a line-by-line diff might miss in a Phoenix application, Atlas goes beyond mere hunks by reading entire changed files. This approach, available in 2026, ensures that surrounding context, such as module attributes, `use` statements, or related function definitions outside the immediate diff, is fully visible and considered during the review. A common pitfall in code review is focusing solely on the diff hunks, which can obscure critical context. For Phoenix, where `LiveView` modules, `contexts`, and `Ecto` schemas often have interconnected logic, understanding the full file is paramount. Atlas addresses this by employing its `read` tool to pull the complete content of every changed file, not just the modified lines. For instance, if a change modifies a function within `lib//accounts/account.ex`, Atlas reads the entire `account.ex` file. This allows it to understand how a modified `Ecto.Changeset` function interacts with other functions in the same module or how a `LiveView` `handle_event` callback relates to the `mount` function, providing a holistic view that a fragmented diff cannot. ## Verifying Phoenix function signature changes with LSP Atlas proactively prevents runtime errors in Phoenix applications by using its `lsp` tool to `findReferences` for every changed function signature. This critical step, performed in 2026, identifies any callers that the diff might not show, ensuring that updates to context functions or LiveView callbacks don't inadvertently break existing code across your project. In Phoenix, modifying a function signature in a context module like `lib//accounts.ex` or a `LiveView` module can have ripple effects across the application. A standard `git diff` won't show where these functions are called. Atlas mitigates this risk by using its `lsp` tool's `findReferences` operation. For every function signature identified as changed, Atlas queries the Language Server Protocol server to locate all call sites. This means if you refactor `Accounts.create_user/2` to `Accounts.create_user/3`, Atlas will flag every file that still calls the old arity, even if those files weren't part of the original pull request diff. This capability is vital for maintaining the integrity of complex Phoenix applications, especially when dealing with `router` pipelines or `Ecto` queries. ## Catching missed updates with `grep` in Phoenix codebases Atlas employs its `grep` tool to diligently search for patterns that should have been updated but were overlooked in a Phoenix pull request. This includes identifying stale constant names, outdated copies of code, or lingering feature flags, ensuring a more robust and consistent codebase in 2026. Beyond structural changes, a thorough review in Phoenix often requires checking for semantic consistency. For example, if a feature flag in `config/config.exs` is removed, or an old constant name in `lib//utils.ex` is deprecated, the diff might not highlight all instances where these patterns are still used. Atlas uses its `grep` tool to search the entire codebase for such patterns. This helps catch instances where a developer might have updated one file but missed a copy-pasted block in another `LiveView` component or an old reference in an `Ecto` migration. This proactive search prevents subtle bugs and ensures that refactorings are complete across the entire Phoenix application. ## Automated Phoenix test execution and reporting Atlas integrates directly with the Phoenix testing ecosystem, running `mix test (ExUnit)` behind a permission prompt to validate changes. In 2026, it reports findings as a `todowrite` list ordered by severity, providing immediate feedback on the impact of the pull request on your application's behavior and stability. No Phoenix pull request review is complete without running the tests. Atlas uses its `bash` tool to execute `mix test (ExUnit)`, the standard test runner for Phoenix applications. Before running, Atlas presents a permission prompt, adhering to its `allow`, `ask`, and `deny` rules, giving you full control. This ensures that `LiveViewTest` cases, `Ecto` schema validations, and `context` function tests are all executed. The results, including any failures or warnings, are then compiled into a `todowrite` list, ordered by severity. This allows you to quickly identify critical issues, such as a broken `Ecto.Changeset` validation or a failing `LiveView` component, and address them before merging the pull request. After successful tests, Atlas can even suggest running `mix format` to ensure code style consistency. ## Atlas's safety and approval mechanisms for Phoenix changes Atlas prioritizes safety in Phoenix development by employing a multi-stage approval process for all code modifications in 2026. It drafts a plan in a read-only agent, seeks explicit permission for tool execution, and presents a unified diff for every file edit before writing, ensuring developers retain full control. Atlas is designed with developer control at its core. When reviewing a Phoenix pull request, it first drafts a plan in a read-only plan agent, outlining its intended actions without making any changes. Every Atlas tool call, whether it's `bash` to run `mix test` or `lsp` to `findReferences`, is permission-gated against `allow`, `ask`, and `deny` rules. This means you explicitly approve each step. Furthermore, for any proposed file edit,such as suggesting a fix for an `Ecto.Changeset` or updating a `LiveView` template,Atlas computes a unified diff and surfaces it for your approval before writing. This granular control, combined with its ability to snapshot file changes as Git patches for easy rollback, provides a robust safety net for even the most complex Phoenix refactorings. ## Steps 1. Use Atlas's VCS layer to fetch the pull request branch and generate the raw diff with `atlas vcs diffRaw`. 2. Instruct Atlas to read the full content of all changed Phoenix files using the `read` tool, ensuring complete context for `LiveView` modules and `Ecto` schemas. 3. For every changed function signature in Phoenix contexts or `LiveView` components, use Atlas's `lsp` tool with `findReferences` to identify all callers across the codebase. 4. Employ Atlas's `grep` tool to search for old constant names, stale code copies, or feature flags that should have been updated in the Phoenix project. 5. Run the Phoenix test suite using Atlas's `bash` tool with `mix test (ExUnit)`, approving the execution via the permission prompt. 6. Review the `todowrite` list generated by Atlas, prioritizing issues based on severity, especially those related to `Ecto.Changeset` or `LiveView` functionality. 7. Approve any proposed code edits from Atlas, reviewing the unified diff before it writes changes to your Phoenix application. ## FAQ ### How does Atlas ensure I don't miss context outside the diff in Phoenix? Atlas uses its `read` tool to pull the full content of every changed file in your Phoenix project, not just the diff hunks. This ensures you see the complete surrounding context, such as module attributes, `use` statements, or related function definitions in `LiveView` modules or `Ecto` schemas, which a line-by-line diff might obscure. ### Can Atlas check if a Phoenix function signature change broke other parts of my app? Yes, Atlas uses its `lsp` tool's `findReferences` operation. For every changed function signature in your Phoenix contexts or `LiveView` components, it queries the Language Server Protocol server to identify all call sites across your entire codebase, even those not included in the original pull request diff. ### How does Atlas handle running `mix test` for Phoenix projects? Atlas integrates directly with the Phoenix testing ecosystem. It uses its `bash` tool to execute `mix test (ExUnit)`. Before running, Atlas presents a permission prompt, adhering to your configured `allow`, `ask`, and `deny` rules, giving you full control over test execution. ### What safety features does Atlas offer when reviewing Phoenix code? Atlas prioritizes safety by drafting plans in a read-only agent, requiring explicit permission for every tool call (like `bash` or `lsp`), and presenting a unified diff for your approval before writing any changes to your Phoenix files. It also snapshots file changes as Git patches for easy rollback. ### Will Atlas help me find old feature flags or constants in my Phoenix codebase? Absolutely. Atlas employs its `grep` tool to search your entire Phoenix codebase for specific patterns. This is highly effective for identifying stale constant names, outdated code copies, or lingering feature flags that should have been updated or removed during the pull request. ### Does Atlas understand Phoenix-specific constructs like Ecto changesets or LiveView? Yes, Atlas is designed to work with Phoenix's unique constructs. It can read your `router` pipelines, `LiveView` modules, `contexts`, and `Ecto` schemas with their `changesets`. This deep understanding allows it to provide relevant insights and checks specific to the Phoenix framework during a review. ### How does Atlas report its findings after a Phoenix PR review? After performing its analysis and running `mix test (ExUnit)`, Atlas compiles its findings into a `todowrite` list. This list is ordered by severity, allowing you to quickly identify and address the most critical issues, such as `Ecto.Changeset` validation failures or `LiveView` component errors, in your Phoenix application. --- Canonical HTML: https://runatlas.sh/resources/stacks/review-a-pull-request-in-phoenix Source of truth: aeo_pages row `/resources/stacks/review-a-pull-request-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.