git-worktree-branch-rationalization
Made by JeffRationalize a repo's accumulated git worktrees and local branches down to a canonical line plus protected branches, harmonizing the strongest content from every variant onto a staging branch before any destructive cleanup. Use when a project has piled up local branches or linked worktrees ("213 branches, 47 worktrees", agent-swarm aftermath, "rationalize my branches", "kill all worktrees save what's worth saving", "merge what's worth merging and delete the rest", or "branch archaeology").
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
2Updates, enhancements, and release notes for this skill.
Enhanced: git-worktree-branch-rationalization, history mining that tells no history from no answer
Phase 0.5 reported "5 of 5 queries returned matches" for zero-hit and timed-out cass answers, and "clean" when cass failed. It now distinguishes the three outcomes, and it re-mines a findings file that an earlier run left incomplete.
- Zero-hit and timed-out answers are no longer counted as matches.
- A project whose searches failed is reported as UNKNOWN, not clean.
- A findings file left incomplete is re-mined on the next run instead of being treated as current.
- A query that got no complete answer says so, including whether cass ran out of its time budget.
- A worked example no longer uses a --window flag that cass does not have.
scripts/cass-mine.sh mines prior sessions for branch-rationalization history on the project. It counted any non-empty cass output as a match, so empty and timed-out answers both produced "5 of 5 queries returned matches", while a failing search was dropped, which could leave "Skill-state: clean" on a project that was never checked.
New: git-worktree-branch-rationalization, collapse 213 branches and 47 worktrees into canonical without losing any of the work
A stash is one diff: pick or drop. Branches collide on the same files in incompatible ways, and picking the "right" branch misses the point. The job is to recover the strongest current implementation of every file by inspecting every variant, identifying each part's intent, and synthesizing on top of canonical's architecture. That's the ◇ HARMONIZE operator; without it, this skill would be git-stash-janitor with extra steps.
- Phase 3 builds the recovery bundle before any verdict: refs/branch-rationalization-backup/*, a git object bundle, per-worktree dirty-state captures, and per-branch format-patches. Byte-for-byte verified before anything destructive runs.
- Keepers land on branch-rationalization-<YYYY-MM-DD>, cut from canonical's tip; canonical itself is never touched. Merging or cherry-picking from there happens at the user's pace. Landing 200 branches onto canonical in one shot is exactly what the human review gate is for.
- Worktrees prune first, branches second. A worktree pinned to a branch blocks git branch -d; remove the worktree, free the branch, then prune. git worktree remove refuses on dirty worktrees, which is the safety net. rm -rf <worktree-path> is forbidden, and DCG blocks it on purpose.
- Verbatim authorization per destructive phase, logged to cleanup_authorization.txt with a UTC timestamp. If that file doesn't exist, the action did not happen.