merge

Descripción general de merge skill

Para qué sirve merge skill

merge skill es una skill de flujo de trabajo de AgentHub para integrar el resultado del agente ganador en una rama base de Git después de una sesión de codificación con varios agentes. Está diseñada para el comando /hub:merge y se centra en una tarea práctica: fusionar el ganador seleccionado, conservar los intentos no ganadores para revisarlos más adelante, limpiar los worktrees de la sesión y escribir un resumen posterior al merge.

Mejor encaje en Git Workflows

Usa esta merge skill cuando tu repositorio siga el patrón de AgentHub con IDs de sesión, ramas de agentes, rankings de evaluación y worktrees temporales. Resulta especialmente útil después de /hub:eval, cuando ya sabes qué agente produjo la mejor solución y quieres un Git Workflow repetible en lugar de hacer checkout manual de ramas, fusionar, etiquetar los intentos perdedores y eliminar worktrees.

Qué la diferencia de un prompt genérico de merge

Un prompt genérico podría decir “merge the best branch”, pero esta skill codifica una convención operativa concreta: usar el agente mejor clasificado salvo que se proporcione --agent, hacer merge con --no-ff, archivar las ramas no ganadoras con tags hub/archive/..., eliminar sus referencias de rama y generar .agenthub/board/results/merge-summary.md. Esa estructura reduce la ambigüedad durante la limpieza, que suele ser el punto en el que las sesiones Git con varios agentes se vuelven difíciles de mantener.

Notas de adopción antes de instalar

La skill asume que tu proyecto ya tiene ramas con estilo AgentHub, como hub/{session-id}/{agent-id}/attempt-1, y resultados de evaluación capaces de identificar un ganador. Si tu equipo no usa AgentHub, la guía de merge sigue siendo útil como modelo para una limpieza estructurada, pero necesitará adaptación antes de usarla de forma segura.

Cómo usar merge skill

Instalación de merge e archivos que conviene revisar primero

Instala la skill desde el repositorio de skills en GitHub con:

npx skills add alirezarezvani/claude-skills --skill merge

Después revisa el código fuente en:

engineering/agenthub/skills/merge/SKILL.md

Esta skill parece estar autocontenida en SKILL.md; en la vista previa del directorio de la skill no se observan carpetas complementarias rules/, resources/ ni scripts/. Como las instrucciones upstream hacen referencia a session_manager.py, verifica dónde existe ese script en tu configuración local de AgentHub antes de depender de una limpieza automatizada.

Uso básico de merge

Las llamadas habituales son:

/hub:merge
/hub:merge 20260317-143022
/hub:merge 20260317-143022 --agent agent-2

Usa /hub:merge cuando el objetivo sea la última sesión evaluada. Proporciona un ID de sesión cuando existan varias sesiones de AgentHub. Añade --agent solo cuando quieras sobrescribir de forma intencional el resultado mejor clasificado de /hub:eval, por ejemplo si la puntuación más alta pasó por alto un requisito de seguridad, compatibilidad o producto detectado en la revisión humana.

Entradas que necesita la skill

Para un uso fiable de merge, el agente necesita:

• La rama base de destino, normalmente la rama en la que quieres integrar el trabajo ganador.
• El ID de sesión de AgentHub, salvo que la sesión más reciente sea inequívoca.
• Un ganador, ya sea desde el ranking de la evaluación más reciente o desde --agent.
• Referencias de rama existentes con el formato esperado: hub/{session-id}/{agent-id}/attempt-1.
• Permiso para ejecutar operaciones de Git que crean commits de merge, tags y eliminaciones de ramas.

Un prompt más sólido sería: “Run /hub:merge 20260317-143022 --agent agent-2 into main. Before merging, confirm the working tree is clean, show the winning branch ref, tag losing branches for archive, and write the merge summary.” Esto le da a la skill suficiente contexto operativo para evitar suposiciones.

Flujo práctico antes y después de ejecutarla

Antes de llamar a merge, ejecuta git status, confirma que no tienes cambios locales no relacionados y revisa el diff ganador. Después del merge, comprueba el mensaje del commit de merge, confirma que se hayan creado los tags de archivo y verifica que .agenthub/board/results/merge-summary.md refleje la sesión, la tarea y el ganador. Si aparecen conflictos, resuélvelos como conflictos normales de Git; la skill aporta estructura de flujo de trabajo, no sustituye la revisión de código.

Preguntas frecuentes sobre merge skill

¿merge es solo para AgentHub?

Sí, en la práctica. La merge skill está escrita alrededor de las convenciones de nombres, evaluación y limpieza de AgentHub. Puede servir de inspiración para un Git Workflow manual en otros experimentos con múltiples ramas, pero su uso directo espera ramas de sesión de AgentHub y metadatos de resultados.

¿merge elige automáticamente el mejor código?

Elige el --agent que especifiques o, si no lo indicas, el agente mejor clasificado de la ejecución más reciente de /hub:eval. Eso significa que la calidad del merge depende de la calidad de la evaluación previa. Si tus criterios de evaluación estaban incompletos, revisa manualmente el ganador antes de fusionarlo.

¿Qué ocurre con las ramas no ganadoras?

El flujo previsto archiva cada rama de agente no ganadora con un tag de Git como hub/archive/{session-id}/{agent-id} y después elimina la referencia de rama. Así los commits siguen siendo alcanzables y se reduce el desorden de ramas. Los equipos con políticas de retención deberían confirmar la convención de nombres de los tags de archivo antes de adoptar la skill.

¿Cuándo no debería usar esta skill?

No uses merge si los nombres de las ramas no siguen la convención de AgentHub, si la rama base no está clara, si el ganador no se ha revisado o si tu repositorio prohíbe la eliminación automatizada de ramas. Tampoco encaja bien en flujos que exigen squash-only, salvo que adaptes el comando de merge, porque el patrón predeterminado de la skill usa git merge --no-ff.

Cómo mejorar merge skill

Mejora los resultados de merge con más contexto

La merge skill funciona mejor cuando tu solicitud incluye el ID de sesión, el ganador, la rama base y cualquier restricción de política. Por ejemplo: “Merge session 20260317-143022, winner agent-2, into develop; keep losing branches archived with tags, do not delete remote branches, and stop if tests fail.” Esto es mejor que “merge the winner” porque separa selección, destino, limpieza y reglas de seguridad.

Modos de fallo habituales que debes vigilar

Los principales riesgos son sesiones más recientes ambiguas, resultados de evaluación ausentes, working trees sucios, referencias de rama que no coinciden con el patrón esperado y comandos de limpieza que dependen de archivos fuera del directorio de esta skill. Otro riesgo importante es fusionar un ganador técnicamente correcto pero equivocado desde el punto de vista de producto. Trata /hub:eval como una entrada para la selección, no como sustituto de la revisión final.

Adapta merge a la política de tu repositorio

Si tu equipo exige squash merges, commits firmados, ramas protegidas, pull requests, gates de CI o retención de ramas remotas, edita el flujo antes de usarlo en producción. Los puntos de personalización más probables son la estrategia de merge, el formato de los tags de archivo, si la eliminación de ramas es solo local y qué campos son obligatorios en merge-summary.md.

Itera después de la primera ejecución

Después de la primera salida, pide al agente que verifique en lugar de continuar a ciegas: “Show the merge commit, list archive tags for this session, confirm no AgentHub worktrees remain, and summarize any conflicts or skipped cleanup.” Esto convierte la guía de merge en un Git Workflow auditable y ayuda a detectar limpiezas parciales antes de que la sesión quede olvidada.