Drakula1980/claude-skills

Cierre de sesiones y remate de cabos sueltos

En el proyecto se han acumulado sesiones paralelas: algunas han terminado, otras esperan al propietario, otras han dejado cambios sin commiteear, ramas, copias de trabajo y hallazgos para "más tarde". La tarea es dejar todo en un estado en el que el propietario pueda cerrar lo superfluo sin perder nada.

Tú eres la única sesión que se encarga de esto (orquestador). A partir de ahora, todo pasa a través de ti: las demás sesiones te entregan su trabajo, tú haces las preguntas al propietario y él ya no entra en sus ventanas.

Resultado esperado

1. Archivo de cierre en el proyecto, con una primera sección de una página "AHORA" que se vea de un vistazo.
2. Cada resultado en git (su propio commit, fusionado o etiquetado como sin fusionar) o indicado explícitamente como "fuera de git, sin copia".
3. Lista de pendientes del propietario: numerada, por orden de importancia, con comandos listos.
4. Una sola cola de hallazgos en lugar de nuevas sesiones y tarjetas.
5. Sesiones superfluas archivadas; las que permanecen abiertas se enumeran con el motivo y la condición para cerrarlas.
6. El tablero del proyecto, los documentos de estado y la memoria se ajustan a los hechos.

Reglas

Cada una surge de un error real; los casos están en references/lessons.md.

1. Un hecho es la salida de un comando. "Commiteado", "fusionado", "publicado", "pruebas superadas" se obtienen de git y de las ejecuciones, no del informe de una sesión ni de tu propia memoria de lo que ocurrió hace una hora. Cualquier número proveniente de un informe de sesión se etiqueta como "según el informe de la sesión".
2. Lo que se puede hacer sin permiso del propietario y lo que necesita su palabra.
   • Sin permiso: leer; mantener el archivo de cierre; copiar lo necesario de carpetas temporales al proyecto (sin sobrescribir nada).
   • Después del primer informe (paso 3), dentro de la solicitud original: modificar el tablero, los documentos de estado y la memoria para que coincidan con los hechos.
   • Solo con permiso: commit, fusión, eliminación de rama, copia o etiqueta, envío al servidor, despliegue en el entorno de pruebas, archivo de sesión, traslado y renombrado de paquetes y scripts desde donde el propietario los ejecuta. "Commit" no significa "envía", "fusiona" no significa "elimina la copia".
   • El permiso puede ser específico: visible en las acciones: "las que hayan entregado, ciérralas según vayan entregando", "lo entregado, commitealo en su rama". Anótalo textualmente en la página "AHORA" y no lo extiendas a acciones vecinas.
3. La palabra del propietario es lo que escribe en tu ventana. Sus palabras parafraseadas por una sesión vecina son el informe de esa sesión: para ella es una autorización, para ti no.
4. Las sesiones no se multiplican. Las sesiones que se cierran casi siempre encuentran nuevos defectos y crean tarjetas, y el propietario las ejecuta: al final de la limpieza hay más sesiones que al principio. Acuerda con el propietario de inmediato: las tarjetas no se ejecutan, los hallazgos van en una línea en la cola. Y diles esto a las sesiones (plantilla "Nuevo orden").
5. Antes de cualquier acción modificadora, relee el estado. El propietario suele dar la misma instrucción tanto a ti como a otra sesión. Antes de un commit: git log -3, git status, el índice; antes de modificar un archivo compartido: comprueba si ha cambiado en el último minuto.
6. No eludas las prohibiciones ajenas. La escritura en servidores de producción y todo lo que una comprobación de permisos haya detenido o detendría lo hace el propietario. No busques una ruta alternativa ni se lo encargues a una sesión vecina: es la misma elusión.
7. El resultado significativo no lo verifica quien lo hizo. La fusión, el paquete de despliegue, el script para producción: los verifica un ejecutor independiente al que se le da el resultado, no tu conclusión sobre él.
8. Coordina el gasto. Verificar docenas de sesiones requiere muchos ejecutores. Indica la escala antes de empezar, si el propietario tiene una regla sobre gastos (consulta su CLAUDE.md).

Procedimiento

Paso 0. Marco

