Review and commit changes

Review the files and the test output together before saving a change in Git. This guide uses the quantity bug from the quickstart, where the fix changes checkout.js and adds a regression test in checkout.test.js.

​

Review the changes

Session changes lists the changed files and their diffs. In the checkout example, the review should cover both the quantity calculation and a regression test with more than one unit. Check the command result in the timeline as well: a test in the diff shows what was added; the command output shows whether it ran successfully. If the regression test is missing, add a comment to the relevant diff line and choose Add N comments to include it in your next message. In a local session, the agent receives the file, line, and quoted snippet with your feedback, so you can ask for a specific revision. Have it add the test and run the checks, then review the updated diff.

​

Review a fix in context

For a bug fix, review three pieces of evidence together: For example, a test that still uses a quantity of one would not catch the checkout bug. Ask for a case with three units and check that the expected total is 36. If the timeline shows a missing dependency instead of test results, the fix has not been verified yet.

​

Request a revision

Leave feedback on the affected line, then send it with the review comments:

This test only covers one item. Add a case with quantity three, confirm it fails with the old calculation, and run the suite after the fix. Keep the change limited to checkout.js and checkout.test.js.

Wait for the revised run to finish and reopen the diff. Review the current file contents and the new test result, since an earlier passing run does not cover edits made afterward.

​

Commit and push

Once the running task has finished and you are satisfied with the changes:

1. Choose Commit changes beside the composer.
2. Select the files and review their diffs.
3. Review or edit the generated commit message.
4. Choose Commit to save locally, or Commit and push to push to the same branch on origin.

The commit dialog selects whole files. Staged changes commits the version in the Git index and leaves later unstaged edits in your working tree. Working tree changes commits the file’s current contents, including both staged and unstaged edits. If you staged a fix and then edited the file again, these choices produce different commits; check the selected diff before confirming. If a push fails, the local commit remains available and the dialog offers Retry push. You can retry without creating another commit.

​

Choose the file version

Suppose you staged the quantity fix, then added temporary debugging output to the same file. Staged changes commits the staged fix. Working tree changes includes the later debugging edit as well. The dialog selects whole files and versions, so prepare partial staging in Git first if you only want particular changes from a file. If a file changes while the dialog is open, choose Refresh changes and inspect the selection again. Resolve merge conflicts and any unfinished Git operation before committing. Confirm the branch before Commit and push; the push sends the selected commit to that branch on origin.

​

Create a pull request

When Create PR is available, use its arrow to choose a regular PR, a draft PR, or Manually create PR, then click the main button. Choosing the menu item only selects the mode. Manual creation pushes the branch and opens GitHub’s comparison form for you to complete. After creation, the session shows the PR number and status; its menu can expose CI checks and review comments when available. Continue with Branches, worktrees, and remote environments.