Claude Code has finished a task. Its summary says the feature works, but you still need to understand which behavior changed before asking it to continue. Open the same local project in Yenpo, read the changes, and follow the parts the summary leaves out.

You need a local Git repository and Yenpo on macOS. Browsing code and diffs needs no model connection. Connect a model only if you want the AI Reader to help with the review.

1. Work out what this turn changed

Before starting a turn, run these read-only commands in the directory Claude Code will edit:

git rev-parse --show-toplevel
git rev-parse HEAD
git status --short

Keep the starting commit ID and note any existing changed or untracked files. A clean starting tree makes it much easier to attribute the next diff. If work is already in progress, preserve it and record its contents with your usual review tools; a file list alone won’t separate two edits to the same file.

When Claude Code finishes, let it stop writing and run the commands again. Check the directory as well as the branch: if you used a separate worktree, open that directory in Yenpo.

State after the turn What to review
No new commits; clean tree before the turn Local changes against the starting commit
New commits The starting commit → the final commit, then any remaining local changes
Changes already existed before the turn Compare with the recorded starting contents before attributing changes to Claude Code

Yenpo reads Git state. It doesn’t know which Claude Code turn made which change. If you didn’t record a dirty starting state, describe the scope as “current changes” rather than “only this turn.”

2. Read the local changes in Yenpo

Open the project folder and click “Changes,” the plus/minus button in the sidebar. The “Local Changes” header summarizes the current changes against HEAD. Select a changed file to read its inline diff.

Start with the file that implements the requested behavior, then its callers and tests. Include new files in the review; an added test or configuration file may explain more than a large generated diff. Yenpo’s current-change summary can include unsaved editor text. Save intended edits before comparing with command-line Git or running tests.

If Claude Code made commits, open “Compare Versions…” and use “Commit” to inspect each relevant commit against its first parent. Then return to “Changes” for anything still uncommitted. To check the net diff for the whole turn, replace the placeholders below with your recorded starting and final IDs and run this read-only command. Yenpo’s “Compare” mode selects branches; see revision selection.

git diff START_COMMIT END_COMMIT --

3. Follow one behavior beyond the changed lines

Suppose you asked Claude Code to keep a search result from appearing after the user changes the query. Read the changed function, then find its caller and the place that updates the displayed result.

Work through three questions:

  1. What starts the operation, and which value identifies the current query?
  2. What happens if the first request finishes after the second?
  3. Does the test actually control that order, or merely call the function twice?

Use file search and, where a language server is available, definition and reference navigation. Check that the tabs you follow show the same version as the diff. A current file may differ from a committed comparison.

4. Ask the AI Reader a bounded question

After connecting your model, use “Ask AI to review all changes” in the local-changes header. It prepares a draft for the current workspace changes. For a committed comparison, use “Ask AI to review this comparison” instead and keep the comparison attachment.

Adjust the draft before sending:

Explain the change to search-result handling. Trace the request from its caller to the UI update. Check the case where an older request finishes last. Cite the relevant code for each claim, separate pre-existing behavior from new behavior, and say which tests actually cover this ordering. Review only; do not edit files.

Keep editing permission off. Click the answer’s references to inspect the cited lines, and open the full file when the caller or surrounding condition matters. This citation-checking workflow gives a detailed example.

5. Give Claude Code a follow-up it can act on

A useful follow-up names the trigger and expected result:

When query A starts before query B but finishes afterwards, A can still replace B’s result. Check the result-assignment path and add a test that completes B before A. Keep the existing behavior for a single successful request.

Use this only after confirming the problem in your code. Replace a broad request to “make it safer” with the behavior you actually need.

After the fix, reread the affected diff, run the relevant project test, and note the command you ran and its result.

6. Finish with a short review note

Keep the starting and final commit IDs, the files you reviewed, one sentence about the behavior change, and any unresolved question. Note whether the review included uncommitted files and which checks you ran. That gives the next turn a clear starting point.

If the work is now on a branch, continue with reviewing a branch against main; the Git steps also apply to branches created with Claude Code.