Manual del usuario

Creación de sesiones y colaboración en Git

Dos funciones que se complementan: separar subtareas en sesiones hijas independientes (opcionalmente, en worktrees de git aislados) y una fusión gráfica que vuelve a unir las ramas paralelas. Juntas permiten que varios agentes trabajen en paralelo sobre el mismo repositorio.

1. Qué es crear sesiones hijas

Desde cualquier sesión puede separar una subtarea. VelaTerm crea una sesión hija nueva debajo del nodo actual (el árbol pasa a ser jerárquico: padre → hija → nieta), le asigna opcionalmente un worktree de git aislado y envía la descripción de la tarea como primer mensaje de la nueva sesión. El nuevo agente empieza a trabajar en cuanto se inicia, sin necesidad de más explicaciones.

El resultado es una sesión real del árbol, con su propio proceso, que puede supervisar, responder, volver a abrir y reanudar en cualquier momento. No es una tarea oculta en segundo plano.

Si el trabajo debe planificarse, ejecutarse y revisarse con agentes distintos, use en su lugar un flujo de trabajo de planificación y ejecución; consulte Planificación y ejecución.

2. Formas de crear una sesión hija

Punto de entradaQuién lo usaWorktree
Comando vspawn "task"Usted o un script, en cualquier sesiónDesactivado de forma predeterminada; --worktree lo activa
Comando vspawn-tree "task"Igual que el anteriorSiempre activado
/vspawn task en Claude Code, $vspawn task en CodexUsted se lo pide al agente, que primero desarrolla la tarea hasta convertirla en instrucciones autónomasDesactivado de forma predeterminada
/vspawn-tree task en Claude Code, $vspawn-tree task en CodexIgual que el anteriorSiempre activado

Los dos comandos están disponibles en todas las sesiones que inicia VelaTerm. Las habilidades de agente requieren Vela Skills: elija «Install» en Ajustes ▸ General y, a continuación, inicie una conversación nueva de Claude Code o Codex para que el agente las cargue. Los agentes solo invocan estas habilidades cuando usted lo solicita.

Una sesión nueva no ve la conversación de la que procede. Cuando usa la habilidad, el agente incluye en la tarea el objetivo, los archivos relevantes, las conclusiones obtenidas hasta el momento, las restricciones y los criterios de aceptación. Cuando ejecuta el comando usted mismo, inclúyalos en el texto de la tarea.

3. Directorio, agente y modelo

  • Directorio. La sesión hija se inicia en el directorio donde se ejecuta el comando, que es también el repositorio que se usa para crear un worktree. Pase --cwd <path> para usar otro proyecto, por ejemplo vspawn-tree --cwd /work/project "fix the parser". Esto es importante en una colección, que no tiene carpeta de proyecto propia. Las habilidades añaden --cwd cuando la conversación identifica claramente un repositorio.
  • Agente. La sesión hija usa el mismo agente que la sesión actual; desde un terminal normal se crea una sesión de Claude Code. --claude, --codex, --copilot o --kiro eligen otro agente, y la tarjeta de confirmación ofrece todos los tipos de agente.
  • Modelo y esfuerzo. --model <name> y --effort <level> establecen el modelo y el esfuerzo de razonamiento de la sesión hija, por ejemplo vspawn --model opus --effort high "port the parser". Los nombres de modelo corresponden al agente que se va a ejecutar. Un ajuste que el agente no admite se rechaza antes de crear la sesión. Sin estas opciones, una sesión hija del mismo tipo de agente hereda los argumentos de inicio y el ajuste de permisos de la sesión padre; una sesión hija de otro tipo usa los valores predeterminados de ese agente definidos en Ajustes ▸ Agentes.
  • Vista. Una sesión hija que admite la vista de conversación se abre en la misma vista que su sesión padre, si esta también la admite; en caso contrario, se abre en la vista predeterminada del agente.

Todas las opciones se enumeran en Comandos de sesión §3.

4. Confirmación antes de crear la sesión

De forma predeterminada, cada solicitud de creación muestra primero una tarjeta de confirmación titulada «Iniciar sesión secundaria». La tarjeta no quita el foco a la sesión en la que está trabajando, y una notificación del sistema («Sesión secundaria pendiente de confirmación») le avisa de que hay una solicitud en espera.

  • La tarjeta muestra la sesión solicitante y su directorio («Sesión solicitante»), las «Instrucciones de la tarea», que se convierten en el primer mensaje de la sesión hija, la «Configuración de ejecución» («Tipo de sesión», «Modelo», «Esfuerzo de razonamiento») y la opción «Directorio de trabajo»: «Directorio actual» o «Worktree independiente».
  • Las sugerencias de modelo proceden del agente seleccionado. Si no hay ninguna lista disponible, puede escribir un identificador de modelo. Si deja un campo en «Valor predeterminado del agente», se usa el ajuste propio del agente.
  • Un terminal normal se abre en el directorio de trabajo; no ejecuta las instrucciones de la tarea.
  • «Iniciar sesión» (o ⌘Enter / Ctrl+Enter) inicia la sesión hija; «Cancelar» descarta la solicitud. Las solicitudes adicionales esperan en una cola, y la tarjeta indica cuántas quedan («N solicitudes más por revisar»).

