handoff

name: handoff description: Compacta la conversación actual en un doc de handoff (estado, próximos pasos) para que otra sesión retome sin re-derivar contexto. Invocar al cerrar una sesión larga con trabajo en curso o antes de cambiar de plataforma ZedBox ↔ x86. argument-hint: "[foco de la próxima sesión]"

Comprime el estado de la sesión actual en un documento que otra sesión (o agente fresco) puede leer en 30 segundos para continuar el trabajo sin re-explorar el repo.

Cuándo invocar

La sesión va larga y aún hay trabajo en curso que no cabe en un finding (porque no es estructural, es estado efímero).
Hay que cambiar de plataforma: lo que se hizo en el host x86 lo retomará una sesión en la ZedBox (o al revés).
El usuario va a cerrar y quiere volver mañana sin tener que releer toda la conversación.
Antes de un wakeup programado / /loop con espera larga.

Cuándo NO invocar

Para conocimiento estructural reusable → usar zedbox-knowledge (crear un finding).
Para una decisión de alcance académico → usar course-deliverables (no es estado de sesión, es heurística permanente).
Para "ya terminé" sin trabajo pendiente → no se necesita handoff.

Diferencia con un finding

	Finding	Handoff
Vida útil	Permanente, reusable en cualquier sesión	Una sola sesión sucesora
Contenido	Hallazgo no obvio del entorno o pipeline	Estado de sesión: dónde quedé
Ubicación	`docs/findings/YYYY-MM-DD-<slug>.md`	`docs/handoffs/YYYY-MM-DD-<slug>.md`
Tono	"X falla porque Y, workaround Z"	"Estaba haciendo X, me falta Y, próximo paso Z"

Si una sesión empieza recurriendo a un handoff antiguo más de una vez, ese contenido probablemente ya merece convertirse en finding.

Procedimiento

Determinar fecha (date +%Y-%m-%d) y slug kebab-case en inglés describiendo el foco (ej. macvo-rerun-capture-debug, zedbox-viewer-hdmi-bringup).
Verificar que docs/handoffs/ existe:
```
mkdir -p docs/handoffs
```
Escribir el doc en docs/handoffs/YYYY-MM-DD-<slug>.md con la estructura de la plantilla (.claude/skills/handoff/assets/handoff.md).
Solo referenciar artefactos existentes (findings, planes, commits, PRs) por path o URL — NO duplicar su contenido.
Redactar información sensible (API keys, contraseñas, PII). Este repo es público en GitHub.
Si el usuario pasó argumento ($ARGUMENTS), tratarlo como descripción del foco de la próxima sesión y adaptar el doc.

Estructura mínima del handoff

# Handoff <fecha>: <tema corto>

## Contexto
Una o dos frases: ¿qué se intentaba lograr?

## Estado actual
- ✅ <lo que quedó hecho>
- 🟡 <lo que quedó a medias>
- ❌ <lo que no se intentó todavía>

## Próximos pasos concretos
1. <acción accionable + comando o archivo>
2. ...

## Skills sugeridas para la sesión sucesora
- `<skill>` — por qué encaja.

## Artefactos referenciados
- [findings/...](../findings/...) — qué aporta.
- Commit `<hash>` — qué cambió.
- `docs/...` — qué consultar.

## Bloqueos / riesgos
- <bloqueo y workaround conocido si existe>

Reglas de contenido

En español (igual que el resto de docs del repo, ver CLAUDE.md §7).
Sin emojis salvo los tres marcadores de estado (✅ 🟡 ❌).
Paths relativos al root del repo.
Fechas absolutas YYYY-MM-DD.
No commitear handoffs con info sensible — leer antes del commit.

Limpieza periódica

Los handoffs son efímeros por diseño. Cuando un handoff se ha "consumido" (la sesión sucesora terminó el trabajo), puede borrarse o moverse a docs/handoffs/_archive/ si tiene valor histórico. No acumular handoffs vivos sin propósito; saturan el índice.