It’s 2am and your two agents have just finished their parallel work: one refactored the payment module’s function signatures, the other added a new feature in the same file, and git merge lets out a groan as conflict markers flood the screen. Who do you ask to sort it out? Ask agent A and it will decide its refactor matters more; ask agent B and it will insist the new feature is the real work — a party to a dispute is never an impartial judge. In August 2026, Hermes merged a skill called merge-reconciler (PR #83063) built on a simple idea: neither author touches the merge — a neutral third-party agent arbitrates instead.

Why the parties can’t reconcile themselves

This is the premise the whole design rests on, and it’s the observation the skill’s docs hammer home: when an agent faces a peer’s code, it carries an inherent bias — either it believes its own change is more correct and quietly overwrites the other side, or it can’t make sense of the peer’s code and abandons its own work. Neither outcome is good. The subtler point is that merge conflicts are rarely just “code won’t apply” — both changes carry intentions behind them, and only by putting both intentions on the table can you decide what each conflicted hunk should become.

merge-reconciler casts the arbiter as a third party with no stake in the conflict: it receives both diffs plus both sides’ stated intents, then rules on every hunk. The skill is pure skill-plus-docs — zero core code changes — so every Hermes user gets it out of the box, no config upgrade required.

Three conflict classes, three ruling rules

The arbiter doesn’t split the difference; it classifies every conflicted hunk and applies the matching rule:

Hunk class	Meaning	Resolution
disjoint-intent	The two changes serve different goals and can coexist	Keep both — combine
same-question-different-answer	Both sides answered one design question differently	Pick ONE per the stated intents; surface the decision
superseded	One side’s premise no longer holds after the other’s change	Keep the surviving side; note why

The most counterintuitive rule is never split the difference: if both sides answered the same design question differently, the arbiter must pick one — not weld a hybrid that nobody designed. The ruling process also runs under an impartiality contract: never favor either side, touch ONLY conflicted regions (no opportunistic fixes), and every design pick must appear in the final summary where a human can veto it.

How to use it: three shapes

Shape one: standalone. Load the skill inside the conflicted repo and follow the procedure top to bottom: find the common ancestor with git merge-base <A> <B>, collect both sides’ changes with git log --oneline <base>..<side> and git diff <base>..<side> -- <file>, pin down both intents via kanban task summaries or PR bodies, then classify, rule, verify, and commit hunk by hunk.

Shape two: delegate a neutral agent. The preferred shape for multi-agent campaigns — spawn a subagent with delegate_task whose task message carries the repo path, both branch names, both sides’ intent summaries verbatim, and an instruction to follow this skill. The subagent is a natural third party with no bias motive.

Shape three: kanban-native. If your parallel work runs through kanban, create a dedicated reconciliation card assigned to a third profile (not either worker’s), with BOTH conflicted cards linked as parents:

kanban_create(
    title="reconcile branch-a x branch-b",
    assignee="reconciler",
    parents=["t_a", "t_b"]
)

The parent links carry both sides’ completion summaries into the arbiter’s context automatically; the card body just names the repo path and the two branches. When arbitration finishes, wrap up with kanban_complete(summary=...), listing the ruling for every hunk.

When NOT to use it

The skill’s docs draw clear boundaries: conflicts within a single agent’s own work, or trivial lockfile/generated-file collisions, should be regenerated instead of arbitrated. It targets the hard case of parallel campaigns where two agents changed the same code with intent. And if either side’s intent can’t be recovered from commit messages, PR bodies, or kanban summaries — escalate instead of guessing. Ruling without intents is rolling dice.

Parallel multi-agent work is one of Hermes’ strengths — we’ve covered AGENTS.md directory chains for multi-agent collaboration and chained skill combos. To keep agents working in parallel without colliding, the kanban command reference and our complete cron automation guide are good next reads.