alex20-create/wrap-up

Cierre de sesión

El usuario está a punto de archivar este chat. Todo lo que solo existe en la conversación está a punto de perderse: lo que se decidió, lo que cambió en el disco, lo que la próxima sesión debe retomar. Varios skills instalados guardan cada uno una parte de eso. La tarea de este skill es encontrarlos, ejecutarlos en el orden correcto y detenerse después de una confirmación.

El conjunto de skills no es fijo: los complementos van y vienen, el usuario escribe nuevos skills. Nunca codifiques nombres fijos; descúbrelos cada vez a partir de lo que está instalado y luego compáralos con las categorías en references/close-out-catalogue.md. El catálogo indica qué es cada categoría, en qué orden y a qué costo; este archivo indica cómo se ejecuta cada una en cada entorno. Si ambos parecen estar en desacuerdo, sigue el catálogo para el qué y el orden, este archivo para el cómo, y menciona el desacuerdo en el informe para que el usuario pueda corregir el catálogo.

0. Saber dónde estás y la antigüedad de la sesión

La mayor parte de lo que sigue cambia con el entorno y con la antigüedad de la sesión, así que establece ambos primero y dilo en una línea al principio del plan. Tres entornos:

• Claude Code en la máquina del usuario. Un shell en esa máquina, skills en ~/.claude/skills, hooks que se ejecutan (incluyendo, si está configurado, un hook SessionEnd que registra cada sesión; el mapa local o settings.json indican si lo hay), repositorios y vault en el disco. Todo lo siguiente se aplica tal como está escrito.
• claude.ai o una sesión en la nube con un shell de dispositivo. El chat se ejecuta en un contenedor Linux, pero aparece una herramienta de shell para la computadora del usuario, por lo que los comandos se ejecutan allí, dentro de las carpetas que el usuario conectó. El vault y cualquier script almacenado en una carpeta conectada son accesibles. Los archivos propios de este skill (el catálogo, scripts/) viven en el contenedor, no en esa máquina. Los hooks no se ejecutan. La memoria se maneja a través de las herramientas de memoria, y un pase en segundo plano archiva hechos duraderos después de cada turno.
• claude.ai o una sesión en la nube sin ese shell. Los archivos en la computadora del usuario solo son accesibles a través de las herramientas que colocan un archivo en el contenedor y lo confirman de vuelta, y solo mientras la aplicación de escritorio esté vinculada. De lo contrario, nada en su disco es accesible. Hooks y memoria como arriba.

Señales: la plataforma y el directorio de trabajo, qué herramientas están listadas (shell de dispositivo, herramientas de archivos de dispositivo, herramientas de memoria), qué dice el prompt del sistema sobre la memoria y sobre un Proyecto. Si no puedes determinarlo, dilo y pregunta, porque una suposición incorrecta escribe en el lugar equivocado.

Luego la antigüedad. Por lo general, se solicita un cierre al final del trabajo, pero un chat puede permanecer abierto durante días y cerrarse más tarde, después de que otras sesiones hayan trabajado en los mismos archivos, notas y skills. La sesión está obsoleta cuando algo que tocó cambió después de su último trabajo real: compara la fecha de ese trabajo (las marcas de tiempo de la conversación o notas fechadas) con las horas de modificación de los archivos y las entradas del almacén que tocó, una confirmación posterior, una entrada del almacén con fecha posterior, o un skill que usó y que ahora aparece renombrado o ya no aparece. Un solo cambio es suficiente. La antigüedad por sí sola es una razón para mirar, no un veredicto: un chat de una semana que nadie retomó no está obsoleto. Dilo en la línea superior junto con la brecha ("activo por última vez el 4 de noviembre; los archivos que tocó cambiaron desde entonces").

En una sesión obsoleta, el disco y los almacenes son más nuevos que la conversación, por lo que ganan:

