Stop being your agents' merge queue. cc-merge queues the worktrees your parallel Claude sessions leave behind, rebases each onto tip, runs your checks, and merges only what passes.
go install github.com/yasyf/cc-merge/cmd/cc-merge@latest
cc-merge --helpDriving with an agent? Paste this:
Install cc-merge with `go install github.com/yasyf/cc-merge/cmd/cc-merge@latest`.
Queue my finished Claude Code worktrees and land them on main one at a time,
rebasing each onto the current tip and running the repo's checks before each merge.
Stop and tell me the moment a rebase conflicts or a check fails.
Six sessions finish within minutes of each other, and suddenly you're the merge queue, deciding who lands first and re-running checks after every rebase. cc-merge takes that job. It picks the order, lands one worktree at a time, and stops the queue the moment something needs a human.
Each branch was green against the main it started from, not the main it lands on. cc-merge rebases every finished worktree onto the current tip and re-runs your checks before merging, so a merge that would break main never reaches it.
Finished worktrees pile up, and a day later you can't tell which are merged, which are waiting, and which are stuck on a conflict. cc-merge reads the queue and reports each worktree as ready, blocked, or landed. No archaeology through git worktree list.
cc-merge is an early scaffold today. The CLI installs and runs; the queue engine is what lands next. Licensed under PolyForm Noncommercial 1.0.0.