ZDEV-XXR/hacer-videos-con-Remotion

Implementa tareas a partir de un cambio de OpenSpec.

Selección del almacén: Si el usuario nombra un almacén (un almacén es un repositorio OpenSpec independiente registrado en esta máquina) o el trabajo vive en uno, ejecuta openspec store list --json para descubrir los IDs de los almacenes registrados, luego pasa --store <id> en los comandos que leen o escriben especificaciones y cambios (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Una vez seleccionado, trata --store <id> como persistente para el resto del flujo de trabajo. Cada ejemplo no especificado de esos comandos a continuación es una abreviatura: antes de ejecutarlo, añade la bandera. Por ejemplo, ejecuta openspec status --change "<nombre>" --json --store "<id>", no la forma no especificada que se muestra a continuación. Otros comandos no toman la bandera. Las sugerencias impresas por los comandos ya llevan la bandera; mantenla en los seguimientos. Sin un almacén, los comandos actúan sobre la raíz local openspec/ más cercana.

Verificación del proyecto: Estos pasos esperan un proyecto que ya use OpenSpec. Antes del primer paso que escriba algo (new change, archive, sync specs o la creación de un archivo de artefacto), confirma que el proyecto tenga una raíz: ejecuta openspec list --json (con --store <id> cuando se haya seleccionado un almacén, ya que el almacén es entonces la raíz) y lee root. Un objeto raíz significa que el proyecto está configurado. "root": null significa que no lo está; no hay un directorio openspec/ aquí, y una escritura como openspec new change lo crearía como efecto secundario. El comando también sale con un código distinto de cero, que es esa respuesta en lugar de una CLI rota, así que lee el JSON en lugar de reintentar o evitar el problema.

Un caso de "root": null no se trata de configuración: cuando un mensaje de error de status comienza con Declared in o Invalid store declaration in y nombra el openspec/config.yaml (o config.yml) de este proyecto, el proyecto sí usa OpenSpec a través de un almacén que declara, pero esta máquina no puede resolverlo (el almacén no está registrado, o la línea store: tiene un formato incorrecto). No lo trates como no inicializado y omitas las ramas a continuación: detente antes de escribir y muestra al usuario el message y fix de ese error.

De lo contrario, sin raíz, lo que sucede a continuación depende de cómo se llegó a este flujo de trabajo:

• Seleccionado automáticamente: elegiste este flujo de trabajo tú mismo, sin que el usuario nombre OpenSpec, nombre este skill o ejecute su comando de barra. Deja de usar OpenSpec y responde la solicitud normalmente, como lo harías sin OpenSpec instalado. No le pidas que configure nada ni menciones la configuración de OpenSpec.
• Solicitud explícita de OpenSpec: el usuario nombró OpenSpec, nombró este skill o ejecutó su comando de barra. Detente antes de escribir y pregunta cómo proceder: configurar este proyecto (openspec init), apuntar a un almacén que ya tengan (--store <id>), o continuar sin OpenSpec para esta solicitud. Espera su respuesta.

En ambas ramas, nunca crees la raíz como efecto secundario: no ejecutes openspec init hasta que el usuario lo solicite, no crees archivos openspec/ manualmente y no permitas que un comando la cree.

Entrada: Opcionalmente especifica un nombre de cambio (ej., /openspec-apply-change add-auth). Si se omite, verifica si se puede inferir del contexto de la conversación. Si es vago o ambiguo, DEBES solicitar los cambios disponibles.

Pasos

1. Seleccionar el cambio

   Si se proporciona un nombre, úsalo. De lo contrario:

   • Inferir del contexto de la conversación si el usuario mencionó un cambio
   • Seleccionar automáticamente si solo existe un cambio activo
   • Si es ambiguo, ejecuta openspec list --json para obtener los cambios disponibles y pide al usuario que seleccione uno

   Siempre anuncia: "Usando cambio: " y cómo anularlo (ej., /openspec-apply-change <otro>).

2. Verificar el estado para entender el esquema

   openspec status --change "<nombre>" --json
   

   Analiza el JSON para entender:

   • schemaName: El flujo de trabajo que se está usando (ej., "spec-driven")
   • planningHome, changeRoot y actionContext: alcance de la planificación y restricciones de edición
   • Qué artefacto contiene las tareas (típicamente "tasks" para spec-driven, verifica el estado para otros)

3. Obtener las instrucciones de aplicación

   openspec instructions apply --change "<nombre>" --json
   

   Esto devuelve:

   • contextFiles: ID del artefacto -> matriz de rutas de archivo concretas (varía según el esquema: podría ser propuesta/especificaciones/diseño/tareas o especificación/pruebas/implementación/documentación)
   • Progreso (total, completo, restante)
   • Lista de tareas con estado, ruta de origen y línea de origen
   • Instrucción dinámica basada en el estado actual
   • context opcional: entrada de instrucción de proyecto requerida actual de la raíz seleccionada
   • operationGuidance opcional: guía asesora actual para la aplicación
   • missingArtifacts (cuando está presente): IDs de artefactos requeridos sin salida

   Manejar estados:

   • Si state: "blocked": muestra el mensaje y pausa la implementación.
     • Si missingArtifacts no está vacío: sugiere completar los artefactos faltantes. Ejecuta openspec status --change "<nombre>" --json, selecciona el siguiente artefacto ready (no skipped ni blocked), y usa openspec instructions "<artifact-id>" --change "<nombre>" --json para sus reglas y plantilla. Mantén el --store <id> seleccionado en ambos comandos.
     • De lo contrario, sigue la instrucción de la CLI para crear o reparar el archivo de seguimiento configurado por el esquema a partir de los artefactos de planificación existentes. No asumas que otro artefacto está listo ni comiences la implementación mientras esté bloqueado.
   • Si state: "all_done": informa que todas las tareas rastreadas están completas y sugiere revisión o verificación según corresponda antes de archivar
   • De lo contrario: procede con la implementación

   Trata context como una entrada de nivel de indicación requerida. Léelo y considéralo, y aplica hechos, convenciones y restricciones relevantes del proyecto durante la implementación. Trata operationGuidance como un consejo aditivo opcional. Lee y considera cada entrada, y sigue las entradas que sean aplicables y compatibles con el flujo de trabajo incorporado.

   Mantén ambos campos separados del estado devuelto por la CLI, artefactos faltantes, tareas, progreso, contextFiles y la instruction incorporada. No son evidencia de finalización de tareas, no reemplazan la instrucción incorporada y no permiten eludir un estado bloqueado. Si el contexto entra en conflicto con la instrucción incorporada, una elección explícita del usuario o un valor controlado por la CLI, informa el conflicto y preserva el valor controlador. Si la guía no es aplicable o entra en conflicto con esas entradas controladoras, no la sigas y explica por qué. Estos son contratos de comportamiento a nivel de indicación, no comprobaciones ejecutables.

4. Leer los archivos de contexto

   Lee cada ruta de archivo listada bajo contextFiles de la salida de las instrucciones de aplicación. Los archivos dependen del esquema que se esté usando:

   • spec-driven: propuesta, especificaciones, diseño, tareas
   • Otros esquemas: sigue los contextFiles de la salida de la CLI

   No copies context ni operationGuidance textualmente en archivos de implementación o artefactos de planificación a menos que el usuario lo solicite por separado.

5. Mostrar el progreso actual

   Muestra:

   • Esquema que se está usando
   • Progreso: "N/M tareas completadas"
   • Resumen de tareas restantes
   • Instrucción dinámica de la CLI

6. Implementar tareas (bucle hasta terminar o bloquearse)

   Para cada tarea pendiente:

   • Muestra en qué tarea se está trabajando
   • Realiza los cambios de código requeridos
   • Mantén los cambios mínimos y enfocados
   • Antes de editar, confirma que la casilla de verificación en la sourcePath y line devueltas aún coincida con la descripción de la tarea; si no es así, vuelve a ejecutar las instrucciones de aplicación y usa la ubicación actualizada
   • Marca la tarea como completada en su sourcePath y line devueltas: - [ ] → - [x]
   • Vuelve a ejecutar las instrucciones de aplicación y confirma que esa tarea ahora está hecha y el progreso cambió
   • Continúa con la siguiente tarea

   Pausar si:

   • La tarea no está clara → pide aclaración
   • La implementación revela un problema de diseño → sugiere actualizar los artefactos
   • Una tarea necesita trabajo más allá de lo que describen la especificación y las tareas, o te sientes tentado a omitir, reducir, aplazar o aceptar excepciones al comportamiento especificado para que encaje → expón el alcance añadido y pregunta; no lo absorbas en silencio
   • Error o bloqueador encontrado → informa y espera orientación
   • El usuario interrumpe

7. Al completar o pausar, muestra el estado

   Muestra:

   • Tareas completadas en esta sesión
   • Progreso general: "N/M tareas completadas"
   • Si todo está hecho: informa que las tareas rastreadas están completas y sugiere revisión o verificación según corresponda antes de archivar
   • Si está en pausa: explica por qué y espera orientación

Salida durante la implementación

## Implementando: <nombre-del-cambio> (esquema: <nombre-del-esquema>)

Trabajando en tarea 3/7: <descripción de la tarea>
[...implementación en curso...]
✓ Tarea completada

Trabajando en tarea 4/7: <descripción de la tarea>
[...implementación en curso...]
✓ Tarea completada

Salida al completar

## Implementación Completada

**Cambio:** <nombre-del-cambio>
**Esquema:** <nombre-del-esquema>
**Progreso:** 7/7 tareas completadas ✓

### Completado en Esta Sesión
- [x] Tarea 1
- [x] Tarea 2
...

Todas las tareas rastreadas están completas. Revisa o verifica el cambio según corresponda
antes de archivar. Puedes archivar este cambio con `/openspec-archive-change`.

Salida al pausar (problema encontrado)

## Implementación en Pausa

**Cambio:** <nombre-del-cambio>
**Esquema:** <nombre-del-esquema>
**Progreso:** 4/7 tareas completadas

### Problema Encontrado
<descripción del problema>

**Opciones:**
1. <opción 1>
2. <opción 2>
3. Otro enfoque

¿Qué te gustaría hacer?

Guardas

• Continúa con las tareas hasta que estén hechas o bloqueadas
• Siempre lee los archivos de contexto antes de comenzar (de la salida de las instrucciones de aplicación)
• Si la tarea es ambigua, pausa y pregunta antes de implementar
• Si la implementación revela problemas, pausa y sugiere actualizaciones de artefactos
• Mantén los cambios de código mínimos y limitados a cada tarea
• Actualiza la casilla de verificación de la tarea inmediatamente después de completar cada tarea
• Pausa ante errores, bloqueadores o requisitos poco claros; no adivines
• Cuando una tarea necesita trabajo más allá de lo que describe la especificación, expón el alcance añadido y pausa; nunca reduzcas, aplaces ni simplifiques en silencio el comportamiento especificado
• Solo marca una tarea - [x] cuando su comportamiento especificado esté completamente implementado, no cuando esté parcialmente hecho o aplazado
• Usa contextFiles de la salida de la CLI, no asumas nombres de archivo específicos
• Usa sourcePath y line de cada tarea para actualizar su casilla exacta
• No uses el contexto ni la guía de operación como prueba de que una tarea está completa
• Aplica el contexto relevante del proyecto; informa conflictos con las entradas controladoras del flujo de trabajo
• Considera cada entrada de guía; explica cualquier consejo no aplicable o conflictivo
• No copies el contexto de ejecución ni la guía de operación en archivos de implementación o artefactos de planificación
• Preserva el comportamiento bloqueado/listo/completado controlado por la CLI y los criterios de finalización

Integración de Flujo de Trabajo Fluido

Este skill admite el modelo de "acciones sobre un cambio":

• Se puede invocar en cualquier momento: antes de que todos los artefactos estén hechos (si existen tareas), después de la implementación parcial, intercalado con otras acciones
• Permite actualizaciones de artefactos: si la implementación revela problemas de diseño, sugiere actualizar los artefactos, sin bloqueo de fase, trabajo fluido