Flujo de Trabajo de Sesión Autónoma

¿Qué hace Flujo de Trabajo de Sesión Autónoma?

Estructura repetible de 5 fases para sesiones de agentes autónomos que previene el trabajo duplicado, garantiza la captura duradera del aprendizaje y orienta el resultado hacia artefactos significativos entregados, no hacia movimiento.

Probado en miles de sesiones autónomas en la arquitectura gptme. Las fases son independientes del runtime: adapta las herramientas específicas a tu stack manteniendo la estructura de fases intacta.

Cuándo Usarlo

• Al inicio de cada sesión de agente autónomo (sin humano en vivo dirigiendo el trabajo)
• Cuando el agente debe seleccionar su propio trabajo de un backlog o cola
• Cuando las sesiones se ejecutan sin supervisión y necesitan producir artefactos duraderos

Cuándo No Usarlo

• Sesiones interactivas donde un humano proporciona el siguiente prompt en cada turno: solo responde
• Invocaciones de herramientas únicas con un objetivo fijo (no se necesita selección)
• Llamadas a subagentes generadas desde una tarea padre (el padre ya seleccionó el trabajo)

Las 5 Fases

Fase 1: Carga de Contexto

Carga la identidad del agente, el estado de la sesión y el modelo del mundo actual.

# Leer archivos de identidad: persona, objetivos, restricciones operativas
# (adaptar a tu stack: CLAUDE.md, AGENTS.md, prompt del sistema, etc.)

# Leer contexto dinámico: diario reciente, cola de tareas, estado de git, notificaciones
# (adaptar: un script de contexto, inclusión impulsada por configuración o inyección de prompt)

# Evaluar cabos sueltos de sesiones anteriores:
#   - Reclamos obsoletos que deberían completarse o abandonarse
#   - Respuestas pendientes en issues/PRs que prometiste cerrar
#   - Ramas en progreso o worktrees abiertos

Pregunta clave: "¿Qué dejé sin terminar y qué cambió mientras estaba desconectado?"

Si un cabo suelto se puede resolver en <5 minutos, manéjalo aquí. Si no, anótalo y continúa.

Fase 2: Selección de Trabajo

Prueba los niveles en orden hasta que encuentres trabajo accionable. Los niveles evitan que el agente invente tareas de relleno cuando existen tareas reales, y previenen la inanición cuando todas las tareas están bloqueadas.

Nivel 1 — Tareas activas: trabajo ya en progreso; máxima prioridad
Nivel 2 — Ganancias rápidas del backlog: elementos listos para dependencias que puedes completar esta sesión
Nivel 3 — Auto-mejora: cuando todas las tareas están externamente bloqueadas
  ├─ Backlog de ideas (avanzar la idea con mayor puntuación)
  ├─ Autorevisión / auditoría (encontrar y corregir un problema real)
  ├─ Mejora de herramientas internas
  ├─ Documentación (solo documentación desactualizada)
  ├─ Calidad de código (typecheck, tests, lint)
  └─ Calidad de lecciones (reparar lecciones dañadas u obsoletas)

Protección contra monotonía: Si la misma categoría ha dominado las últimas N sesiones, sáltala incluso si parece la mejor opción. La diversidad de categorías es una función forzada para aprender nuevos modos de fallo.

Cuando todo está seco: Si todas las tareas de Nivel 1/2 están bloqueadas externamente y los carriles de Nivel 3 están saturados (límites diarios alcanzados), escribe un breve diario de contención registrando lo que verificaste y omitiste deliberadamente. Un NOOP justificado es mejor que inventar trabajo.

Fase 3: Reclamo

Antes de ejecutar, adquiere un reclamo de coordinación exclusivo. Esto evita que dos sesiones concurrentes ejecuten el mismo trabajo, inunden el mismo hilo de PR o escriban el mismo archivo.

# Patrón de coordinación genérico: adapta la herramienta a tu stack:
claim_key="task:<task-id>"          # para trabajo basado en tareas
claim_key="github:<owner>/<repo>#<num>"  # para trabajo basado en issues
claim_key="content:<slug>:<date>"   # para creación de contenido/artefacto

# Adquirir reclamo (ejemplo usando un CLI de coordinación):
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# RECLAMADO → continuar
# DENEGADO  → otra sesión ya está en ello; elegir el siguiente candidato

Regla de notificar-antes-de-reclamar: Cualquier acción visible para otros (publicar un comentario, enviar un mensaje, abrir un PR) debe estar precedida por un reclamo. Las acciones sociales sin reclamos convergen y generan spam; el patrón de reclamar-y-luego-publicar previene inundaciones.

Al completar: coordination work-complete "<session-id>" "$claim_key" Al pivotar/fallar: coordination work-abandon "<session-id>" "$claim_key"

Fase 4: Ejecutar

Haz trabajo real. La disciplina clave es entregar, no perfeccionar.

- Haz commit temprano y a menudo (commits pequeños y bien descritos)
- Ejecuta pruebas antes de hacer commit (detecta problemas antes de que CI lo haga)
- Usa commits convencionales: feat/fix/docs/refactor/chore
- Haz push al remoto antes de que termine la sesión
- Si te atascas por más de 10 minutos, sigue adelante: no hundas el presupuesto en un agujero de conejo
- No agregues funciones no solicitadas ni ampliaciones del alcance

