La habilidad /resolving-merge-conflicts

Fuente: The /resolving-merge-conflicts Skill — traducción comunitaria no oficial al español.

Qué hace

resolving-merge-conflicts trabaja un merge o rebase de git en curso, trozo por trozo, luego ejecuta las comprobaciones propias del proyecto y termina la operación con un commit.

Se niega a tratar un conflicto como un problema de texto. Antes de tocar un trozo rastrea cada lado hasta su fuente primaria (el mensaje de commit, la PR, la incidencia original), así elige entre dos intenciones y no entre dos bloques de texto, y preserva ambas donde son compatibles. Donde genuinamente no lo son, elige el lado que coincide con el objetivo declarado del merge y nombra la concesión. No inventa ningún comportamiento nuevo para tapar un choque, y --abort no es una opción que tenga: el merge siempre se lleva hasta un commit terminado.

Cuándo recurrir a ella

Escribe /resolving-merge-conflicts, o el agente la usará automáticamente cuando la tarea encaje.

Recurre a ella cuando git ya se detuvo en conflictos que no pudo resolver solo. Está acotada al conflicto que tienes delante, no a nada a sus lados:

Tu situación	Habilidad
A mitad de merge o rebase, con marcadores de conflicto en el árbol	Esta
Merge terminado, algo ahora se porta mal por razones que no ves	diagnosing-bugs
Planear cómo trocear el trabajo para que las ramas choquen menos	Ninguna: ver la pregunta de trabajo paralelo abajo

Fuentes primarias antes que ours y theirs

El modo de fallo que esto existe para matar es resolver por bandera: --ours, --theirs, o borrar a mano el bloque que parezca menos importante, para que los marcadores desaparezcan y el build compile. Esa resolución puede ser sintácticamente perfecta y aun así soltar en silencio un cambio que alguien hizo a propósito.

No puedes preservar una intención que no has leído. Así que el trabajo empieza en el historial (commits, PR, tickets) y solo después se mueve al diff. Otro paso del bucle existe por la misma razón: la habilidad localiza las comprobaciones automatizadas propias del repositorio y las ejecuta antes de publicar el commit, porque un merge es el lugar más fácil en git para producir código que satisface a ambas ramas y no pasa las pruebas de ninguna.

Preguntas comunes

Claude Code ya resuelve conflictos bastante bien solo. ¿Por qué esto necesita una habilidad?

El valor añadido son los pasos de «encuentra las fuentes primarias» y «ejecuta bucles de retroalimentación», que si no hay que pedirlos a mano cada vez. Un agente sin instrucciones suele producir una resolución plausible solo desde el diff y ahí se detiene. El valor de la habilidad son los dos pasos que no deja saltarse al agente: leer por qué existe cada lado y ejecutar las comprobaciones después. Es un margen fino sobre un buen modelo, y está hecho a propósito: al menos un lector ha predicho que esta es una habilidad completa que se vuelve un no-op a medida que mejoran los modelos.

¿Debería mantener a los agentes paralelos fuera de los mismos archivos para evitar conflictos desde el inicio?

Mayormente no. Zonificar archivos entre tareas paralelas cuesta más de lo que ahorra, porque los agentes son lo bastante buenos en conflictos de merge para que el trueque no sea tan duro como parece. La única disciplina que vale la pena conservar es hacer primero las refactorizaciones grandes. Un renombrado grande aterrizando después de que diez ramas bifurcaron desde él es el caso que sigue siendo caro.

Una advertencia de un reporte de usuario sobre worktrees paralelos: cuando sesiones hermanas construyen cada una un ticket en su propio árbol, el merge de vuelta lo hace mejor la sesión que escribió el cambio, porque es la que ya conoce la intención. Amontonar los conflictos de todos en un agente al final desperdicia exactamente el contexto que el paso 2 de esta habilidad tiene que ir a reconstruir.

¿Por qué nunca --abort?

Abortar tira el trabajo de resolución y te devuelve al mismo conflicto, sin cambios, la próxima vez que lo intentes. La habilidad está escrita para el caso en que el merge va a ocurrir. Si decidiste que no debería ocurrir, esa es una decisión para tomar antes de invocar, no una rama dentro del bucle.

Funciona si

• El agente te cita mensajes de commit, PR o incidencias mientras resuelve, no solo trozos de diff.
• Cada trozo termina con el comportamiento de ambos lados, o con una nota explícita que nombra lo que se soltó y por qué.
• Nada aparece en el resultado que no estuviera en ninguna rama.
• Typecheck, pruebas y formato se localizaron y corrieron en verde antes del commit, no después de que notaste algo roto.
• Terminas en un árbol limpio con la operación completada, incluyendo cada commit restante en un rebase de varios commits.

Dónde encaja

Una habilidad independiente para usar en cualquier momento sin dependencias de ninguna otra habilidad: empieza cuando git se atasca y termina cuando el árbol queda limpio y publicado. Su única vecina real es diagnosing-bugs, que toma el relevo en el punto donde un merge se resolvió limpio pero el código fusionado se porta mal: un problema de diagnóstico, no de conflicto. Está totalmente fuera del flujo principal de idea a publicación, así que ask-matt es el mapa de lo que corre antes y después.