Worktree-per-agent automation — question on merge conflict UX

[vdalhambra]

Giving every coding agent its own git branch + worktree automatically is the cleanest answer I've seen to "how do I run 3 agents without them stomping each other's edits" — most multi-agent orchestrators try to share a workspace and end up rewriting half the file each turn. The Direct Mode (work on main when you want to) escape hatch is also the right pragmatic choice; sometimes you just want speed.

For context: I just open-sourced axiom-reflex — 7 PreToolUse hooks + 6 skills + 6 subagents for Claude Code. Apache 2.0: github.com/vdalhambra/axiom-reflex. Single-agent setup; I've been hand-rolling worktrees with the superpowers:using-git-worktrees skill but considering whether to graduate to something Parallel-Code-shaped.

Question: when two agents finish their tasks and both produce mergeable-but-overlapping diffs, what's the merge UX? Manual rebase in the host editor, automated 3-way merge inside the app, or do you just sequence them and let one block? The first time I tried this on my own I got a 4-way conflict that took longer to resolve than just doing the work serially.

No marketing intent — comparing notes between adjacent solo builders. Show HN Tuesday.

[johannesjo]

Thanks for the kind words and the axiom-reflex pointer — I'll take a look.

On the merge UX: the short version is sequence-and-block, with two rebase ramps, no in-app 3-way editor. Concretely:

• When you hit "Merge" on a task, the dialog pre-flights with git merge-tree and lists any conflicting files inline before you can confirm. If the base has moved, the merge button is disabled until you rebase.
• Two rebase paths: a plain Rebase onto <base> (deterministic, bails on conflicts), and Rebase with AI — which closes the dialog and sends "rebase on <base> branch" back to the still-running agent so it resolves the conflict with its normal toolset. In practice the AI path is what makes overlapping diffs cheap; the agent already has the context for what it just wrote.
• Merges serialize through a per-repo worktree lock, so two tasks finishing at the same time can't race each other into main — one lands, the other has to rebase.
• Deliberately no native 3-way merge GUI. Felt like reinventing a worse mergetool when the two real escape valves (CLI rebase, agent rebase) cover it.

Re: your 4-way conflict — yeah, I think the worktree-per-task model trades that for N pairwise rebases, which usually decomposes better. Whether that beats "just sequence them" depends a lot on how independent the agents' tasks are; for tightly-coupled edits it's still faster to serialize.

Good luck Tuesday!