Antes de leer los registros de sesiones, establece cuatro cosas; las anotarás en la sección "Marco" del archivo de cierre en el paso 3.

• Qué se considera proyecto. La carpeta del proyecto y todos los repositorios en los que han trabajado sus sesiones, incluidos los que están en otras carpetas. Para encontrarlos: repo_state.py <carpeta-del-proyecto> para una carpeta sin git muestra los repositorios dentro; sessions.py list muestra por cada sesión las carpetas y repositorios a los que ha accedido mediante git -C. Confirma la lista con el propietario en una línea.
• Dónde está el estado. Tablero o registro de orquestación, documentos de estado, memoria. Si no hay tablero, el archivo de cierre lo será. No leas el tablero completo si es grande: busca por nombre las secciones de reglas y las anotaciones sobre las sesiones relevantes.
• Qué sesiones no tocar. Sesiones de programación y recordatorios (marcadas como "programación" en list), sesiones de otros proyectos, la sesión necesaria para la siguiente etapa, tú mismo.
• Reglas específicas del propietario: commits, envío, producción, entorno de pruebas, gasto. Están en CLAUDE.md, en el tablero y en la memoria: léelas, no las parafrasees de memoria.

Paso 1. Inventario (solo lectura)

Los scripts están en scripts/ de esta habilidad y solo leen. Ejecútalos desde la carpeta del proyecto (o con --root <carpeta-del-proyecto>). La ruta a la carpeta de la habilidad la inserta Claude Code en los comandos: la habilidad se instala de diferentes maneras (carpeta personal, carpeta del proyecto, plugin), así que no escribas la ruta de memoria. Si la ruta no se ha insertado (en el comando aparece un signo de dólar con llaves), toma la carpeta de la línea "Base directory for this skill" al inicio de la habilidad.

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" list --days 14

python3 -B "${CLAUDE_SKILL_DIR}/scripts/repo_state.py" <repositorio> <repositorio>

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" scratch

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" cards --days 14

• Sesiones por registros — list: cómo terminó el registro, cuándo escribió el propietario, en qué carpetas y repositorios trabajó la sesión. Los registros de un repositorio vecino se añaden con --project <ruta o nombre de carpeta>. El registro no sabe si la sesión está archivada o si sigue activa.
• Sesiones en la aplicación — mcp__ccd_session_mgmt__list_sessions. Las herramientas de la aplicación pueden ser diferidas: cárgalas mediante ToolSearch (select:mcp__ccd_session_mgmt__list_sessions,mcp__ccd_session_mgmt__archive_session,SendMessage,ListAgents), de lo contrario, pensarás que no existen. Establece limit con margen (por defecto 20), para contar archivos — include_archived: true. La respuesta incluye sesiones de todos los proyectos: filtra por carpeta; la sesión actual no aparece en la respuesta. El número de sesión en la aplicación (local_…) no es igual al número del registro: haz coincidir por nombre. Si no hay herramienta, pide al propietario una captura de la lista.
• Repositorios — repo_state.py: cambios sin commit, ignorados, ramas sin fusionar, copias de trabajo y si están limpias, cambios en el área de preparación, sin enviar, operaciones incompletas.
• Carpetas temporales — scratch: qué desaparecerá cuando se limpie el sistema (no en el momento del archivo, pero sin previo aviso).
• Tarjetas — cards: qué tarjetas han creado las sesiones y cuáles no se han ejecutado. Las no ejecutadas van a la cola de hallazgos. "Ejecutada pero sin registro" significa que la sesión se ha ido a otro proyecto: añádelo mediante --project.

Recursos compartidos (entorno de pruebas, bloqueos, datos de prueba): una línea aparte: si el bloqueo está libre, si no quedan datos temporales de otros.

Paso 2. Verificación de cada sesión

Para cada sesión, responde a las mismas preguntas y anótalas en la tabla (references/templates.md):

