Son las 2 de la madrugada y tus dos agents acaban de terminar su trabajo en paralelo: uno refactorizó las firmas de las funciones del módulo de pagos, el otro añadió una nueva feature en el mismo archivo, y git merge deja escapar un gemido mientras los marcadores de conflicto inundan la pantalla. ¿A quién le pides que lo arregle? Pídeselo al agent A y decidirá que su refactor importa más; pídeselo al agent B e insistirá en que la nueva feature es el trabajo real — quien es parte de una disputa nunca es un juez imparcial. En agosto de 2026, Hermes incorporó un skill llamado merge-reconciler (PR #83063) construido sobre una idea simple: ninguno de los autores toca el merge — un agent neutral de terceros arbitra en su lugar.

Por qué las partes no pueden reconciliarse solas

Esta es la premisa sobre la que descansa todo el diseño, y es la observación que la documentación del skill remacha: cuando un agent se enfrenta al código de un compañero, arrastra un sesgo inherente — o cree que su propio cambio es más correcto y sobrescribe silenciosamente al otro lado, o no logra dar sentido al código del compañero y abandona su propio trabajo. Ninguno de los dos resultados es bueno. El punto más sutil es que los conflictos de merge rara vez son solo «el código no aplica» — ambos cambios llevan intenciones detrás, y solo poniendo ambas intenciones sobre la mesa puedes decidir en qué debería convertirse cada hunk en conflicto.

merge-reconciler presenta al árbitro como un tercero sin intereses en el conflicto: recibe ambos diffs más las intenciones declaradas de ambas partes y luego dictamina sobre cada hunk. El skill es puro skill-más-documentación — cero cambios en el código del núcleo — así que todos los usuarios de Hermes lo reciben de serie, sin necesidad de actualizar la configuración.

Tres clases de conflicto, tres reglas de dictamen

El árbitro no parte la diferencia; clasifica cada hunk en conflicto y aplica la regla correspondiente:

Clase de hunk	Significado	Resolución
disjoint-intent	Los dos cambios sirven a objetivos distintos y pueden convivir	Mantener ambos — combinar
same-question-different-answer	Ambas partes respondieron de forma distinta a una misma pregunta de diseño	Elegir UNO según las intenciones declaradas; dejar la decisión a la vista
superseded	La premisa de un lado ya no se sostiene tras el cambio del otro	Conservar el lado superviviente; anotar el motivo

La regla más contraintuitiva es nunca partir la diferencia: si ambas partes respondieron de forma distinta a la misma pregunta de diseño, el árbitro debe elegir una — no soldar un híbrido que nadie diseñó. El proceso de dictamen también se rige por un contrato de imparcialidad: no favorecer nunca a ninguno de los lados, tocar SOLO las regiones en conflicto (nada de arreglos oportunistas), y cada decisión de diseño debe aparecer en el resumen final, donde un humano pueda vetarla.

Cómo usarlo: tres formas

Forma uno: autónoma. Carga el skill dentro del repo en conflicto y sigue el procedimiento de principio a fin: encuentra el ancestro común con git merge-base <A> <B>, recoge los cambios de ambos lados con git log --oneline <base>..<side> y git diff <base>..<side> -- <file>, fija ambas intenciones a través de los resúmenes de las tareas kanban o los cuerpos de los PR, y luego clasifica, dictamina, verifica y haz commit hunk a hunk.

Forma dos: delegar un agent neutral. La forma preferida para las campañas multi-agent — lanza un subagent con delegate_task cuyo mensaje de tarea lleve la ruta del repo, los nombres de ambas branches, los resúmenes de intención de ambas partes verbatim, y la instrucción de seguir este skill. El subagent es un tercero natural, sin motivo de sesgo.

Forma tres: nativa de kanban. Si tu trabajo en paralelo pasa por kanban, crea una tarjeta de reconciliación dedicada asignada a un tercer perfil (no al de ninguno de los dos workers), con AMBAS tarjetas en conflicto enlazadas como padres:

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

Los enlaces de parentesco llevan automáticamente los resúmenes de finalización de ambas partes al contexto del árbitro; el cuerpo de la tarjeta solo nombra la ruta del repo y las dos branches. Cuando termina el arbitraje, cierra con kanban_complete(summary=...), enumerando el dictamen de cada hunk.

Cuándo NO usarlo

La documentación del skill traza límites claros: los conflictos dentro del propio trabajo de un solo agent, o las colisiones triviales de lockfiles/archivos generados, deben regenerarse en lugar de arbitrase. El skill apunta al caso difícil de las campañas en paralelo donde dos agents cambiaron el mismo código con intención. Y si la intención de alguno de los lados no se puede recuperar de los mensajes de commit, los cuerpos de los PR o los resúmenes kanban — escala en lugar de adivinar. Dictaminar sin intenciones es tirar los dados.

El trabajo multi-agent en paralelo es uno de los puntos fuertes de Hermes — ya hemos cubierto las cadenas de directorios AGENTS.md para la colaboración multi-agent y las combinaciones de skills en cadena. Para mantener a los agents trabajando en paralelo sin colisionar, la referencia del comando kanban y nuestra guía completa de automatización con cron son buenas próximas lecturas.