Rebase

---
name: rebase
description: >-
  Rebase current branch onto trunk (origin/master or origin/main), predict
  and resolve conflicts
disable-model-invocation: true
allowed-tools: ["Bash", "Read", "Grep", "Glob", "Edit"]
metadata:
  source: "plugins/rebase/skills/rebase/SKILL.md"
---

## Context

- Current branch: !`git branch --show-current`
- Working tree: !`git status --short`
- Remote refs available: !`git remote -v`

These run before the first turn, so each is a single command that succeeds in
any repository. Anything needing the trunk is derived in Phase 1 instead: a
repository set up with `git init` and `git remote add` has no
`refs/remotes/origin/HEAD`, and a context command that exits non-zero takes the
whole invocation with it.

## Your Task

Rebase the current branch onto the remote trunk branch. Follow these steps carefully, handling each phase before moving to the next.

### Phase 1: Detect trunk branch

Determine the trunk branch name and store it as `TRUNK`, the **bare** name — every use below prefixes it with `origin/` itself, so storing `origin/main` here would ask git for `origin/origin/main`.

Ask the remote first, because it answers before anything has been fetched:

```
git ls-remote --symref origin HEAD
```

The `ref:` line names the remote's default branch, so `TRUNK` is the part after `refs/heads/`. A repository built with `git init` plus `git remote add` has no remote-tracking refs at all until Phase 2 fetches, so local lookups cannot answer this yet.

If the remote is unreachable, fall back to `git symbolic-ref --short refs/remotes/origin/HEAD` (which prints `origin/<branch>` — take the part after the slash), and failing that to whichever of `origin/main` or `origin/master` `git rev-parse --verify` resolves.

### Phase 2: Fetch latest and analyze

1. Run `git fetch origin` to get the latest remote state.
2. Run `git diff origin/${TRUNK}...HEAD --stat` to see what files the current branch modifies.
3. Run `git diff origin/${TRUNK}...HEAD` to see the full diff of changes on this branch.
4. Run `git log --oneline origin/${TRUNK}..HEAD` to see commits that will be rebased.
5. Run `git diff origin/${TRUNK} -- $(git diff --name-only origin/${TRUNK}...HEAD)` to check if trunk has also modified any of the same files — these are potential conflict zones.

Report a brief summary of:
- How many commits will be rebased
- Which files were changed on this branch
- Which of those files were ALSO changed on trunk (potential conflicts)
- An assessment of conflict likelihood (none expected / minor / significant)

### Phase 3: Execute the rebase

Run:
```
git pull --rebase origin ${TRUNK} --autostash
```

If the rebase completes cleanly (exit code 0), skip to Phase 5.

### Phase 4: Resolve conflicts (if any)

If conflicts are detected:

1. Run `git status` to see which files have conflicts.
2. For each conflicted file:
   a. Read the file to see the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
   b. Understand both sides of the conflict by examining what the branch intended vs what trunk changed
   c. Resolve the conflict by editing the file — preserve the intent of BOTH changes when possible. When in doubt, prefer the branch's changes (our work) but integrate trunk's changes if they're structural (renames, new parameters, etc.)
   d. Run `git add <file>` to mark it resolved
3. Before continuing the rebase, run the project's quality checks. Look for CLAUDE.md or AGENTS.md in the repo root to discover the project's required checks. Common quality gates by ecosystem:

   | Gate | Example commands |
   |------|-----------------|
   | Formatter | `ruff format`, `prettier --write`, `rustfmt`, `gofmt` |
   | Linter | `ruff check --fix`, `eslint --fix`, `clippy`, `golangci-lint` |
   | Type checker | `mypy`, `tsc --noEmit`, `basedpyright` |
   | Tests | `pytest`, `jest`, `cargo test`, `go test ./...` |

   If any check fails, fix the issues and re-stage with `git add` before continuing.
4. Run `git rebase --continue` to proceed.
5. If more conflicts appear, repeat from step 1 of this phase.
6. If the rebase becomes unrecoverable, run `git rebase --abort` and report what went wrong.

### Phase 5: Verify final state

After the rebase completes successfully:

1. Run `git log --oneline -10` to confirm the rebased commit history looks correct.
2. Run `git status` to confirm a clean working tree.
3. Run the project's quality checks one final time as described in Phase 4 step 3.
4. Report the results: how many commits were rebased, whether any conflicts were resolved, and the final state of all quality checks.

Do NOT force-push. Only report the final state and let the user decide on the next step.