aigengame/skills

State

Mantén STATE.md en la raíz del repositorio: un informe diario ligero entre sesiones para que el siguiente trabajador aprenda en ~15 líneas dónde está el proyecto, qué hizo la última sesión, qué experiencia inmediata reutilizar, qué abordar a continuación y qué elementos pendientes no deben olvidarse. Este es el bucle de retroalimentación que hace que la experiencia de desarrollo se acumule en lugar de redescubrir el estado del proyecto cada sesión.

STATE.md es transitorio ("dónde estamos ahora / qué sigue", se sobrescribe cada sesión) y autocontenido — no es el lugar para decisiones duraderas, arquitectura o un glosario, y no debe duplicarlos. Se crea perezosamente: si aún no existe, la primera ejecución lo crea.

Cuando el proyecto cuenta con una autoridad de planificación (un gestor de incidencias, hitos), esa autoridad define qué es el trabajo; no prescribe el orden y la forma de ejecución — las incidencias se ejecutan en paralelo, una incidencia abarca varias sesiones, el trabajo insertado se antepone al trabajo planificado. STATE.md es el informe del trabajador sobre la ejecución: resultados, más la orquestación actual del trabajo registrado (qué empezar a continuación, qué fue interrumpido y puesto en espera). Registra el estado de ejecución; nunca se convierte en una segunda autoridad de planificación.

Esta habilidad es autosuficiente y ortogonal a cualquier otra cosa que el proyecto utilice (control de versiones, un gestor de incidencias/tareas, documentos de diseño). Asume que dichas herramientas pueden existir pero no depende de ninguna en particular — lee las fuentes que tenga el proyecto, omite el resto.

Escribe con moderación — omite mejor que engañes. Cada viñeta de contenido en la plantilla es opcional. La fecha de actualización es obligatoria cada vez que se reescribe el archivo. Escribe una línea de contenido solo cuando sea precisa y útil para la próxima sesión. Si un valor falta, está desactualizado, no verificado o no es claramente útil, déjalo fuera. Una línea incorrecta o de relleno es peor que una ausente. El Backlog usa una regla de eliminación diferente; sigue el paso 4.

Cuándo ejecutarlo

• Al final de una sesión de trabajo / cierre — el tiempo de ejecución de tu agente puede sugerir esto mediante un gancho de fin de sesión, o lo ejecutas tú mismo.
• Bajo demanda, invoca el skill state usando la sintaxis explícita de habilidades del anfitrión.

El trabajador principal actualiza STATE.md una vez por sesión. Las subtareas paralelas y los subagentes no lo actualizan. Esta regla evita escrituras concurrentes o duplicadas.

Guardia de no operación: si la sesión no realizó trabajo material (por ejemplo, una ronda trivial de preguntas y respuestas), deja STATE.md sin cambios — como máximo actualiza la fecha. No generes cambios en el archivo sin progreso.

Flujo de trabajo

1. Recopila lo que esta sesión realmente completó o cambió. La fuente principal es la conversación actual. Si el proyecto tiene herramientas de apoyo, corrobora ligeramente (historial reciente de control de versiones, el gestor de incidencias/tareas) — trátalas como opcionales, no obligatorias.
2. Indica la fase macro solo si conoces la actual. No traslades la fase del STATE.md anterior por defecto — si puede haber avanzado, o no puedes confirmar la etapa actual en esta sesión, omite la línea en lugar de afirmar una desactualizada. (Una fase terminada escrita como si fuera actual es desinformación.) Usa los propios términos del proyecto.
3. Elige el próximo trabajo recomendado — los elementos abiertos con los que una nueva sesión debería comenzar, en orden de ejecución. Promociona elementos del Backlog aquí cuando sean el próximo inicio correcto.
4. Reconcilia el Backlog. Aplica este algoritmo a los elementos pendientes entre sesiones:
   • Hereda mediante filtrado. Comienza con el Backlog anterior y cualquier elemento de "Próximos" que no se haya ejecutado. Elimina un elemento solo cuando la evidencia muestre que está terminado, obsoleto, seleccionado para "Próximos" o registrado en el gestor de incidencias del proyecto. Una referencia del gestor es evidencia de que el elemento tiene un nuevo hogar. Verifica la conversación y corrobora con el gestor cuando exista uno. Mantén el elemento cuando su estado sea incierto.
   • Degrada el trabajo no terminado. Mueve el trabajo desplazado al Backlog solo cuando no esté seleccionado para "Próximos". El trabajo que debería reanudarse en la próxima sesión pertenece a "Próximos".
   • Estaciona el trabajo diferido. Agrega un elemento recién aceptado cuando esté diferido más allá de la próxima sesión y no tenga otro hogar.
   • Asigna cada elemento a un solo hogar. Ponlo en "Próximos" o en el Backlog, nunca en ambos.
   • Sella cada elemento del Backlog. Registra su fecha de entrada como desde YYYY-MM-DD.
   • Aplica el presupuesto de cinco elementos. Cuando el Backlog supere los cinco elementos, o un elemento sea claramente sustancial, mueve los elementos al gestor del proyecto del más antiguo al más reciente. Elimina un elemento solo después de que el gestor proporcione una referencia. Si no existe gestor, mantén todos los elementos. También mantén todos los elementos cuando ningún escritor autorizado pueda crear el registro en el gestor. El desbordamiento visible es la señal de que los elementos aún necesitan un hogar duradero.
