Finito

Cierra la sesión con un resumen que se entiende y dos bloques de traspaso: uno para compactar ahora y otro para volver otro día.

Cuándo se usa

Al terminar de trabajar, antes de cerrar la conversación o antes de compactarla.

SKILL.md

# Finito

Una sesión termina dos veces. Primero para la persona, que cierra el portátil y
necesita saber en treinta segundos qué pasó y qué toca ahora. Después para el
siguiente agente, que mañana abre un contexto en blanco y no sabe nada de hoy.

Casi todos los cierres solo sirven al primero. Por eso la sesión siguiente empieza
releyendo archivos, repreguntando lo que ya se contestó y repitiendo un fallo que
ya se pagó una vez. El contexto se fue, pero el trabajo del que salió sigue ahí.

## Antes de escribir nada

Repasa la conversación desde el último cierre y ejecuta git status y git log. El
cierre tiene que reflejar lo que de verdad pasó, no lo que se recuerda por encima:
la memoria de una sesión larga es optimista y confunde intenciones con resultados.

Lo que quedó a medias se cuenta como a medias. Lo que no se ejecutó no está
verificado. Y si un plan se abandonó a mitad, se dice y se dice por qué: eso es lo
más valioso que hereda la sesión siguiente.

## Lo que solo sabe esta sesión

Hay cosas de hoy que no están en ningún sitio salvo en esta conversación, y
desaparecen con ella. Antes de responder, guárdalas donde sobrevivan: en los
documentos del proyecto y en la memoria persistente del agente, si la tiene. Solo
lo que falte, y actualizando lo que ya exista en vez de duplicarlo.

No guardes lo que el repositorio ya registra. El código y los commits ya están
escritos: esto es para lo que no se puede deducir de ellos. Si no hay nada nuevo
que guardar, se dice y ya.

## El formato de la respuesta

1. **Una frase** con lo esencial de la sesión.
2. **Resumen**, en orden, máximo ocho puntos. Frases simples y sin jerga: se lee
   en el móvil.
3. **Próximos pasos**, máximo cinco, el más importante primero.
4. **Qué se dejó apuntado**, en una línea.
5. **El bloque de traspaso** y **el de retomar**.

## Los dos bloques

Van dentro de un bloque de código cada uno, para copiarlos de un clic, y hacen
trabajos distintos. Por eso son dos y no uno.

El **traspaso** se pega justo después de compactar, con la conversación todavía
viva. Lleva cinco partes: el contexto del proyecto y sus normas no negociables; lo
hecho en orden, con las rutas exactas y el porqué de cada decisión; el estado real,
con la rama, lo que quedó sin commitear y lo que siga corriendo; lo que queda
abierto, cada cosa con el dato para retomarla sin releer nada; y las trampas del
día. La prueba es simple: ¿podría el siguiente agente continuar solo con este
bloque? Si un detalle hace falta para seguir, entra.

El de **retomar** se pega en frío, otro día, en una ventana nueva o en otra
herramienta, donde no queda nada de hoy. Por eso empieza por dónde está el
proyecto y no por lo que se hizo: la carpeta, el estado real con lo que falta por
subir, la primera acción concreta y la trampa del día. Va escrito en primera
persona para pegarlo tal cual, y es corto: si ocupa más que el traspaso, sobra la
mitad.

Las trampas son la parte que todo el mundo se salta y la única que se paga sola.
Un fallo ya resuelto, resuelto otra vez desde cero, es lo más caro que tiene un
proyecto largo.

## Reglas

- Proporción: una sesión de veinte minutos tiene un cierre de veinte minutos.
- No des por hecho lo que no se hizo ni por verificado lo que no se ejecutó.
- El estado del repositorio se dice siempre, aunque no quede nada pendiente.
- Nunca hagas commit ni push por tu cuenta al cerrar. Recuérdalo y pregunta.
- Los números, las versiones y las rutas van completos en las dos mitades.