• Antes de planificar cualquier escritura, lee la versión actual de cada archivo y entrada del almacén que el paso tocaría, y planifica en función de lo que hay ahora, no de lo que recuerda la conversación.
• Una decisión que tomó la sesión y que una sesión posterior ya registró está hecha: señálala, no la escribas de nuevo. Una que una sesión posterior cambió o revirtió no es para que este cierre la restaure: nómbrala como reemplazada y elimínala. Cuando el registro posterior cubre solo parte de la decisión, o no está claro cuánto cubre, elimina solo la parte que cubre claramente y nombra el resto como posiblemente reemplazado; de qué manera va depende de la pregunta única.
• Las rutas, nombres y skills que usó la sesión pueden haberse movido o renombrado. Resuelve cada uno de nuevo antes de usarlo. Un nuevo formulario cuenta solo cuando algo escrito desde entonces lo indica (memoria, una nota, una confirmación, la propia descripción de un skill que dice cómo se llamaba antes); usa ese formulario y dilo. Cuando nada lo indica, nombra el antiguo como que ya no se resuelve en lugar de adivinar, y no lo escribas en un almacén como si fuera actual.
• Lo que queda por proponer es lo que la sesión decidió y nada desde entonces ha registrado, cambiado o contradicho. Eso puede ser muy poco; un cierre obsoleto que escribe una línea, o nada, es un cierre correcto.

El mismo chat puede ya contener un cierre anterior, ejecutado antes de que el usuario siguiera trabajando. Entonces este cierre se basa en ese en lugar de empezar de nuevo: toma su plan y marca cada paso como hecho (su informe lo dice y el disco está de acuerdo), reemplazado o aún pendiente, y verifica solo lo que sucedió después. Un plan que el cierre anterior propuso y el usuario nunca respondió no fue aprobado: traslada sus pasos pendientes a este plan, verificados nuevamente contra el disco y las reglas anteriores, en lugar de ejecutarlos o eliminarlos en silencio, y di en la línea superior que existe un cierre anterior.

1. Descubrir

Antes de descubrir nada, verifica las instrucciones permanentes del entorno (en Claude Code los archivos CLAUDE.md y la memoria automática, que cuenta como permanente aquí; en claude.ai las instrucciones del Proyecto, las preferencias del usuario y la memoria, y una sección Mapa local para esta instalación que una copia empaquetada de este SKILL.md puede contener) para un mapa local de esta rutina: una sección corta que nombra qué skill instalado cubre cada categoría, los almacenes, lo que está retirado y los costos medidos. Cuando existe uno, reemplaza el descubrimiento; verifica que cada skill que nombra todavía esté instalado (y un comando o ruta nombrada con una búsqueda económica de solo lectura donde sea útil), y trata lo que retira como resuelto. Un mapa parcial (almacenes o retiros nombrados, pero ningún skill por categoría) informa el descubrimiento en lugar de reemplazarlo: respeta lo que nombra, descubre el resto, y la oferta de la sección 5 se convierte en completar esa sección, no en agregar una segunda. Cuando no existe ninguno, descubre como sigue y ofrece al final escribir uno (sección 5). En Claude Code, lee los archivos CLAUDE.md del disco, no solo del contexto: una copia inyectada puede ser anterior a una edición, y una obsoleta te envía a un descubrimiento completo y una oferta para escribir un segundo mapa sobre uno que ya existe.

La lista de candidatos es la lista de skills disponibles ya en contexto (nombre + descripción). Cubre skills locales, skills de complementos y gstack por igual; no hay mejor fuente. Dos peculiaridades de la lista: un skill que aparece tanto con como sin un prefijo de complemento, misma descripción, es un solo skill, así que llámalo por el nombre simple en el plan, pero invócalo con el nombre exacto que muestra la lista; y la lista puede crecer durante la ejecución cuando un comando toca una carpeta que lleva sus propios skills, cuyas llegadas tardías cambian el plan solo si coinciden con una categoría.

