This guide was prepared with AI writing assistance. The Git commands were checked against the official Git documentation, and the Orke description against BOMTOBE’s Git window guide. BOMTOBE makes Orke. \nAn AI coding agent says a task is complete. A review of AI-generated code should begin with the repository state, not an agent summary. Before you accept the result, you need to know what it changed, whether those changes belong to the request, and what still needs a check. A confident summary cannot answer those questions on its own. The diff and the repository status give you a concrete starting point.

This walkthrough uses read-only Git inspection commands. They help you review a working tree; they do not prove that the change is correct, and they do not replace project-specific tests or review.

Section — Start with the repository state

Before focusing on the patch, establish what is already in progress. A working tree may contain edits from you, another tool, or a previous agent run. If you cannot tell which changes belong to the task, do not assume that every changed line came from the latest agent action.

Run:

git status --short --untracked-files=all

This compact view reports changed paths and includes individual untracked files. Read the status codes as well as the names: a path can have a staged change and a separate unstaged change. If the output includes files you expected to remain untouched, pause and identify their origin before reviewing or discarding anything.

Do not use cleanup or reset commands to make the status look tidy. Commands such as git clean, git reset --hard, or checking out a file can destroy work. They are not review commands.

Section — Make a path inventory before reading line by line

List the changed paths and group them by purpose. A small feature might reasonably touch an implementation file, a focused test, and a short documentation page. A request to adjust one label may not explain new dependencies, build outputs, lockfile churn, or edits across unrelated modules.

For tracked, unstaged changes, these commands give a summary and a path list:

git diff --stat

git diff --name-only

For staged changes, use the corresponding cached forms:

git diff --cached --stat

git diff --cached --name-only

Treat the path list as a question, not a verdict. A generated file or dependency lockfile can be expected in one task and surprising in another. Compare each path with the task’s stated scope and ask what evidence explains it.

Section — Read staged and unstaged changes separately

Git distinguishes changes staged for the next commit from changes that are still unstaged. The plain git diff shows unstaged changes. git diff --cached shows staged changes. Inspect both when both appear in git status:

git diff --

git diff --cached

A single combined view can hide how a file’s current state relates to what is staged. Review each version deliberately. If you need to compare the whole tracked working tree to the current commit, git diff HEAD can be useful, but remember that ordinary diffs do not show untracked files.

For a large patch, narrow the view to one path at a time:

git diff -- path/to/file

git diff --cached -- path/to/file

The official Git documentation describes git diff as comparing working trees, the index, and commits in different combinations. Choose the comparison that answers your question instead of assuming every form shows the same changes.

Section — Inspect untracked files directly

A new file that has not been added to the index does not appear in the ordinary git diff output. That is why the initial status command includes untracked paths. Open each new file and read it. Check whether it belongs to the task, whether it contains generated output, and whether it introduces secrets or local-only configuration.

If you expected a test or documentation update but there is no corresponding path, check whether the agent omitted it. If a new file exists outside the requested area, ask why before accepting it. Do not stage files just to make them appear in a diff; staging changes the repository state.

Section — Look beyond the added and deleted lines

Line-by-line review is useful, but context matters. For each meaningful change, ask:

• Does the code path match the requested behavior, including error and edge cases?

• Did the patch change a public interface, configuration default, permission, or dependency?

• Were tests weakened, skipped, or removed instead of fixing the behavior?

• Are credentials, tokens, private data, or machine-specific paths present?

• Do generated files or lockfile changes have an explanation?

• Does the surrounding code still call the changed function with the expected values?

A patch can be syntactically tidy and still violate the task boundary. When a change is hard to explain, inspect the callers, tests, and relevant documentation before deciding what to do.

Section — Check whitespace and run the relevant verification

Git can flag certain whitespace errors in a diff:

git diff --check

git diff --cached --check

These checks do not establish that code works. Read the project’s documented test command and run the smallest relevant verification when it is safe and practical. Record the exact command and result. If you cannot run it, say why; do not turn an unrun check into a pass.

Also inspect what the tests actually assert. A green test suite is weaker evidence if the agent removed the meaningful assertion or changed the test to avoid the original case. Conversely, a failing test does not by itself prove the new code caused the failure; compare with a known starting state when available.

Section — A small example: a button label change

Suppose the request was “Change the save button text to ‘Save draft’.” The diff shows the label changed in one component and a focused UI test was updated. That may fit the scope. Then status also shows a new analytics dependency, an edited permissions file, and a generated bundle. Those extra paths are not automatically wrong, but the task brief does not explain them. Review them separately and ask for the reason before accepting the result.

This is a fictional example to show the review method, not a report of an Orke session or a measured coding task.

Section — Keep the conclusion tied to evidence

A useful review note can be short:

• Requested outcome:

• Changed paths:

• Staged changes:

• Unstaged changes:

• Untracked files:

• Checks run and exact results:

• Risks or unexplained changes:

• What remains unknown:

Separate observed facts from hypotheses. “The test command exited with status 1” is an observation. “The agent introduced the defect” is a conclusion that needs a comparison and code evidence.

Section — Reviewing changes in Orke

Orke’s official Git window guide says to read the changed-files list and diff after AI work, check that the scope is right, and look for secrets or generated files. The same guide describes Orke’s Git window as a place to review changed files and history. These are review aids; the person responsible for the repository still decides whether the patch matches the task and what verification is needed.

BOMTOBE develops Orke, a desktop workspace for AI agents such as Claude Code and Codex. Its terminal, web window, and Git view let a person review task output and repository changes in the same workspace. This article describes a general Git review process; it does not claim that Orke ran the example above.

Section — Official references

• Git: git-diff documentation — https://git-scm.com/docs/git-diff

• Orke: Git window — https://orke.bomtobe.com/en/docs/orke/git/