Presupuesto de 50 minutos: La mayoría de las sesiones autónomas deberían completar trabajo significativo en 50 minutos. Si la tarea es más grande, entrega un fragmento incremental y crea una tarea de seguimiento para el resto.

Fase 5: Persistir

La fase más infravalorada. Todo lo hecho en las Fases 1–4 se evapora entre sesiones a menos que se registre de forma duradera.

# 1. Escribe la entrada del diario (archivo específico de la sesión, solo añadir)
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# Sesión <HASH>
**Fecha**: YYYY-MM-DD
**Resultado**: productiva|bloqueada|noop — una frase
**Categoría**: código|investigación|estratégico|mantenimiento|...

## Por qué este trabajo
[Qué llevó hasta aquí]

## Lo que hice
[Cambios concretos con enlaces a commits/PRs]

## Verificación
- [¿Pruebas pasando? ¿CI verde?]

## Aprendizaje Persistido
- Estado de la tarea: <tarea> → hecha/en espera
- Nuevas lecciones: [si las hay]
- "Sin feedback duradero en esta sesión" — si genuinamente no hay nada que añadir

## Siguiente
[Próxima acción clara o factor bloqueante]
EOF

# 2. Actualiza el estado de la tarea
task edit <task-id> --set state done   # o waiting, si está bloqueada

# 3. Si se descubrió un patrón de fallo recurrente, escribe una lección/regla
#    (archivo de contexto coincidente por palabra clave inyectado al inicio de la próxima sesión)

# 4. Haz push de todos los commits
git push origin master

Regla de persistir primero: Si descubriste algo útil, escribe la lección ANTES de aplicarla al trabajo actual. Una vez que la corrección está hecha, el modo de fallo se siente resuelto y la lección se omite. El diario captura lo que sucedió; la lección captura cuándo reconocerlo de nuevo.

Instalación

Claude Code

Copia este directorio de skill en la carpeta de skills de tu agente:

cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow

Luego invoca con /autonomous-session-workflow para cargar la lista de verificación de 5 fases en el contexto.

Manual / cualquier runtime

Copia SKILL.md en la ruta de contexto de tu agente y cárgalo al inicio de la sesión. Las fases son markdown plano: incluye todo el archivo o selecciona las secciones relevantes para tu stack.

Racionalizaciones Comunes

Racionalización	Realidad
"Me saltaré el reclamo; soy la única sesión ejecutándose ahora"	No puedes ver otras sesiones iniciándose. La generación concurrente es el valor predeterminado en runtimes de producción. El reclamo es la puerta, no la observación.
"Escribiré el diario después de terminar la próxima tarea"	Las sesiones se interrumpen. El diario se salta. Escríbelo antes de hacer push, no después de "una cosa más".
"Esta tarea está casi terminada; me saltaré la Fase 5 y solo haré commit"	El aprendizaje solo se acumula si se persiste. La sesión que "casi" cerró el ciclo es la sesión cuya percepción desaparece para la próxima ejecución.
"Mi selección es obvia; no necesito recorrer los niveles"	La selección que se salta los niveles es la fuente principal de trabajo redundante y PRs duplicados. Los niveles existen porque lo "obvio" a menudo no es lo que realmente necesita hacerse.
"La lección es demasiado específica para ser reutilizable"	Las lecciones específicas (mensaje de error exacto, comando exacto, modo de fallo exacto) son las más valiosas: se activan precisamente cuando se necesitan.
"Un NOOP justificado se siente como un fracaso"	No lo es. Un commit de relleno para esquivar la etiqueta de NOOP quema presupuesto, alimenta la rotación de convergencia y oculta el atasco. Un diario de contención ES el entregable.

Señales de Alerta

• Comenzar la ejecución antes de reclamar (riesgo de convergencia)
• La sesión termina sin diario ni estado de tarea actualizado
• Hacer commit "en un momento" — si no has hecho push antes de terminar, no has entregado
• Tres sesiones consecutivas en la misma categoría sin una pausa forzada de diversidad
• "Lo recordaré" — no lo harás; escribe la lección ahora

Verificación

Una sesión bien ejecutada cumple todo lo siguiente antes de cerrar:

• Reclamado antes de actuar (o justificado por qué no se necesitaba reclamo)
• Trabajo significativo con commit y push realizados
• Pruebas pasadas (o fallo conocido documentado con motivo)
• Entrada de diario escrita con la sección Aprendizaje Persistido completada
• Estado de la tarea actualizado (activo → hecho, activo → en espera, etc.)
• Reclamo completado o abandonado (no dejado como concesión caducada)

Adaptación a tu Stack

concepto gptme	Tu equivalente
gptodo	cualquier gestor de tareas con transiciones de estado
coordination work-claim	un archivo de bloqueo, Redis SETNX o puerta de comentarios de GitHub
lessons/<category>/name.md	cualquier archivo de contexto coincidente por palabra clave inyectado al inicio de la sesión
journal/<date>/session-<hash>.md	cualquier registro de sesión de solo añadir
cascade-selector.py	tu heurística o planificador de selección de trabajo

El patrón es el valor, no las herramientas específicas.

Relacionados

• self-push (en este catálogo) — verificación rápida antes de enviar cualquier salida
• pre-landing-review (en este catálogo) — puerta antes de fusionar cambios significativos
• multi-lens-review (en este catálogo) — revisión estructurada de PRs a través de múltiples lentes
• five-element-spec (en este catálogo) — definición de alcance antes de comenzar el trabajo