How do I install the Squash Rebase skill?

Run npx skillmds@latest add parmaster/squash-rebase in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Squash Rebase safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Squash Rebase?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Squash Rebase free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Squash Rebase?

parMaster (@parmaster) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Squash Rebase by parmaster — Agent Skill

Name: Squash Rebase
Author: parMaster

Squash Rebase

Rebase the current branch onto main after its parent branch was squash-merged. Activates on "squash rebase", "rebase onto main", "parent branch was squash-merged", or when git rebase would re-apply already-merged commits.

parMaster 668875a 2.4 KB Updated Sep 17, 2026

File contents

Squash-Rebase onto Main

Rebase the current branch onto main, keeping only commits that are NOT already in main via a squash merge.

Problem this solves

When a feature branch is started from another feature branch (e.g. feat/A), and feat/A later gets squash-merged into main, the current branch inherits all of feat/A's commits. Git cannot detect that those commits are already in main (the squash changed their SHA), so a plain git rebase main would conflict or re-apply duplicate work.

Procedure

Verify we're on a branch (not detached HEAD) and that main exists.
Find the common ancestor:
```
git merge-base main HEAD
```
List all commits in the branch not in main:
```
git log --oneline main..HEAD
```
Show this to the user so they have full context.
Auto-detect the cut point using file overlap heuristic:
- Get the squash commit (first commit on main after the merge-base): git log --format="%H" "<merge-base>..main" | tail -1
- Get the files it touched: git diff --name-only <squash>^ <squash>
- Walk the branch commits from oldest to newest. For each commit, get its changed files: git diff --name-only <commit>^ <commit>
- The last commit where ALL its changed files are also in the squash commit's file list is the likely cut point.
- The first commit that touches a file NOT in the squash commit is the first "new" commit.
Show the user:
- The detected cut point commit
- The commits that WILL be replayed onto main (the new work)
- The commits that will be DROPPED (already in main via squash)
Ask for confirmation. If the auto-detected cut point looks wrong, run git log --oneline <parent-branch> (if the parent branch still exists locally) to show the user the candidate commits, and ask them to pick the correct cut point.

Run:

git rebase --onto main <cut-point-hash>

If there are conflicts, explain them and help resolve. After resolution, run git rebase --continue.
Show the final git log --oneline -5 to confirm the clean result.
Remind the user they'll need git push --force-with-lease since history was rewritten.

---name: squash-rebasedescription: Rebase the current branch onto main after its parent branch was squash-merged. Activates on "squash rebase", "rebase onto main", "parent branch was squash-merged", or when git rebase would re-apply already-merged commits.---# Squash-Rebase onto MainRebase the current branch onto main, keeping only commits that are NOT already in main via a squash merge.## Problem this solvesWhen a feature branch is started from another feature branch (e.g. `feat/A`), and `feat/A` later gets squash-merged into `main`, the current branch inherits all of `feat/A`'s commits. Git cannot detect that those commits are already in main (the squash changed their SHA), so a plain `git rebase main` would conflict or re-apply duplicate work.## Procedure1. Verify we're on a branch (not detached HEAD) and that `main` exists.2. Find the common ancestor: ``` git merge-base main HEAD ```3. List all commits in the branch not in main: ``` git log --oneline main..HEAD ``` Show this to the user so they have full context.4. Auto-detect the cut point using file overlap heuristic: - Get the squash commit (first commit on main after the merge-base): `git log --format="%H" "<merge-base>..main" | tail -1` - Get the files it touched: `git diff --name-only <squash>^ <squash>` - Walk the branch commits from **oldest to newest**. For each commit, get its changed files: `git diff --name-only <commit>^ <commit>` - The last commit where ALL its changed files are also in the squash commit's file list is the likely cut point. - The first commit that touches a file NOT in the squash commit is the first "new" commit.5. Show the user: - The detected cut point commit - The commits that WILL be replayed onto main (the new work) - The commits that will be DROPPED (already in main via squash)6. Ask for confirmation. If the auto-detected cut point looks wrong, run `git log --oneline <parent-branch>` (if the parent branch still exists locally) to show the user the candidate commits, and ask them to pick the correct cut point.7. Run: ``` git rebase --onto main <cut-point-hash> ```8. If there are conflicts, explain them and help resolve. After resolution, run `git rebase --continue`.9. Show the final `git log --oneline -5` to confirm the clean result.10. Remind the user they'll need `git push --force-with-lease` since history was rewritten.

Frequently asked questions