Skip to main content
After an AI completes work, you need to review the changes before committing. This guide walks through the full review and commit workflow.

​
Prerequisites

  • Git installed and configured
GitHub CLI (gh) is optional. It’s only needed for:
  • Creating pull requests
  • Viewing PR status badges on branches
  • Browsing your GitHub repositories when cloning
All core features (reviewing, staging, committing, pushing) work without it.

​
Viewing Changes

​
Open the source control panel

1

Select a worktree

Click on the worktree you want to review.
2

View the source control panel

The source control panel shows on the side. It lists all files with changes.
You can also open the diff viewer by clicking the eye icon in the source control header.
Prefer reviewing in your own editor? Click the “Open in Editor” button in the top toolbar to open the worktree in VS Code, Cursor, or your configured editor. This is useful for manual changes or reviewing diffs in a familiar environment.

​
Understanding file status

Files are marked with their status:

​
View a file diff

Click any file in the source control panel to see its diff:
  • Red lines: Removed content
  • Green lines: Added content
  • Gray lines: Unchanged context

​
Reviewing Changes

​
What to look for

When reviewing AI-generated code, check for:
  • Does the code do what was asked?
  • Are there logic errors?
  • Are edge cases handled?
  • Any hardcoded credentials?
  • Input validation present?
  • SQL injection possible?
  • XSS vulnerabilities?
  • Does it match your code style?
  • Is it readable?
  • Are names descriptive?
  • Are tests included?
  • Is error handling present?
  • Documentation updated?

​
Adding inline comments

1

Click on a line

Click the line number where you want to comment. For multi-line comments, click a line number, hold, and drag to select multiple lines.
2

Write your comment

Describe what needs to change.
3

Copy to AI

Click the copy button in the header to automatically copy all comments and paste them into your AI chat. Alternatively, click the export button and feed that to the AI.
Instead of fixing issues yourself, send them back to the AI. Describe what’s wrong and let the AI iterate.

​
Staging Changes

Once you’re satisfied with the changes, stage them for commit.

​
Stage all changes

Click Stage All to stage everything at once.

​
Stage individual files

1

Find the file

Locate the file in the source control panel.
2

Stage it

Click the + icon next to the file.

​
Unstage files

If you staged something by mistake:
1

Find the staged file

Look in the “Staged Changes” section.
2

Unstage it

Click the - icon.

​
Discarding Changes

If you don’t want to keep the changes:

​
Discard all changes

1

Click Discard All

In the source control panel, click Discard All.
2

Confirm

Confirm you want to discard. This cannot be undone.

​
Discard specific files

1

Find the file

Locate the file in the source control panel.
2

Discard it

Click the discard icon next to the file.
Discarding changes permanently deletes uncommitted work. Make sure you don’t need it before discarding.

​
Committing Changes

1

Stage your changes

Make sure all files you want to commit are staged.
2

Write a commit message

Enter a clear, descriptive commit message:
3

Click Commit

Click the Commit button to create the commit.
You can also ask your AI to commit the changes for you. It will review the changes and create an appropriate commit message.

​
Pushing Changes

After committing, push to the remote:
1

Click Push

Click the arrow up icon in the toolbar.

​
Creating a Pull Request

1

Click Create PR

Click the Create PR icon in the toolbar (beside the push button).
2

Fill in PR details

Termpad opens your browser to the PR creation page. Fill in:
  • Title
  • Description
  • Reviewers
  • Labels
Creating PRs requires the GitHub CLI (gh) to be installed and authenticated.

​
Tips

​
Review frequently

Don’t let changes pile up. Review after each significant AI task:
  1. AI completes a piece of work
  2. Review immediately
  3. Commit if good, or send back for fixes
  4. Continue

​
Use atomic commits

Make each commit a logical unit of work:
  • One feature per commit
  • One bug fix per commit
  • Don’t mix unrelated changes