
Stack Rebase
Cascade a rebase through a stacked PR branch chain after the base merges or master moves forward.
Overview
Stack-rebase is an agent skill for the Ship phase that cascades a rebase through a PR stack after a base PR merges or the upstream base branch changes.
Install
npx skills add https://github.com/athola/claude-night-market --skill stack-rebaseWhat is this skill?
- Six TodoWrite gates from fetch through PR updates
- Cascade rebase when base PR merges onto master or upstream advances
- Handles mid-stack revisions propagating to descendant branches
- Requires Git 2.38+ for --update-refs
- Documents conflict resolution, force-push, and PR target updates
- 6 TodoWrite progress items
- Git 2.38+ required for --update-refs
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
Your stacked PRs still target an old base branch after the bottom PR merged, and manual rebases leave descendants out of sync.
Who is it for?
Solo developers using stacked diffs who need a scripted cascade after merge or upstream movement.
Skip if: Single-branch feature workflows or teams that do not use stacked PRs and stack-create prerequisites.
When should I use this skill?
When a stack needs to incorporate new base branch commits after a base PR merges, master advances, or a mid-stack PR was revised.
What do I get? / Deliverables
The full stack is rebased onto the current base, conflicts are resolved per the checklist, branches are force-pushed, and dependent PRs are updated to the correct targets.
- Rebased stack branches
- Resolved conflict states documented
- Updated remote PRs and targets
Recommended Skills
Journey fit
Stack maintenance is part of shipping stacked diffs safely through review and merge, not greenfield UI work. Review subphase fits PR-stack hygiene: retargeting, rebasing descendants, and updating PRs after upstream changes.
How it compares
Git procedure skill for stacked diffs, not a generic interactive rebase tutorial or CI deploy workflow.
Common Questions / FAQ
Who is stack-rebase for?
Builders already using sanctum-style stack-create and stack-push who maintain multi-PR stacks and need agent-guided cascade rebases after merges.
When should I use stack-rebase?
When the first stack PR merged to master, master moved ahead of your stack bases, or a mid-stack PR was revised and descendant branches must pick up the change—during Ship review and merge hygiene.
Is stack-rebase safe to install?
It instructs force-push and rebases that rewrite history; confirm repo policy and review the Security Audits panel on this page before running on shared branches.
Workflow Chain
Requires first: stack create, stack push
SKILL.md
READMESKILL.md - Stack Rebase
# Stack Rebase Cascade a rebase through an entire PR stack after a base PR merges or the upstream base branch changes. ## When to Use Run `stack-rebase` in any of these situations: - The first PR in the stack merged into `master`; the second PR now needs to target `master` directly - `master` has moved forward and stack branches need to incorporate the new commits - A mid-stack PR was revised and descendants need to pick up the change ## Prerequisites - All slice branches exist locally (`git branch --list`) - Remote is up to date (`git fetch origin`) - Working tree is clean (`git status`) - Git 2.38+ for `--update-refs` ## Required Progress Tracking Create `TodoWrite` items before starting: 1. `stack-rebase:fetch-complete` 2. `stack-rebase:trigger-identified` 3. `stack-rebase:rebase-complete` 4. `stack-rebase:conflicts-resolved` 5. `stack-rebase:force-pushed` 6. `stack-rebase:prs-updated` ## Step 1: Fetch Remote State (`fetch-complete`) ```bash git fetch origin ``` If the merged PR's branch still exists on remote, note that GitHub retains the branch after merge. The merged branch itself is no longer a valid stack base. ## Step 2: Identify the Trigger (`trigger-identified`) Determine what changed: **Case A, Base PR merged into master:** The slice that was the old "root" is now in `master`. All remaining slices need to rebase onto `master`. ```bash # Confirm the merged branch is now in master git branch -r --merged origin/master | grep "${MERGED_BRANCH}" ``` **Case B, Master moved forward:** Slices are behind `master` but the stack topology is unchanged. Rebase the root slice onto `master`; `--update-refs` carries all descendants. **Case C, Mid-stack revision:** A slice was amended. All descendant slices need to rebase onto it. ## Step 3: Run the Cascading Rebase (`rebase-complete`) ### Case A and B: Rebase root slice onto master ```bash STACK=stack/my-feature BASE=master # Check out the root slice ROOT_SLICE=$(git branch --list "${STACK}/*" \ | sed 's/^[* ]*//' | sort | head -1) git checkout "${ROOT_SLICE}" # Rebase with --update-refs rewrites all stack branches git rebase --update-refs origin/${BASE} ``` `--update-refs` scans the reflog and updates every local branch ref that points to a commit being rebased. All slice branches in the stack are rewritten in one pass. ### Case C: Rebase from a mid-stack slice ```bash # Check out the first slice BELOW the amended one CHILD_SLICE=stack/my-feature/add-api # example git checkout "${CHILD_SLICE}" git rebase --update-refs stack/my-feature/add-schema ``` ### jj Accelerator (if available) ```bash # jj rebases all descendants automatically on any change # To rebase the whole stack onto master: jj rebase -d master \ -r "ancestors(${STACK}/add-ui) & !ancestors(master)" ``` ## Step 4: Resolve Conflicts (`conflicts-resolved`) If the rebase pauses with conflicts: ```bash # See which file conflicts git status # After resolving each file: git add <resolved-file> git rebase --continue ``` Repeat until the rebase completes. If a conflict is too complex, abort and investigate: ```bash git rebase --abort ``` Then examine the diff between the conflicting commits before retrying. ## Step 5: Force-Push Updated Branches (`force-pushed`) After a successful rebase, push all slice branches. Use `--force-with-lease` to guard against remote changes made since the last fetch: ```bash for branch in $(git branch --list "${STACK}/*" \ | sed 's/^[* ]*//' | sort); do git push --force-with-lease origin "${branc