Es ist 2 Uhr nachts, und deine beiden Agents sind gerade mit ihrer Parallelarbeit fertig: Der eine hat die Funktionssignaturen des Zahlungsmoduls refaktoriert, der andere hat in derselben Datei ein neues Feature hinzugefügt — und git merge stöhnt auf, als Konfliktmarker den Bildschirm fluten. Wen fragst du, das aufzuräumen? Frag Agent A, und er entscheidet, dass sein Refactoring wichtiger ist; frag Agent B, und er besteht darauf, dass das neue Feature die eigentliche Arbeit ist — ein Beteiligter ist nie ein unbefangener Richter. Im August 2026 hat Hermes einen Skill namens merge-reconciler (PR #83063) gemergt, der auf einer einfachen Idee beruht: Keiner der beiden Autoren fasst den Merge an — stattdessen schlichtet ein neutraler dritter Agent.

Warum sich die Parteien nicht selbst einigen können

Das ist die Prämisse, auf der das gesamte Design beruht — und die Beobachtung, die die Skill-Doku unermüdlich wiederholt: Steht ein Agent dem Code eines Kollegen gegenüber, bringt er eine eingebaute Voreingenommenheit mit. Entweder hält er die eigene Änderung für korrekter und überschreibt die andere Seite stillschweigend, oder er kann mit dem fremden Code nichts anfangen und verwirft die eigene Arbeit. Keines der beiden Ergebnisse ist gut. Der subtilere Punkt: Merge-Konflikte sind selten bloß „Code lässt sich nicht anwenden“ — hinter beiden Änderungen stecken Absichten, und nur wenn beide Absichten auf dem Tisch liegen, lässt sich entscheiden, was aus jedem umstrittenen Hunk werden soll.

merge-reconciler setzt den Schlichter als unbeteiligten Dritten ohne Eigeninteresse am Konflikt ein: Er erhält beide Diffs plus die erklärten Intents beider Seiten und entscheidet dann über jeden Hunk. Der Skill ist reines Skill-plus-Docs — null Änderungen am Kerncode —, sodass jeder Hermes-Nutzer ihn out of the box bekommt, ohne Konfigurations-Update.

Drei Konfliktklassen, drei Entscheidungsregeln

Der Schlichter teilt nicht die Differenz; er klassifiziert jeden umstrittenen Hunk und wendet die passende Regel an:

Hunk-Klasse	Bedeutung	Auflösung
disjoint-intent	Die beiden Änderungen verfolgen unterschiedliche Ziele und können koexistieren	Beides behalten — kombinieren
same-question-different-answer	Beide Seiten haben eine Designfrage unterschiedlich beantwortet	EINE Variante gemäß den erklärten Intents wählen; die Entscheidung sichtbar machen
superseded	Die Prämisse einer Seite gilt nach der Änderung der anderen nicht mehr	Die überlebende Seite behalten; begründen, warum

Die kontraintuitivste Regel ist teile niemals die Differenz: Haben beide Seiten dieselbe Designfrage unterschiedlich beantwortet, muss der Schlichter eine Variante wählen — keinen Hybrid, den niemand entworfen hat. Der Entscheidungsprozess läuft außerdem unter einem Unparteilichkeits-Vertrag: nie eine Seite bevorzugen, NUR umstrittene Regionen anfassen (keine Gelegenheits-Fixes), und jede Design-Entscheidung muss in der Abschlusszusammenfassung auftauchen, wo ein Mensch sie überstimmen kann.

So nutzt du ihn: drei Formen

Form eins: eigenständig. Den Skill im betroffenen Repo laden und die Prozedur von oben bis unten durchgehen: den gemeinsamen Vorfahren mit git merge-base <A> <B> finden, die Änderungen beider Seiten mit git log --oneline <base>..<side> und git diff <base>..<side> -- <file> sammeln, beide Intents über Kanban-Task-Zusammenfassungen oder PR-Bodies festnageln, dann Hunk für Hunk klassifizieren, entscheiden, verifizieren und committen.

Form zwei: einen neutralen Agent delegieren. Die bevorzugte Form für Multi-Agent-Kampagnen — einen Subagent mit delegate_task spawnen, dessen Task-Nachricht den Repo-Pfad, beide Branch-Namen, die Intent-Zusammenfassungen beider Seiten wortwörtlich und die Anweisung enthält, diesem Skill zu folgen. Der Subagent ist ein natürlicher Dritter ohne Motiv für Voreingenommenheit.

Form drei: kanban-nativ. Läuft deine Parallelarbeit über Kanban, erstelle eine eigene Reconciliation-Karte, die einem dritten Profil zugewiesen ist (nicht einem der beiden Worker), mit BEIDEN konfliktbehafteten Karten als Eltern:

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

Die Eltern-Verknüpfungen bringen die Abschluss-Zusammenfassungen beider Seiten automatisch in den Kontext des Schlichters; der Kartentext nennt nur Repo-Pfad und die beiden Branches. Wenn die Schlichtung abgeschlossen ist, schließe mit kanban_complete(summary=...) ab und liste das Urteil für jeden Hunk auf.

Wann du ihn NICHT nutzen solltest

Die Skill-Doku zieht klare Grenzen: Konflikte innerhalb der Arbeit eines einzelnen Agents oder triviale Kollisionen bei Lockfiles/generierten Dateien sollten neu generiert statt geschlichtet werden. Ziel sind die harten Fälle paralleler Kampagnen, in denen zwei Agents denselben Code mit Absicht verändert haben. Und wenn sich der Intent einer Seite nicht aus Commit-Messages, PR-Bodies oder Kanban-Zusammenfassungen rekonstruieren lässt — eskalieren statt raten. Ohne Intents zu entscheiden, ist Würfeln.

Parallele Multi-Agent-Arbeit ist eine der Stärken von Hermes — wir haben AGENTS.md-Verzeichnis-Ketten für die Multi-Agent-Kollaboration und verkettete Skill-Kombos behandelt. Damit Agents parallel arbeiten, ohne zu kollidieren, sind die Kanban-Befehlsreferenz und unser kompletter Cron-Automation-Guide gute nächste Lektüre.