smart-rebase

Smart Rebase — Partial Rebase for Squash-Merge Repos

Analyze branch history → identify squash-merged commits → generate precise git rebase --onto command.

When NOT to Use

• Simple git rebase without squash-merge complexity — the developer runs it; Claude never executes rebase, here or anywhere else (§ Permissions). "Use git directly" is an instruction to the human, and this list is read by the dispatcher before § Permissions loads, so it says so here
• Merge conflict resolution (use /merge-prep)
• Branch management or switching — the developer runs the git command
• Cherry-picking specific commits (use git cherry-pick)

Core Problem

In squash-merge repositories, when a feature branch is based on another branch that was already squash-merged:

main:    A ─── S (squash merge of B1+B2+B3) ─── ...
              ↑
feature: A ─ B1 ─ B2 ─ B3 ─ F1 ─ F2 ─ F3
              ↑ drop (in S)   ↑ keep (unique)

Need: git rebase --onto main B3 feature to keep only F1-F3.

Permissions

Claude must not execute git rebase — there is no authorization that lifts this. rebase is a destructive operation under Anchor Register #4 (@rules/discretion.md), whose enumerated approval workflows are a closed set: /push-ci (push), /smart-commit --execute (add + commit) and /epic-merge (rebase --onto, force-with-lease, squash-merge). This skill is not on that list, so user approval here cannot create the exception — adding a workflow to the list is itself an Anchor-level change. This skill outputs the rebase command; the developer runs it.

Note on allowed-tools: Bash(git:*) is granted because Steps 1–3 read history (git log, git rev-parse, git branch --show-current), and Bash(bash:*) to run the analysis script — the latter cannot be narrowed to specific script paths until #9354 is resolved. A tool grant is not an authorization: what may be executed is decided by the rule above, not by what the permission string happens to permit.