Git actions and pull requests

The Git action button answers one question: what is the most useful next action for this worktree? It combines local Git state, the target branch, and GitHub pull-request or GitLab merge-request context.

The action appears in the center bottom bar for the active worktree. Compact sidebar hover cards mirror it for other worktrees. It changes as the task moves from local edits to review, merge, and cleanup.

Every Git action styleThese are the same controls shown in the homepage preview. Open any chevron to inspect valid alternatives.

feat/workspace-previews+128−24

Add instant workspace previews

feat/command-palette+84−12

Make every action keyboard-first

fix/session-restore+62−18

Restore sessions without drift

feat/review-handoff+96−8

Ship reviewed changes with confidence

feat/product-narrative+74−59

Sharpen the product narrative

Route selected actionPreview only — choose any button. This example never runs Git.

What the Git action shows

The Git action is not a fixed lifecycle. It reads the active worktree and its PR or MR, then shows the action that fits the current condition.

Current conditionGit action

No review yetA task branch contains workCreate PRCreate MR

Local work changedAn open review has new files or local commitsCommit and pushCommitPush

Review needs workConflicts, failed checks, feedback, or an unknown blockerResolveFixInvestigate

Review is waitingChecks are running or the branch is behind its targetChecksUpdate

Review can advanceA clean draft or mergeable review is readyReadyMerge

Review mergedThe local worktree can be removedDelete

With an open review, local work takes priority over review blockers. After every action, the app reads Git and forge state again.

A task can skip conditions, return to an earlier one, or hide the button when no action is available. The Create PR or MR flow can prepare, commit, and push local work before it opens the review.

What each state means

Button or state	Why it appears	What it does
Commit & push	The worktree has uncommitted changes and can push	Routes an agent to review, commit, and push the changes
Commit	The preferred action is local-only, or pushing is not available	Routes an agent to create a local commit
Push	Local commits are ahead of the upstream	Pushes directly
Create PR / Create MR	A non-default task branch has work but no open review	Routes an agent to prepare and create the review
Resolve	The branch or review has merge conflicts	Routes an agent with the conflict-resolution prompt
Fix CI	Checks or pipelines failed	Routes an agent with failure context
Investigate	The forge reports a merge blocker that needs diagnosis	Routes an agent with the blocked-merge prompt
Fix comments	Review conversations remain unresolved	Routes an agent with comment context
Fix changes	A reviewer requested changes	Routes an agent with review context
Checks	Required checks are still pending	Refreshes or waits for current forge status
Update	The review branch is behind its target	Updates the branch through the supported forge flow
Ready	A draft PR or MR has no higher-priority blocker	Marks it ready for review
Awaiting review	Required approval has not arrived	Shows the current passive review state
Squash & merge, Create a merge commit, or Rebase & merge	Checks and review requirements permit merging	Merges with the selected allowed strategy
Delete worktree	The PR or MR has merged	Runs the configured cleanup flow and removes the local task worktree

GitLab can also report a passive No changes to merge state. Closed but unmerged reviews return the worktree to the appropriate local Git action.

How the app chooses the action

The app generally evaluates state in this order:

A temporary branch must receive a durable name.
A base branch with local changes needs Commit & push or Commit, then Push if commits remain local.
A non-default task branch with work but no open review gets Create PR/MR. Its dropdown still offers commit-only choices.
An open review with uncommitted changes gets Commit & push or Commit; an open review with local-only commits gets Push.
A clean open review checks conflicts, an empty GitLab MR, failed checks, requested changes, unresolved comments, pending checks, behind-target state, and otherwise unexplained merge blockers in that priority order.
A clean draft can become ready; a clean review that still needs approval remains Awaiting review; an eligible review can merge.
A merged review can delete its worktree.

Before a forge mutation, the button may briefly show Checking, Creating, or another loading state while it refreshes stale context. This prevents an action based on an old PR, check, or merge status.

The chevron exposes valid alternatives without discarding the recommended action.

For a dirty worktree, choose between Commit & push and local-only Commit. Choosing either from the primary commit button also remembers that preference for future dirty worktrees. Choosing it as a secondary action under another primary button is a one-time choice.

The Create PR/MR menu can also offer:

Create a draft PR or MR.
Open the manual creation flow.
Commit and push, or commit locally, before creating the review.

When a review is ready to merge, the menu lists only strategies allowed by the repository and forge: squash, merge commit, or rebase. The selected primary strategy remains on the button.

Direct actions and agent actions

Actions that need judgment use an agent: committing, creating a PR or MR, resolving conflicts, fixing CI, investigating a merge blocker, addressing comments, and addressing requested changes.

Mechanical forge or Git operations run directly: push, update branch, mark ready, merge, delete worktree, and refresh pending checks. Direct operations can still show confirmation, progress, or an error when the forge rejects them.

This distinction matters when you configure action routing. Provider and prompt settings affect agent actions; they do not turn a direct merge or push into an agent prompt.

Click, Command-click, and background dispatch

Each agent action can behave differently for a normal click and -click. Available dispatch modes are:

Reuse tab (prepare): reuse a compatible tab when possible, fill the prompt, and wait for you to submit. This is the default click behavior.
Reuse tab (submit): reuse or create a compatible tab and submit immediately.
New tab (prepare): open a new tab with the prompt ready for editing.
New tab (submit): open a new tab and submit immediately. This is the default -click behavior.
Background: dispatch without bringing an agent tab to the foreground.

Open Settings → Agents → Routing to configure fast and thorough action groups, then use advanced routing when one action needs a different click mode, provider, or model. Permission and bypass controls live separately under Execution & approvals. Settings cascade global → workspace → project.

The default groups treat short, bounded tasks such as inline commit and Create PR/MR as fast actions. Review, conflict resolution, failed CI, blocked merges, comments, and requested changes use the thorough path. You can change both groups and override individual actions.

Customize action prompts

Open Settings → Commands to edit the prompt templates for:

Inline commit, Commit & push, and Commit.
Create PR/MR.
Resolve conflicts and Review.
Fix CI and investigate a blocked merge.
Fix review comments and requested changes.

Use the workspace or project scope for repository-specific requirements, such as a pull-request template, label, verification command, or commit convention. Keep prompts focused on policy; the app supplies live worktree and forge context separately.

See Custom commands and action routing for scoped prompt inheritance, Fast and Thorough model selection, per-action provider and model pins, and user-defined commands.

Keyboard workflow

Default shortcuts include:

Shortcut	Action
	Run the visible Git action
	Run it with the alternate/new-tab behavior
	Create a PR or MR
	View the associated PR or MR

Change shortcuts in Settings → Keyboard Shortcuts. A hidden or unavailable action does not run merely because its shortcut was pressed.

Inspect the state behind the action

The adaptive button interprets repository and forge state; it does not evaluate the implementation. Open Review changes for the worktree diff, app-managed threads, AI findings, agent follow-up, and current checks.

For live worktree values, an app-launched terminal can use:

sc worktree status --json
sc worktree diff-summary --json
sc worktree review-checklist --json

These values explain why the button shows a commit, push, review, repair, merge, or cleanup action. Refreshing them can change the visible action when cached forge context was stale.

See Supported forges for gh and glab requirements, and Worktree cleanup for deletion safeguards and hooks.