A useful review ends with a clear decision about the exact change you will commit. That requires more than reading the agent’s summary or seeing a passing test command. You need to establish what changed, whether it meets the request, and whether the staged snapshot contains everything it needs.

This workflow applies to code written with Claude Code, Codex, Cursor, or another agent. On a Mac, you can perform it with Git, your editor, and the project’s existing checks. Start with scope, then inspect behavior, then verify the commit contents.

Stop edits and establish the review boundary

Ask the agent to pause before you review. Record the intended outcome and the work that is outside scope. If you cannot describe the change in a sentence, divide the review into coherent pieces before reading lines.

Run git status --short and separate pre-existing work from the current task. Note staged, unstaged, and untracked files. A file can have both staged and unstaged changes, so seeing its name once does not mean you have seen everything that might matter.

Ask for a concise handoff: changed behavior, design decisions, checks actually run, and known limitations. Verify those statements against the repository rather than treating the handoff as approval evidence by itself.

Inventory the whole change before opening hunks

Read the changed-file list first. Compare it with the requested behavior and identify the likely entry points, implementation, configuration, dependencies, and tests. A small feature that also rewrites unrelated code needs an explanation before detailed review begins.

Use git diff --name-status for unstaged tracked changes and git diff --cached --name-status for staged changes. Check untracked files through status and open them separately. Ordinary diffs omit them, even when they contain the entire implementation of a new feature.

Review additions, deletions, and renames deliberately. New files can be required dependencies; deleted files can remove behavior; renamed files can include substantive edits. Look for unintended generated output, local settings, credentials, or unrelated work before selecting anything for the commit.

Choose the comparison that answers your question

Different comparisons reveal different parts of the work. Keep the distinction visible while reviewing:

  • git diff compares unstaged tracked changes with the index.
  • git diff --cached compares the staged snapshot with the current commit.
  • git show HEAD shows the latest commit, useful when the agent has already committed a step.
  • git diff main...HEAD compares the current commit with its common ancestor with main, showing committed changes since that shared point.
  • git diff main HEAD compares the two committed endpoints directly, so changes on main can also affect the result.

Use the actual target branch in place of main when appropriate, and make sure the reference is current enough for your review. Branch comparisons omit uncommitted work. If the task spans committed and local changes, inspect both before deciding that the review is complete.

Inspect contracts and callers, then the details

Start with changes that alter behavior across a boundary: input validation, return values, errors, saved data, or shared state. For each one, describe the previous behavior and the intended new behavior. Check whether the requirement supports that difference.

Trace outside the changed lines

Jump to definitions for unfamiliar calls and find references to changed functions or types. A diff can be internally consistent while an unchanged caller still expects an older contract. Follow data through the caller, the changed code, and the resulting side effect.

Try concrete edge cases that fit the task: missing input, repeated actions, cancellation, or failure after a partial update. Inspect ordering as well as values. A guard added after a write cannot prevent that write.

For each concern, record the trigger, the observed code behavior, and the consequence. This makes a repair request specific enough to verify. Review the repair as a new change, including any callers or tests it affects.

Check what the tests actually prove

Read modified tests before accepting their results. Ask whether the assertions cover the requirement and would detect its absence. Inspect removed assertions and changed expectations carefully, particularly when they make an existing failure disappear.

Run the narrowest relevant checks using the project’s documented commands. Expand to a build, static analysis, or broader tests when shared behavior or configuration changed. Record the command and result, including checks that could not run. Separate environment failures from evidence of a code defect.

Remember that tests normally run against the working tree. If you later stage only part of that tree, the tested files may differ from the proposed commit. Either keep the reviewed, tested change together or verify the proposed subset separately before committing. An essential new file left untracked can cause the same mismatch.

An optional Mac workspace for diff review

Yenpo is a native Mac app that opens local Git repositories for reading and reviewing changes. It provides line diffs by commit, branch comparisons against main from the common ancestor or directly, and local uncommitted changes, including untracked files. Definition jumps and reference searches use local language servers, which are not bundled with the app. It also provides full-text search.

It has no integration with Claude Code, Codex, Cursor, or GitHub. AI Reader is optional and uses your own AI provider. You can see the files it reads and the searches it performs, and follow clickable file-and-line references. AI Reader is read-only by default. Allow Edits applies only to the next message you send to AI Reader; it then returns to read-only mode. If you permit a repair, inspect the resulting changes before accepting them.

No Yenpo account and no telemetry. It only connects to your own AI provider, an optional daily update check, and downloads you start yourself.

It is Freeware and supports macOS 14+, Apple silicon, and Intel.

Verify the exact snapshot you will commit

Stage the reviewed changes deliberately, then read git diff --cached in full. Run git diff --cached --check to catch whitespace errors and conflict markers; it does not establish behavioral correctness. Check status again for required files still untracked or unstaged.

Confirm that the staged snapshot includes its dependencies and tests, excludes unrelated changes, and matches what you verified. If the agent edited anything after that verification, review the new material and rerun affected checks. Commit when you can explain what the snapshot changes, why it is correct, and what remains unverified.