Lee references/close-out-catalogue.md. Para cada categoría que define, elige los skills instalados cuya descripción coincida con su propósito. Los miembros conocidos son pistas, no la respuesta: un skill instalado no listado allí califica si su descripción encaja, uno listado que ya no está instalado se omite. Presta atención a los casi aciertos que marca el catálogo. Cuando la lista muestra un skill solo por nombre (ambos entornos hacen esto para algunos), haz coincidir el nombre y las palabras "Reconocer por" del catálogo, y márcalo como "(sin descripción)" en el plan para que el usuario sepa que la coincidencia es más débil.

Una categoría sin un skill instalado va en el plan como "saltar, no instalado"; no improvises un reemplazo, a menos que el entorno tenga su propio mecanismo para ese trabajo (sección 2). Algunas categorías no son skills (en Claude Code, la memoria automática se escribe con la herramienta Escribir y una actualización del gráfico es un comando); son pasos en el mismo plan, solo cuando el entorno los tiene.

Luego verifica qué vale realmente la pena hacer en esta sesión:

• Gráficos. En Claude Code en la máquina, ejecuta python scripts/find_graphs.py <workspace-root> (ruta relativa al directorio de este skill; cualquier Python funciona). La raíz del espacio de trabajo es la carpeta de trabajo de la sesión, o la carpeta más amplia que las instrucciones del proyecto describen como que contiene todos los repositorios, cuando lo hacen. El script enumera cada graphify-out/ cuya carpeta de proyecto está como máximo a cinco niveles por debajo, y si los archivos cambiaron desde su manifiesto: una línea por gráfico, ACTUAL, OBSOLETO con recuentos de cambios y eliminaciones, o DESCONOCIDO (sin manifiesto, o graphify no importable), o una sola línea que dice que no se encontró ninguno. Los recuentos no indican si los cambios son notas, ~85k cada una para reextraer, o código, que no necesita LLM; dilo a partir de lo que tocó la sesión. ACTUAL no es un paso, incluso si recuerdas haber editado un archivo graficado: el manifiesto sabe si el gráfico se reconstruyó después de eso. Sin Python en la máquina, los gráficos no se verifican; dilo. En cualquier otro lugar donde el script no pueda ver el espacio de trabajo (se ejecuta en el contenedor, los gráficos están en el disco del usuario): reporta cada gráfico como no verificado, que no es "nada que actualizar".
• La sesión. ¿Decisiones, correcciones, nuevos hechos sobre el usuario o el proyecto, archivos creados o movidos? Eso decide si los pasos de memoria y aprendizajes tienen algo que escribir. Una sesión que fue puramente de lectura puede no necesitar nada más que un guardado de contexto.
• Git. git status en cada repositorio que la sesión tocó. El trabajo no confirmado no es competencia de este skill confirmarlo; va en la línea "se queda con el usuario" del plan. Cuando la historia de la sesión y git no coinciden (archivos cambiados en la sesión, un árbol limpio), nombra la discrepancia en lugar de reconciliarla en silencio.
• Escrituras reclamadas. Enumera lo que la sesión dijo que escribió, creó, instaló o cambió (archivos, notas, confirmaciones, configuraciones, paquetes instalados) y verifica cada uno con una mirada de solo lectura: existe, y su contenido es el que la sesión escribió (una línea distintiva o el tamaño, no solo la existencia, ya que una sobrescritura fallida deja el archivo anterior en su lugar). Una herramienta que informó éxito no es una prueba. Cuando el contenido difiere, la hora de modificación decide: cambiado después del último trabajo de la sesión significa que una sesión posterior lo cambió (sección 0, obsoleto); no cambiado después significa que la escritura nunca se realizó. Un archivo que debería existir y no existe tampoco se realizó, a menos que una confirmación o nota posterior registre su eliminación. Una escritura que nunca se realizó, o un trabajo que la sesión dejó a medio hacer (instalado en algunos lugares y no en otros, un paso que prometió y no ejecutó), va en la línea "dejado roto" del plan (sección 3). Una sesión que no reclamó escrituras omite esto.
• Trabajo en progreso que otro skill reparte en varias sesiones (catálogo, "Trabajo en progreso"). No es un paso propio: va en la nota de traspaso y en el guardado de contexto.
• Dónde ya vive el estado. Las instrucciones del proyecto pueden nombrar los almacenes que el usuario trata como fuente: un vault, una base de datos de proyecto, un campo que contiene la siguiente acción. Lee las instrucciones antes de planificar cualquier escritura (los almacenes mismos son leídos por los pasos que los escriben); deciden cómo se ejecutan las categorías 3 y 5. Cuando dos almacenes nombrados podrían contener el mismo hecho (una nota de decisiones y una nota de proyecto, por ejemplo), el plan nombra a cuál apunta la escritura; si las instrucciones no lo resuelven, resuélvelo en la pregunta única, nunca en silencio.

