version: "1.0.1" name: rebase description: Interactive rebase onto a base branch, resolving conflicts along the way and verifying tests pass. Compares against remote when done. disable-model-invocation: true allowed-tools: Bash, Read, Glob, Grep, Agent, AskUserQuestion argument-hint: [base-branch]

Rebase

Rebase the current branch onto a base branch, resolving conflicts and verifying tests along the way.

Step 0: Check for an in-progress rebase

Before anything else, check whether a rebase is already underway:

git rev-parse --git-path rebase-merge >/dev/null 2>&1 && ls "$(git rev-parse --git-path rebase-merge)" >/dev/null 2>&1 && echo "rebase in progress" || (ls "$(git rev-parse --git-path rebase-apply)" >/dev/null 2>&1 && echo "rebase in progress")

If a rebase is already in progress, skip Steps 1–2 entirely. Assume the task is to resolve the outstanding conflicts and continue the rebase: go straight to Step 3. Treat the base branch as the one already being rebased onto — you do not need to determine or fetch it.

Otherwise, continue to Step 1.

Step 1: Determine base branch

Determine the base branch in this order:

1. Use $ARGUMENTS if the user specifies a branch
2. Use the tracked parent from git config branch.$(git branch --show-current).parent, if set and it still resolves to a commit
3. Use bin/base-branch if the script exists and is executable
4. Ask the user which branch to rebase onto

Step 2: Start the rebase

Fetch latest and begin the rebase:

git fetch origin
git rebase origin/<base-branch>

If the rebase completes with no conflicts, skip to Step 6.

Step 3: Resolve conflicts

1. Identify the conflicting files with git diff --name-only --diff-filter=U
2. Read only the conflict hunks (git diff -- <file>) with enough surrounding lines to understand both sides of the conflict. Open the whole file only when the hunk alone doesn't make the intent clear.
3. Resolve the conflict by taking both sides into account — don't blindly pick one side. Understand the intent of each change and produce a result that incorporates both correctly.
4. Stage the resolved files with git add

If a conflict is ambiguous and you can't confidently determine the correct resolution, ask the user.

Step 4: Run related tests

Run the tests related to the files that had conflicts in a sub-agent (Agent tool, general-purpose, model: haiku). Give it the test files to run and ask for only the verdict: pass, or the failing test names with their assertion messages — no log output, and no edits. If tests fail due to the conflict resolution, fix them before proceeding.

If tests fail but seem unrelated to the rebase, have the same sub-agent verify by stashing and testing:

git stash
# run tests again
git stash pop

• If tests also fail without your changes, the failures are pre-existing. Note this for the user and continue.
• If tests only fail with your changes, the rebase introduced the problem. Investigate and fix.

If you are unable to resolve test failures, let the user know what's broken and what you tried.

Step 5: Continue the rebase

git rebase --continue

If there are more conflicts, go back to Step 3. Repeat until the rebase is complete.

Step 6: Update the tracked parent

If a tracked parent is set for this branch (git config branch.$(git branch --show-current).parent), update it so later tooling stays in sync and doesn't act on a stale parent ref:

branch=$(git branch --show-current)
git config "branch.$branch.parent" "<base-branch>"
git update-ref "refs/parent/$branch" "$(git rev-parse origin/<base-branch>^{commit})"

Skip this step if no tracked parent is set.

Step 7: Check remote and compare

If there is no remote tracking branch (git rev-parse --verify @{u} fails), skip to Step 8.

Otherwise reduce each branch's net change against the base to a normalized hash and compare. <base-branch> is the branch you just rebased onto, using the freshly fetched origin/ ref for both sides:

git diff -b --unified=0 origin/<base-branch>...HEAD | git patch-id --stable | awk '{print $1}'
git diff -b --unified=0 origin/<base-branch>...@{u} | git patch-id --stable | awk '{print $1}'

patch-id --stable ignores line numbers, hunk headers, and file ordering, and -b ignores whitespace — so a rebase that adapted your change to overlapping base edits still matches.

If the hashes match (including both empty), report Clean rebase — no issues detected. and go to Step 8.

If they differ, list the affected files, then go to Step 8 — do not write patch files or analyze hunks:

git diff -b --unified=0 --name-only origin/<base-branch>...HEAD
git diff -b --unified=0 --name-only origin/<base-branch>...@{u}

Report the file names and note that local and remote differ. Differing hashes are expected whenever the branches hold different commits — commits added since the last push, or a base that moved — so do not call it a problem on the hash alone. Investigate further only if the user asks.

Step 8: Finish

End with a one-line confidence rating (Low, Medium, or High) that the conflict resolutions are correct and need no human review. When it's not High, add one short sentence on the doubt behind the rating. Then a final line: ✅ Rebase complete.