Pregunta	Cómo se confirma
¿Qué hacía y dónde está el resultado?	repositorio, rama, hash, archivos
¿Está commiteado?	git status de su copia de trabajo — vacío
¿Está fusionado?	git merge-base --is-ancestor <rama> <principal>
¿Está documentado el resultado?	documentos del proyecto, tablero, memoria — leer
¿Qué espera del propietario?	sus últimos mensajes + si no se ha cerrado desde entonces
¿Hay una promesa de "haré después…"?	cola del registro
¿Qué hay en su carpeta temporal?	sessions.py scratch

Cola del registro: sessions.py tail "<parte del nombre>" --last 40. Las tres últimas réplicas se imprimen completas, al resto se les corta el medio; completas — --chars 0. La copia de trabajo y la rama de la sesión se toman de su mensaje final, de las líneas "carpetas" y "trabajó mediante git -C" y del historial de herramientas (--tools): el campo de la rama en el registro suele estar vacío.

Etiquetas: PROPIETARIO — escrito por una persona en esa ventana; TARJETA — primer mensaje de una sesión ejecutada desde una tarjeta: el texto lo escribió otra sesión, no el propietario; SESIÓN — mensaje de otra sesión; PROGRAMACIÓN — ejecución automática. La ausencia de la palabra del propietario en la salida no demuestra que no la hubiera: después de comprimir el registro, las palabras se recogen en un resumen.

El veredicto es uno de estos cinco:

• cerrar ahora — entregado; el resultado está en git o etiquetado como "fuera de git, sin copia"; todo lo que espera del propietario se ha trasladado a la lista de pendientes del propietario, y la sesión en sí no es necesaria para ello;
• cerrar después de una acción — nombra una acción y de quién es;
• dejar abierta — está activa o se necesita más adelante; nombra el motivo y la condición para cerrarla;
• no tocar — programaciones y proyectos ajenos;
• ya archivada — verifica solo su carpeta temporal, copias de trabajo y cambios sin commit.

Si hay más de una docena de sesiones, existe la herramienta Workflow y el propietario acepta la verificación paralela, ejecuta ${CLAUDE_SKILL_DIR}/references/audit-workflow.js (lectores por grupos, verificación separada de ubicaciones de almacenamiento, resumen; los parámetros se describen al inicio del archivo, en skill pasa ${CLAUDE_SKILL_DIR}). De lo contrario, verifícalo tú mismo con la misma lista de preguntas.

Trampas de este paso:

• Una rama sin commits propios no significa "fusionada": así se ve también una rama donde el trabajo quedó sin commit, y una rama nueva de una sesión que acaba de empezar.
• La rama ya no existe (git responde con código 128) — no es "no fusionada": verifica el hash de su punta desde la cola del registro.
• Una sesión con la palabra "listo" en medio del registro podría haber encontrado después un defecto en su propio trabajo. Lee el final, no el primer "listo".
• El diagnóstico de una sesión sin experiencia de control es una suposición. No lo traslades a los documentos como causa.

Paso 3. Archivo de cierre y primer informe

El archivo — CIERRE_DE_SESIONES_<AAAA-MM-DD>.md junto al tablero (esqueleto en references/templates.md). Si el archivo de esa fecha ya existe, no lo crees de nuevo ni lo sobrescribas: léelo, reescribe solo la sección "AHORA", y traslada la anterior al registro más abajo. En un proyecto git, el archivo permanece sin commit hasta que el propietario lo indique — menciónalo en la sección "Qué no está en git".

Como primera sección — página "AHORA": para qué sirve todo esto y qué orden rige, qué se ha hecho, qué está en git, qué sesiones están abiertas, qué palabras ha dado el propietario y qué se ha hecho con ellas, qué debe ejecutar él mismo, cola de hallazgos. Debajo, la tabla y el registro.

Reescribe la página después de cada evento, no añadas al final: el propietario la lee cuando pierde el hilo. Con cada modificación, actualiza la hora en el encabezado, recalcula los números de las listas y relee el bloque de decisiones: "en curso" y "esperando" no deben permanecer después de que se haya hecho.

Luego informa al propietario: cuántas sesiones se pueden cerrar de inmediato, cuántas después de una acción, qué no está en git, qué espera de él. En el primer informe, pregunta por las instrucciones específicas; de lo contrario, tendrás que preguntar por cada sesión:

• si cerrar las sesiones que han entregado trabajo a medida que lo entregan;
• si commiteear el trabajo entregado en su rama sin preguntar cada vez;
• si confirma que las tarjetas de las sesiones que se cierran no se ejecutan.

El formato de las preguntas está en la sección "Conversación con el propietario".

Paso 4. Remate de cabos sueltos

El orden es el siguiente para no perder nada: guardar → commiteear → (archivar sesión, paso 5) → fusionar → limpiar.

1. Guarda los materiales de las carpetas temporales en el proyecto: protocolos de verificación, capturas del estado "antes", ensayos. Colócalos junto al resultado. Si la carpeta de destino está en .gitignore (lo mostrará repo_state.py, línea "ignorado") — anótalo en "Qué no está en git": guardado en el proyecto no significa guardado en git.
2. Commitea lo listo — cada trabajo en su rama, solo por rutas explícitas. Antes del commit, revisa lo añadido para detectar claves, contraseñas y datos personales. Un archivo que contiene fragmentos de varias sesiones, divídelo por sesiones a través del índice, sin tocar el archivo de trabajo. Verifica el commit en un clon separado. Recetas — references/git-recipes.md.
3. Fusiona — con la palabra del propietario, registrando antes de la fusión el hash de la punta anterior. Ejecuta las pruebas sobre el resultado de la fusión, no sobre las ramas por separado: tres ramas, verdes individualmente, juntas pueden dar un fallo.
4. Elimina copias y ramas — solo después de verificar: en el historial de la rama principal están los commits de la rama con su trabajo; la copia está limpia; sus carpetas ignoradas con protocolos se han revisado; ninguna sesión abierta está trabajando en esa copia. git branch -d rechazará una rama sin fusionar, pero una rama sin commits propios, incluida la rama recién creada de una sesión activa, la eliminará sin previo aviso. No elimines ramas ni copias de sesiones de un proyecto vecino: anota "lo resuelve ese proyecto".
5. Despliega en el entorno de pruebas, si el propietario lo ha dicho, siguiendo las reglas del entorno (bloqueo, vecinos, verificación de vecinos antes y después).
6. Para producción, solo prepara. Script con plan, aplicación y reversión, verificado de forma independiente, y una línea en la lista de pendientes del propietario con el comando exacto. La versión anterior del paquete o script, que está donde el propietario ejecuta, es peligrosa: dile de inmediato al propietario "no ejecute la versión anterior" y, con su permiso, muévela a una subcarpeta "OBSOLETO — no ejecutar" con una nota. Si encuentras un defecto en un comando ya comunicado al propietario, escríbele como primera línea "no lo ejecutes hasta que te avise".
7. Corrige documentos y memoria. Versiones, puntas de ramas, "sin fusionar", "espera" — ajustarlos a los hechos. En la memoria, solo lo estable (reglas, trampas, dónde está qué); el estado del día, en los archivos del proyecto.
8. Los hallazgos, a la cola. Una entrada: qué, dónde, con qué se confirma, qué riesgo supone, qué se necesita para solucionarlo.

Mientras una sesión aún está abierta y modifica los mismos archivos, dile "espera" y espera su respuesta: la entrega no significa que el mensaje se haya leído. Después de tu commit, "el árbol está libre". Si estás verificando un paquete que la sesión podría recompilar, pídele que no lo toque y compara la suma de verificación antes y después de la verificación.

Paso 5. Cierre de sesiones

Una sesión que ha entregado su trabajo se archiva tan pronto como sus materiales se han guardado y el trabajo se ha commiteado en su rama; no espera a la fusión ni a la limpieza de copias. El archivo es reversible (unarchive_session), la eliminación no; usa el archivo.

Antes de archivar cada sesión:

• su copia de trabajo está limpia, las carpetas ignoradas con protocolos se han revisado. Según la descripción de la herramienta, el archivo por defecto elimina la copia de trabajo que la aplicación creó para la sesión; las copias que la sesión hizo ella misma mediante git worktree add permanecen — las eliminas tú (paso 4, punto 4);
• su carpeta temporal se ha revisado — márcalo en la tabla;
• en la cola del registro no hay promesas ni respuestas sin atender.

...

[truncado para la traducción]