2. Lo que cambia con el entorno

En Claude Code, ejecuta cada categoría como describe el catálogo; de lo que sigue, solo las reglas que así lo dicen vinculan allí también. En los otros dos casos de la sección 0, ajústalo así.

1 Memoria: verificar, no escribir. El pase en segundo plano ya archiva hechos duraderos después de cada turno. Lee los archivos de memoria que probablemente haya usado (la lista muestra las rutas) y di en el plan si las decisiones de esta sesión están allí. El pase se ejecuta después de cada turno, por lo que lo que se decidió en el propio turno de cierre aún no está allí y se archivará después; eso es normal, no una brecha. La plataforma solo permite una escritura de memoria a petición explícita del usuario, así que si algo que dijeron falta, nómbralo en el plan y deja que digan "guardarlo"; esa frase es la solicitud. Dentro de un Proyecto, las escrituras van en el propio subárbol del Proyecto, en la forma que requieren las instrucciones de memoria.

1b Nota de traspaso, 2 Aprendizajes: saltar si no están instalados. No hay reemplazo; un documento del Proyecto, una nota nueva o un resumen del chat no se convierten en uno (ver la regla de un solo lugar).

3 Sincronización del vault: depende del alcance. Con un shell de dispositivo y la carpeta del vault conectada, ejecuta el skill de sincronización si está instalado; si necesita algo de lo que carece este entorno, lo dirá, y luego haz la sincronización manualmente. Sin un shell, y solo mientras la computadora esté vinculada, hazlo manualmente con las herramientas de archivos. De cualquier manera, lee primero la nota de convenciones del propio vault (colócala cuando no haya shell) y pon cada cambio propuesto en el plan como lo que se queda, lo que cambia y lo que desaparece, para que la confirmación única cubra las escrituras. El registro de sesión que escribe un hook no existe aquí; dilo.

4 Gráfico: no verificado, como dice la sección 1. No es "nada que hacer".

5 Guardado de contexto: escribir donde dice el proyecto. Esto también se aplica en Claude Code: un lugar que las instrucciones del proyecto nombran gana sobre un skill de instantánea genérico, y sin uno, el skill de instantánea instalado es el paso. Si las instrucciones del proyecto nombran un lugar donde "dónde lo dejé" (un campo en una base de datos de proyecto, por ejemplo), ese lugar es el guardado de contexto. Si un skill instalado posee ese lugar (una rutina de cierre diario), ese skill es el paso; si ya se ejecutó en esta sesión, saltar. De lo contrario, escribe allí tú mismo. El plan lleva el texto exacto propuesto para ese lugar, para que la respuesta única lo cubra; esa regla se aplica cuando escribes el lugar tú mismo, mientras que un skill que posee la escritura compone su propio contenido, en Claude Code o en cualquier lugar. Si ninguna entrada del proyecto cubre en qué trabajó la sesión, dilo y propón...

[...truncado para traducción...]