with one click
rebase-origin-main
// Use when rebasing the current branch onto origin/main, including resolving merge conflicts along the way
// Use when rebasing the current branch onto origin/main, including resolving merge conflicts along the way
Generate Stage chapters for the current local git branch and open them in a browser for review.
Use when building or reviewing UI components, pages, or layouts to ensure premium, intentional design that never looks vibe coded
Use when CI is failing on a branch and you need to diagnose failures from GitHub, fix them locally with iterative verification, and re-push clean commits.
Use when a pull request has unresolved review comments that need to be addressed, or when asked to fix PR feedback
Use when a PR is open and the user wants to autonomously monitor and fix PR review comments, CI failures, and rebase conflicts on a recurring loop, or when asked to babysit/iterate on a PR
Use when creating a Linear issue from the current coding context, or when the user invokes /linear-issue. Infers team, priority, status, and relationships from conversation context, working directory, and git branch.
| name | rebase-origin-main |
| description | Use when rebasing the current branch onto origin/main, including resolving merge conflicts along the way |
| metadata | {"internal":true} |
Fetches the latest origin/main, rebases the current branch onto it, and resolves every conflict that arises — one commit at a time — until the rebase completes cleanly.
During a rebase, git's labels are inverted from what you expect:
| Label | Means |
|---|---|
HEAD / ours (top of conflict) | origin/main — the base being rebased onto |
theirs (bottom of conflict) | Your commit being replayed |
Always resolve conflicts to preserve the intent of your commit while incorporating origin/main's context.
git fetch origin
git rebase origin/main
If the output says Successfully rebased — done. No conflicts.
git status
Look for lines with both modified, added by us, deleted by them, etc.
For each conflicted file:
<<<<<<<, =======, >>>>>>>)======= (HEAD) = origin/main's version======= = your commit's changegrep -En "<<<<<<<|=======|>>>>>>>" <file>git add <file>If a conflict is ambiguous — where preserving both sides isn't clear — stop and ask the user before resolving.
After all conflicts in the current commit are staged:
git rebase --continue
Git will either move to the next commit (go back to step 2) or report success.
| Situation | Command |
|---|---|
| A commit becomes empty after resolution | git rebase --skip |
| You need to abort entirely | git rebase --abort |
| Binary file conflict | Show the user and ask which version to keep |
After a clean rebase, confirm the branch looks correct:
git log --oneline origin/main..HEAD
After a successful rebase, run the full CI suite locally to catch any breakage introduced by the rebase:
pnpm lint && pnpm typecheck && pnpm test && pnpm build
If anything fails, follow the fixing-ci skill workflow starting from Step 2 (Fix Loop) through Step 3 (Verify All): diagnose each failure, fix the root cause, verify, and commit atomically. Do not proceed to push until all checks pass locally — the push is handled by Step 8 below with --force-with-lease.
Force-push with lease (safe force-push — aborts if someone else pushed since your last fetch):
git push --force-with-lease
| Mistake | Fix |
|---|---|
| Leaving conflict markers in file | Grep for <<<<<<< before staging |
| Staging before fully reading the file | Read the full file first |
Assuming ours = your branch | It's inverted in rebase — ours is origin/main |
| Continuing without reviewing log | Always run git log --oneline origin/main..HEAD after |