rebaselisted

# Rebase a branch onto a new base The point is **not** `git rebase`. Git can replay commits; it cannot tell you whether the replayed solution still makes sense. This skill is the *thinking* around a rebase: re-validate the work against a codebase that moved on, then do the mechanics carefully. Invoke for "rebase `<branch>` on `<new-base>`", "rebase my WIP onto master", or before merging a long-lived branch to check it still fits current architecture, specs, and conventions. Not for a trivial fast-forward with no semantic delta — just `git rebase`. ## Required references This file is the skeleton; each reference holds a step's full rules. Read it **at that step**. | File | Read at | Holds | |---|---|---| | `references/stash.md` | step 0, only if the tree is dirty | labeled stash, restore, conflicted-pop handling | | `references/analysis.md` | step 3 | delta checklist, classification table, gaps, derisk passes | | `references/rationalizations.md` | when tempted to skip a step | why each shortcut fails | ## Inputs - `curr` — the branch or commit being rebased (default: `HEAD`) - `old_base` — what `curr` was branched from (default: merge-base of `curr` and `new_base`) - `new_base` — the target (default: `master` / `main`; confirm with the user) If any is ambiguous, **ask**. A wrong base pick silently invalidates the whole analysis. ## Workflow 0. **Preflight.** `git status --porcelain`. Clean → step 1. Dirty → **read `references/stash.md` now**: the uncommitted work