São 2h da manhã e seus dois agentes acabaram de terminar o trabalho em paralelo: um refatorou as assinaturas de funções do módulo de pagamento, o outro adicionou um novo recurso no mesmo arquivo, e o git merge solta um gemido enquanto os marcadores de conflito inundam a tela. A quem você pede para resolver? Pergunte ao agente A e ele vai decidir que a refatoração dele importa mais; pergunte ao agente B e ele vai insistir que o novo recurso é o trabalho de verdade — uma parte envolvida na disputa nunca é um juiz imparcial. Em agosto de 2026, o Hermes incorporou uma skill chamada merge-reconciler (PR #83063) construída sobre uma ideia simples: nenhum dos autores toca no merge — um agente terceiro e neutro arbitra no lugar.

Por que as partes não conseguem se reconciliar sozinhas

Esta é a premissa em que todo o design se apoia, e é a observação que a documentação da skill martela: quando um agente encara o código de um colega, ele carrega um viés inerente — ou acredita que a própria mudança é mais correta e silenciosamente sobrescreve o outro lado, ou não consegue entender o código do colega e abandona o próprio trabalho. Nenhum dos dois resultados é bom. O ponto mais sutil é que conflitos de merge raramente são apenas “o código não aplica” — as duas mudanças carregam intenções por trás delas, e somente colocando as duas intenções na mesa você decide no que cada hunk conflitante deve se tornar.

O merge-reconciler coloca o árbitro como um terceiro sem interesse no conflito: ele recebe os dois diffs e as intenções declaradas de ambos os lados, e então decide sobre cada hunk. A skill é puramente skill-mais-documentação — zero mudanças no código do núcleo — então todo usuário do Hermes a recebe de fábrica, sem precisar atualizar configuração alguma.

Três classes de conflito, três regras de decisão

O árbitro não divide a diferença; ele classifica cada hunk conflitante e aplica a regra correspondente:

Classe de hunk	Significado	Resolução
disjoint-intent	As duas mudanças servem a objetivos diferentes e podem coexistir	Mantenha as duas — combine
same-question-different-answer	Os dois lados responderam uma mesma pergunta de design de formas diferentes	Escolha UMA conforme as intenções declaradas; deixe a decisão explícita
superseded	A premissa de um lado não se sustenta mais após a mudança do outro	Mantenha o lado sobrevivente; registre o motivo

A regra mais contraintuitiva é nunca dividir a diferença: se os dois lados responderam a mesma pergunta de design de formas diferentes, o árbitro deve escolher uma — não soldar um híbrido que ninguém projetou. O processo de decisão também roda sob um contrato de imparcialidade: nunca favorecer nenhum dos lados, tocar SOMENTE nas regiões conflitantes (sem correções oportunistas), e toda escolha de design deve aparecer no resumo final, onde um humano pode vetá-la.

Como usar: três formatos

Formato um: standalone. Carregue a skill dentro do repositório com conflito e siga o procedimento de ponta a ponta: encontre o ancestral comum com git merge-base <A> <B>, colete as mudanças dos dois lados com git log --oneline <base>..<side> e git diff <base>..<side> -- <file>, fixe as duas intenções por meio dos resumos das tarefas no kanban ou dos corpos dos PRs, e então classifique, decida, verifique e faça commit hunk por hunk.

Formato dois: delegar um agente neutro. O formato preferido para campanhas multi-agente — crie um subagente com delegate_task cuja mensagem de tarefa carrega o caminho do repositório, os nomes das duas branches, os resumos de intenção dos dois lados na íntegra e uma instrução para seguir esta skill. O subagente é um terceiro natural, sem motivo para viés.

Formato três: nativo do kanban. Se o seu trabalho paralelo passa pelo kanban, crie um card de reconciliação dedicado atribuído a um terceiro perfil (não a nenhum dos dois workers), com AMBOS os cards conflitantes vinculados como pais:

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

Os vínculos de pais carregam automaticamente os resumos de conclusão dos dois lados para o contexto do árbitro; o corpo do card apenas nomeia o caminho do repositório e as duas branches. Quando a arbitragem termina, finalize com kanban_complete(summary=...), listando a decisão de cada hunk.

Quando NÃO usar

A documentação da skill traça limites claros: conflitos dentro do trabalho de um único agente, ou colisões triviais de lockfile/arquivos gerados, devem ser regenerados em vez de arbitrados. A skill mira o caso difícil de campanhas paralelas em que dois agentes mudaram o mesmo código com intenção. E se a intenção de algum dos lados não puder ser recuperada das mensagens de commit, dos corpos dos PRs ou dos resumos do kanban — escale em vez de adivinhar. Decidir sem intenções é jogar dados.

O trabalho paralelo multi-agente é um dos pontos fortes do Hermes — já cobrimos cadeias de diretórios AGENTS.md para colaboração multi-agente e combinações de skills em cadeia. Para manter os agentes trabalhando em paralelo sem colidir, a referência de comandos do kanban e nosso guia completo de automação com cron são boas próximas leituras.