5. Agrega experiencia solo si sirve para "Próximos". Incluye una nota solo cuando el trabajo de esta sesión sea continuo o esté relacionado con el trabajo recomendado para "Próximos", para que la nota realmente se reutilice. Si el próximo trabajo no está relacionado, omítela — la experiencia que no ayuda a la siguiente tarea es ruido, no un archivo de anécdotas de guerra. Cuando el proyecto tenga un PITFALLS.md, guarda allí la guía duradera sobre entorno, herramientas, permisos, sandbox e invocación de herramientas. STATE.md puede señalar una entrada relevante; no debe copiar esa entrada.
6. Reescribe STATE.md a partir de la plantilla. Sobrescribe el archivo; nunca añadas. Mantenlo en 15 líneas o menos. Si la regla de no pérdida en el paso 4 deja más de cinco elementos en el Backlog, permite una línea adicional por cada elemento extra. No elimines un elemento para cumplir con el límite de líneas. Omite viñetas de contenido que no sean precisas y útiles. Vuelve a emitir el Backlog filtrado como parte de la nueva instantánea. Sella la fecha actualizada.
7. No auto-confirmes (commit). Simplemente deja el STATE.md reescrito en el árbol de trabajo. Si está bajo control de versiones o se mantiene como una ayuda de trabajo solo local es elección del proyecto — esta habilidad nunca lo confirma.

Plantilla

# STATE — <proyecto>

_Informe diario entre sesiones (~15 líneas, reescrito cada sesión mediante el skill `state`). Las decisiones duraderas viven en otro lugar, no aquí._

- **Fase/hito:** <etapa actual, en los propios términos del proyecto — omite si no puedes confirmar la *actual*>
- **Última sesión:** <lo que se completó/cambió; una línea, ej. incidencia #N>
- **Experiencia:** <experiencia transitoria que ayude a "Próximos", o un enlace a una entrada relevante de `PITFALLS.md`; de lo contrario, omite>
- **Próximos:** <elementos recomendados para EMPEZAR a continuación, en orden de ejecución, ej. incidencia #N>
- **Backlog:** <elementos pendientes entre sesiones NO seleccionados para "Próximos"; una línea por elemento>
  - <elemento interrumpido o en espera, anclado a una referencia del gestor (#N) cuando exista> _(desde YYYY-MM-DD)_
  - <elemento aún no en el gestor — promuévelo allí del más antiguo al más reciente cuando la lista se desborde> _(desde YYYY-MM-DD)_

_Actualizado: <YYYY-MM-DD>_

(Toda viñeta de contenido es opcional. _Actualizado es obligatorio cada vez que se reescribe el archivo.)

Salvaguardas

• Sigue el paso 4 para cada cambio en el Backlog. Nunca elimines trabajo no terminado para cumplir con un presupuesto.
• Sigue el paso 6 para reescribir y los límites de líneas. STATE.md es una instantánea actual, no un registro histórico.
• Registra solo el delta de esta sesión. El Backlog es el único campo que traslada el estado filtrado hacia adelante.
• Mantén el archivo autocontenido. No dupliques decisiones duraderas ni dependas de un gestor o herramienta específica.
• Usa el vocabulario establecido del proyecto.