orca-handoff

Como /handoff, pero no se queda en el archivo: abre la sesión nueva y le entrega el input.

Un handoff que solo escribe un .md es medio trabajo — obliga al usuario a abrir terminal, arrancar el agente y pegar el contexto a mano.

1 · Escribir el documento de handoff

Aplica íntegras las reglas de /handoff:

• Guardar en el directorio temporal del SO, nunca en el workspace. Usa el scratchpad de sesión si existe.
• Incluir una sección "Suggested skills".
• No duplicar lo que ya viva en PRDs, planes, ADRs, issues, commits o diffs — referenciarlo por path o URL.
• Redactar cualquier secreto: API keys, passwords, PII.
• Si el usuario pasó argumentos, son el foco de la próxima sesión: adapta el documento a eso.

Añade además, porque el agente nuevo arranca a ciegas:

• Gotchas del entorno que le harían perder tiempo (limitaciones de MCP, bugs de escapado, mounts raros, comandos que no existen en esta plataforma).
• IDs y rutas literales que necesitará (UUIDs, handles, paths absolutos) — que no tenga que redescubrirlos.
• Estado del entorno al cerrar: daemons corriendo o parados, rama actual, instalaciones recientes.

2 · Resolver el binario de Orca

Sigue la skill orca-cli para elegir el ejecutable. Resumen: $ORCA_CLI_COMMAND si está · orca-dev en checkout dev · orca-ide en Linux fuera de terminales Orca (ahí orca es el lector de pantalla de GNOME y arranca voz) · orca en el resto.

Comprueba que la app responde:

orca status --json

Si no está corriendo, orca open --json. Si el ejecutable elegido falla, reporta el error exacto y para — no pruebes otro binario, apuntaría a otra build.

3 · Cargar la guía versionada antes de ejecutar

orca skills get orca-cli

No adivines subcomandos ni flags de memoria — cambian entre releases de Orca. Es una guía larga; filtra la sección que necesitas (grep -n -iE "terminal|handoff|worktree create") en vez de volcarla entera al contexto.

4 · Decidir: terminal en el checkout actual, o worktree nuevo

La decisión que más se equivoca. Regla:

Un worktree nuevo para trabajo que no toca archivos del repo solo añade fricción y un checkout que limpiar después.

Para trabajo en paralelo con otros agentes, el worktree sí es obligatorio: sin aislamiento se pisan. Peor si el repo vive en Google Drive.

5 · Abrir la terminal y entregar el prompt

Caso corriente (mismo checkout):

orca terminal create --worktree active --title "<slug-de-la-tarea>" --command "claude" --json
orca terminal wait --terminal <handle> --for tui-idle --timeout-ms 90000 --json
orca terminal send --terminal <handle> --text "<prompt>" --enter --json

Caso worktree aislado:

orca worktree create --name <slug> --no-parent --agent claude --prompt "<prompt>" --json

--agent arranca el agente en la primera terminal y --prompt le entrega el trabajo; evita el patrón "crear worktree y luego abrir agente", que deja un shell huérfano.

El wait --for tui-idle no es opcional en el camino de dos pasos: mandar texto antes de que el TUI esté listo lo pierde.

Agentes disponibles como --agent: claude, codex, omp, pi, grok, y otros TUI instalados.

Qué escribir en el prompt

No repitas el handoff — apúntale a él:

1. Ruta absoluta del documento de handoff, y de los artefactos que referencia (plan, PRD).
2. El foco de la sesión, en una línea.
3. Los 2-4 problemas concretos que va a encontrar, nombrados.
4. Las reglas de trabajo que no puede deducir (modo de checkpoints, dónde vive la fuente de verdad).
5. Los gotchas que más caro le saldrían.

6 · Parar

Un handoff completo transfiere la propiedad. Reporta la terminal y el handle creados, y deja de monitorear.

No uses orca orchestration task-create ni dispatch --inject ni check --wait — eso es orquestación supervisada, y se pide distinto. Si el usuario quiere supervisar, esperar resultados o coordinar un DAG, esta no es la skill: usa orchestration.

Gotchas

Relacionadas

handoff (solo documento) · orca-cli (guía completa del CLI) · orchestration (cuando sí quieres supervisar en vez de transferir)