Review and organise commits
On this page
Inspect agent changes, request revisions and turn the result into meaningful commits.
Before you start
Wait until the agents changing the relevant files have reached a review point. Select an agent terminal in the intended repository and enter the review instruction there.
Review the diff in the terminal
- Ask the agent to identify its working directory and show
git status --short,git diffandgit diff --cached. - Have it explain the changes and group related behaviour, tests and documentation into a proposed commit plan.
- Inspect the file and hunk membership of every group. If two features share a file, ask how it will stage their separate hunks.
- Request any corrections directly in the terminal, then inspect the updated diff and test output.
- Approve the concrete grouping before asking the agent to create the commits.
Send feedback to an agent
Enter a single review prompt directly into the agent terminal, with file paths, relevant lines or code excerpts and the requested changes.
In src/settings.ts, handle an empty response before reading its fields. In the associated test file, add an empty-response case. Make these revisions, run the relevant tests and leave the revised diff ready for review.
Inspect the new diff afterwards. A separate reviewer can check the actual changes without editing them. Markdown documents also have a Review notes panel in Peruse.
Group changes into feature commits
Give the agent a bounded instruction such as:
Split these changes into coherent commits. Keep the saved-search fix with its regression tests, and put the independent documentation update in a separate commit. Show the proposed files and hunks first. After I approve the plan, stage only the intended changes for each group, inspect the staged diff and create each commit. Report
git logandgit showfor every resulting commit, rerun the relevant checks and verify that no reviewed change was lost. Do not push.
These are ordinary Git operations performed by the agent through its terminal tools. For each approved group, inspect the staged diff before committing. Afterwards, check each commit's exact contents and the remaining working tree. Publishing the branch is a separate instruction.
Check the result
Review the final diff and test results before committing. Afterwards, check that each commit tells a coherent story and contains the intended files. Compare the resulting file contents with the reviewed starting changes, including any work intentionally left uncommitted.
For merge conflicts, ask the agent to explain the conflicting changes, inspect its proposed resolution and verify the resolved result before continuing Git's operation.