Para iniciar las solicitudes sin la tarjeta, desactive «Confirm before spawn» en Ajustes ▸ Comportamiento o añada --yes a un comando concreto.

5. Worktrees: trabajo en paralelo sin conflictos

Con un worktree, la sesión hija trabaja en una rama nueva dentro de su propio directorio, aislada del espacio de trabajo principal y de las demás sesiones hijas. Es la configuración recomendada cuando varios agentes modifican el mismo repositorio a la vez. Los worktrees nuevos parten del commit actual y no incluyen los cambios pendientes de commit. Si no se puede crear un worktree para una sesión hija, la sesión usa el directorio original.

Una sesión que trabaja en un worktree muestra un pequeño distintivo sobre su icono en la barra lateral; sitúe el puntero sobre él para ver el nombre y la ruta del worktree.

Otras formas de trabajar con worktrees:

  • «Nueva sesión de worktree…», en el menú de proyecto, grupo o sesión, abre el cuadro de diálogo de creación con la opción «Worktree» establecida en «Nuevo». Escriba un «Nombre del worktree», que se usa para el directorio y la rama. El cuadro de diálogo también permite vincular la sesión a un worktree «Existente» o elegir «Ninguno».
  • «Mover a un worktree…», en el menú de un grupo, vincula el grupo a un worktree nuevo o existente. Las sesiones que se creen en el grupo a partir de ese momento usarán ese worktree; las que ya están en él conservan su directorio. Un grupo con worktree ofrece además «Información del grupo».

El submenú Git de una sesión o un grupo cuyo directorio es un repositorio git contiene:

OpciónFunción
«Ver cambios…»Muestra los cambios del árbol de trabajo con una lista de archivos y sus diferencias
«Merge…»Abre el cuadro de diálogo de fusión (§6)
«Copy worktree path», «Open worktree folder»Disponibles en sesiones y grupos vinculados a un worktree
«Delete worktree…»Permite elegir un worktree de este repositorio y eliminar su directorio del disco; «Force delete (discard uncommitted changes)» lo elimina aunque tenga cambios pendientes de commit

Después de eliminar un worktree vinculado, el menú de la sesión o del grupo ofrece «Convert to normal session» o «Convert to normal group», que quitan la vinculación para que la sesión vuelva a iniciarse en el directorio del proyecto.

Al eliminar una sesión que tiene worktrees en su subárbol, la confirmación ofrece eliminar también esos worktrees.

6. Fusión gráfica de ramas con Git

Cuando el trabajo esté terminado, fusiónelo. En cualquier sesión o grupo cuyo directorio sea un repositorio git, con o sin worktree, elija «Git ▸ Merge…» para abrir el cuadro de diálogo «Merge branches»:

  • Elija ambas ramas. Seleccione una rama de origen («Source branch») y una rama de destino («Target branch»); «Swap direction» las intercambia. El mismo cuadro de diálogo sirve para fusionar la rama de una sesión hija en la rama principal o para incorporar la rama principal a una sesión hija y actualizarla.
  • Antes de que usted confirme, el cuadro de diálogo enumera los cambios que la fusión incorpora a la rama de destino.
  • La fusión se ejecuta en el árbol de trabajo en el que está activa la rama de destino. Si la rama de destino no está activa en ningún árbol de trabajo, la fusión no puede ejecutarse; haga checkout de ella primero.
  • Si el árbol de trabajo de la rama de origen tiene cambios pendientes de commit, primero se hace commit de ellos con el mensaje que usted escriba («Commit & merge»).
  • Si la fusión tiene conflictos, VelaTerm los deja tal como están y le indica dónde resolverlos. Resuélvalos en el terminal de ese worktree (o pida a un agente que lo haga) y, después, haga commit.

La fusión no elimina el worktree. Elimínelo después con «Git ▸ Delete worktree…» cuando ya no lo necesite.

7. Un flujo de trabajo típico

  1. En la sesión principal, comente la tarea con Claude Code y, después, ejecute /vspawn-tree refactor the checkout module (requiere Vela Skills).
  2. Revise la tarea en la tarjeta de confirmación y elija «Iniciar sesión». La sesión hija se inicia en su propio worktree y aparece en la barra lateral bajo su sesión padre, con un punto de estado verde mientras trabaja.
  3. Continúe en la sesión principal. Cuando la sesión hija pregunte algo o termine, su punto cambiará y aparecerá una notificación.
  4. Revise el trabajo de la sesión hija y, a continuación, elija «Git ▸ Merge…» para fusionar su rama en la rama principal.
  5. Elimine el worktree con «Git ▸ Delete worktree…» y, después, archive la sesión hija para conservar un registro.