Save Status

Skill: Save Status

Cuándo usar

• Cuando el usuario escribe /save-status o save status
• Antes de cerrar una sesión productiva (al detectar frases como "ya nos vamos", "hasta mañana", "por hoy es suficiente", "cierro la sesión")
• Cuando el usuario dice "guarda el estado", "actualiza el status", "checkpoint", "antes de cerrar"
• En medio de una sesión larga si el usuario quiere preservar el progreso (por ejemplo, cuando la ventana de contexto ya va muy avanzada)

Qué hace

Actualiza (o crea si no existe) el archivo .claude/memory/SESSION-STATUS.md del proyecto en el que se está trabajando, con un resumen completo y estructurado de la sesión en curso.

Esto permite que la siguiente sesión pueda retomar exactamente donde se quedó la actual, sin perder contexto, decisiones, ni pendientes. Se acabó el explicarle a la IA en cada sesión nueva cosas que ya habían trabajado juntos.

Proceso

Paso 1: Detectar el proyecto actual

Identificar el directorio del proyecto en el que se trabajó durante la sesión (la carpeta raíz del repo o subproyecto activo).

El archivo objetivo es: <proyecto>/.claude/memory/SESSION-STATUS.md

Paso 2: Leer el SESSION-STATUS existente (si existe)

Si ya existe, leerlo completo para entender el estado previo. La actualización debe:

• Mantener información histórica relevante
• Actualizar el estado actual con lo trabajado en esta sesión
• Mover los pendientes completados a "Lo que se construyó"
• Dejar los pendientes nuevos en "Pendientes inmediatos"

Paso 3: Recopilar el contexto de la sesión actual

Revisar la conversación completa para extraer:

• Cambios concretos al código (qué archivos se tocaron, qué se construyó)
• Decisiones técnicas tomadas (con su porqué)
• Bugs resueltos y cómo se resolvieron
• Pendientes nuevos que quedaron al aire
• URLs, comandos y rutas relevantes (nunca secretos — ver Reglas)
• Aprendizajes grabados durante la sesión

Paso 3-BIS: CHECKLIST OBLIGATORIO de captura (si tu proyecto es para un cliente)

Antes de escribir el SESSION-STATUS, revisar explícitamente cada uno de estos puntos. Si alguno aplica y no se captura, la próxima sesión arrancará ciega:

1. Archivos nuevos recibidos del cliente durante la sesión. Revisar las carpetas de documentos y trabajo compartido. Listar cada archivo nuevo con: nombre, qué contiene, dónde se movió. Ejemplos: transcripciones de reuniones, catálogos, PDFs, imágenes compartidas.

2. Documentos compartidos CON el cliente pendientes de respuesta. PDFs, formularios, preguntas enviadas por WhatsApp o email. Listar cada uno con: nombre, fecha de envío, a quién, estado (pendiente / parcialmente contestado / contestado).

3. Preguntas abiertas con el cliente. Cualquier cosa que se le preguntó y no contestó todavía, y cualquier cosa que descubrimos en la sesión que hay que preguntarle próximamente.

4. Conflictos de datos / decisiones pendientes de confirmar con el cliente. Campos duplicados, valores default sin calibrar, decisiones de arquitectura que requieren confirmación antes de aplicarse. Cada uno con: qué está en conflicto, por qué, quién lo tiene que confirmar, impacto si se ignora.

5. Memorias o documentos nuevos creados en esta sesión dentro de .claude/memory/ del proyecto.

Paso 3-TER: DETECCIÓN DE DRIFT (OBLIGATORIO) — el doc vs el estado real del código

Antes de escribir la nueva versión, hacer un sweep para detectar drift entre lo que el SESSION-STATUS afirma como "pendiente" y lo que ya está en master.

Por qué es obligatorio (lección aprendida por las malas): un SESSION-STATUS que dice "feature X pendiente" cuando X lleva días en producción es PEOR que no tener SESSION-STATUS — empuja a la IA a tomar decisiones equivocadas. En un caso real, esa información desactualizada contaminó el knowledge-base de un asistente de IA, y el asistente le inventó funcionalidades inexistentes al usuario final. El código es la única fuente de verdad; el doc es solo su resumen.

Sweep concreto a ejecutar:

1. Listar cada feature / fase / item marcado como "pendiente" en el SESSION-STATUS actual.
2. Por cada uno, hacer git log --all --oneline filtrando por el nombre del item para verificar si hay commits relacionados ya mergeados a master.
3. Si los hay, hacer Grep al código de los archivos que ese item debía modificar, para confirmar que la feature está en master (no solo el commit).
4. Cualquier item que ya esté hecho: moverlo a "Lo que se construyó" con la fecha correcta y marcarlo ✅. NO dejarlo en "pendiente".
5. Listar al inicio del SESSION-STATUS los items que se movieron en este sweep, para que la próxima sesión no los siga tratando como pendientes.

Output adicional: si se detecta que un README, BUSINESS_LOGIC o knowledge-base de un asistente IA quedó desactualizado respecto al código, levantar bandera al usuario y anotarlo como pendiente.

Paso 4: Generar / actualizar el archivo

Usar la siguiente estructura como referencia. Si el archivo ya existe, MERGEAR con lo nuevo (no sobreescribir todo).

# SESSION-STATUS — [Nombre del proyecto]

**Última actualización:** [Fecha YYYY-MM-DD]
**Owner:** [Nombre]
**Tipo de proyecto:** [MVP / Producción / Personal / etc.]

---

## Pendientes con el cliente (si aplica — SIEMPRE AL INICIO, leer primero)

### Documentos pendientes de respuesta
- [Nombre del doc] — enviado [fecha] — estado: [pendiente / parcial / respondido]

### Archivos recibidos del cliente
- [Nombre archivo] — recibido [fecha] — ubicación [ruta] — contenido [resumen breve]

### Preguntas abiertas
- [Pregunta — contexto — por qué importa responderla]

---

## Contexto crítico

[Información clave que la IA debe saber siempre: terminología obligatoria,
decisiones de negocio que afectan el código, qué NO incluir en documentos, etc.]

---

## Estado actual del proyecto

### Deployment
- Producción: [URL]
- Repo: [URL]
- Dev local: [puerto, comando]
- Estado: [funcionando / en desarrollo / con issues]

### Base de datos / Servicios externos
| Tabla / Servicio | Estado | Notas |
|------------------|--------|-------|
| ... | ... | ... |

### Credenciales relevantes
- [DÓNDE están las llaves (ej. ".env.local"), sin exponerlas en este archivo]

---

## Lo que se construyó en sesiones recientes

### [Fecha de la sesión más reciente]
- [Cambio 1]
- [Cambio 2]

---

## Pendientes inmediatos

### Pendiente #1: [Título]
- [Descripción clara]
- [Qué se necesita para resolverlo]
- [Dónde quedamos exactamente]

---

## Decisiones técnicas clave

- [Decisión 1 + porqué]

---

## Aprendizajes / Reglas grabadas

- [Regla 1 — qué se aprendió y por qué]

---

## Cómo retomar esta sesión

1. [Primer paso al abrir nueva sesión]
2. [Verificar que el dev server esté corriendo]
3. [Continuar con Pendiente #1]

Paso 5: Confirmar al usuario

Después de guardar el archivo, mostrar un resumen breve:

• Qué se actualizó (cambios principales)
• Cuáles son los pendientes inmediatos
• Cómo retomar la siguiente sesión

Cómo retomar en la siguiente sesión (la otra mitad del truco)

Al abrir una conversación nueva, solo di: "Vamos a trabajar en [proyecto], lee primero .claude/memory/SESSION-STATUS.md". La IA carga el objetivo, lo que ya está listo, lo que falta y el punto exacto donde se quedaron — y siguen trabajando como si la sesión nunca se hubiera cortado.

Tip: si quieres que sea automático, agrega a tu CLAUDE.md una instrucción tipo: "Cuando te indique en qué proyecto vamos a trabajar, lee completo su .claude/memory/SESSION-STATUS.md antes de cualquier otra acción."

Reglas

• NUNCA exponer secretos en el SESSION-STATUS. Referenciar dónde están las llaves (ej: ".env.local") sin pegarlas.
• MERGEAR con lo existente — no borrar contexto histórico relevante.
• SER ESPECÍFICO — pendientes vagos como "terminar feature" no sirven. Especificar qué falta exactamente.
• INCLUIR COMANDOS — paths, comandos de terminal, puertos: todo lo que necesita la siguiente sesión para arrancar sin fricción.
• TONO TÉCNICO — el SESSION-STATUS lo lee otro agente, no un humano. Ser preciso y denso en información.

Ejemplo de invocación

Usuario: /save-status

Agente:

1. Detecta el proyecto actual
2. Lee SESSION-STATUS.md existente (si hay)
3. Recopila el contexto de la conversación
4. Corre el sweep anti-drift contra git y el código
5. Escribe el archivo
6. Confirma al usuario con un resumen de los cambios