agentleFS
lbednerlbedner/aegis-stack/.claude/skills/squash-branch/SKILL.md

squash-branch

Skill144 starsChanged 15 months agoMITView on GitHub

Use when collapsing a feature branch into a single commit before opening or merging a PR. Covers the non-interactive squash, dropping co-author trailers, and verifying the tree is unchanged.

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use when a feature branch has several work-in-progress commits that should land as one commit.

    line 15
  2. Distinctive:

    Do NOT use on a shared branch others have based work on (rewriting its history breaks their clones), and do NOT run any git command here …

    line 18
  3. Distinctive:

    Commit once with a clean message and no co-author or generated-by trailers: git commit.

    line 39
  4. Very specific:

    Verify nothing changed: git rev-parse HEAD^{tree} must equal the value from step 2, and git log --oneline <base>..HEAD must show exactly …

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Squash branch

Collapse all of a branch's commits into one, authored by the committer, with a clean message and no co-author trailers. Interactive rebase (git rebase -i) is not available in this environment, so the squash uses git reset --soft against the base, which produces the identical end state.

When to use

Use when a feature branch has several work-in-progress commits that should land as one commit.

Do NOT use on a shared branch others have based work on (rewriting its history breaks their clones), and do NOT run any git command here without explicit user request, per the repo git policy.

Files that change

None. This operates on git history, not the working tree. The tree at HEAD is byte-for-byte identical before and after; only the commit history collapses.

Procedure

  1. Confirm the base and that the branch is ahead of it with nothing behind: git rev-list --count <base>..HEAD (commits to squash) and git rev-list --count HEAD..<base> (must be 0; rebase onto <base> first if not).
  2. Record the current tree to verify the squash later: git rev-parse HEAD^{tree}.
  3. Collapse to staged changes without moving the working tree: git reset --soft <base>.
  4. Stage any intended uncommitted additions with git add, leaving unrelated working-tree changes out.
  5. Commit once with a clean message and no co-author or generated-by trailers: git commit. The commit is authored by the configured git identity.
  6. Verify nothing changed: git rev-parse HEAD^{tree} must equal the value from step 2, and git log --oneline <base>..HEAD must show exactly one commit.

Gates

  • The post-squash tree hash must equal the pre-squash tree hash (step 6); a mismatch means content was dropped or added, not just recommitted.
  • git log --oneline <base>..HEAD shows a single commit.

Pitfalls

  • git reset --soft leaves the index and working tree untouched, so uncommitted or untracked files are still present after it; stage deliberately in step 4 so unrelated changes do not get folded into the squash.
  • Squashing rewrites history, so a branch already pushed needs a force push (--force-with-lease), which is an outward-facing action the user must approve.
  • Writing a fresh commit message drops any co-author or generated-by trailers from the original commits, which is the intended cleanup; do not carry them forward.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.