ouxxyy/codex-gif-video

Codex GIF Video

Propósito y selección de salida

Este Skill está diseñado exclusivamente para crear material visual listo para edición posterior. No añade subtítulos, títulos, etiquetas de texto, marcas de agua, música, voces ni efectos de sonido. El texto de locución se usa únicamente para comprender la acción y dividir las tomas; no se convierte en subtítulos ni audio. Los requisitos de sonido, subtítulos o producción de largometrajes presentes en las referencias de estilo upstream no son instrucciones ejecutables para este Skill.

El usuario puede elegir:

• GIF cortos originales: cada toma conserva los bytes originales devueltos por el servicio y su lista de fuentes.
• Un GIF largo: concatena varias tomas aprobadas en orden cronológico en un único archivo .gif; sin bucle, una sola reproducción completa.
• Formato de video: guarda como .mp4 (H.264/yuv420p), solo stream de video, mudo, sin subtítulos.
• Ambos formatos: reutiliza las mismas tomas para exportar tanto el GIF largo como el MP4, sin regenerar las tomas.

Se respeta la elección explícita del usuario; si dice "haz un GIF", se entrega GIF; si dice "formato de video", se entrega MP4. Si no se especifica, por defecto se generan GIF y se menciona la opción MP4. Cuando la duración objetivo excede la capacidad de una sola toma, primero se divide en varias tomas y luego se exporta un único archivo largo; no se pueden entregar fragmentos sueltos. Ver flujo de exportación.

Límites de generación y punto de entrada

La fuente de imágenes dinámicas acepta únicamente GIF devueltos de forma nativa por el modelo. Se utiliza la herramienta nativa de la sesión actual de Codex, o la API oficial de OpenAI Image ya seleccionada por el usuario; no se usan proxies de terceros, otros modelos de imagen/video, fotogramas estáticos encadenados, animaciones de código, I2V ni interpolación para suplantar animaciones nativas. Se conservan el GIF original y la evidencia de cada solicitud; no se altera la velocidad, se repite el bucle ni se añaden fotogramas estáticos para alargar la duración.

La concatenación de GIF largos, la codificación MP4 y el escalado proporcional son exportaciones derivadas, no pueden denominarse generación nativa única del modelo ni añaden fotogramas de movimiento real. La recodificación de GIF puede provocar cambios en la paleta; se prioriza mantener las dimensiones originales. Para contenido largo se puede optar por MP4 para reducir tamaño.

Prioridad de entrada: instrucción explícita de la ronda actual → preferred_entry del archivo privado del proyecto codex-gif-video.config.json → sesión de Codex. Se mantiene la selección guardada previamente; si falla la entrada nativa, no se cambia automáticamente a una API de pago. Las rutas credential_file y budget_file son relativas a la raíz del proyecto; las claves no se incluyen en el Skill, prompts ni logs.

Para la API oficial, primero leer official-api.md y usar official_api.py; se omite la verificación del interruptor GIF de Codex. Para el modo Codex, ejecutar primero native_gif.py doctor y comprobar el esquema real de herramientas de esta sesión: debe tener un campo gif; no se envían sondeos estáticos solo de prompt, ni se inventan parámetros. Diagnóstico en native-entry.md. La capacidad del modelo y de GIF está limitada por la cuenta y el alcance del servicio.

El mismo lote de autorización comparte presupuesto. Por defecto, máximo 8 solicitudes de GIF y 3 solicitudes de referencia; los fallos y tiempos de espera también cuentan. Las tareas nuevas o las repeticiones explícitas pueden crear un libro de contabilidad independiente, registrando la cantidad planificada y conservando el libro anterior. No se puede borrar el saldo para evitar fallos; los nuevos intentos deben ser explícitos y los cambios en prompts, parámetros o referencias deben crear un nuevo bundle.

De la necesidad a la toma

1. Leer protocolo de llamada, dividir el objetivo en shots, cada toma debe tener claro: "estado inicial → acción → estado final". La locución se conserva textualmente; no se inventan marcas de tiempo de audio; para fragmentos repetidos, proporcionar la posición de los caracteres.
2. Determinar el formato de salida, la relación de aspecto y la duración total. prepare convierte la relación a píxeles: por defecto 9:16 → 288×512, 16:9 → 512×288, 1:1 → 512×512; estos son valores conservadores locales, no el límite del servicio. Se pueden especificar dimensiones explícitas que cumplan con múltiplos de 16 y los límites de píxeles del servicio.
3. Duración precisa por defecto. Si se omite frame_count, se selecciona automáticamente un esquema que divida exactamente la duración objetivo dentro de 2–16 fotogramas; si el número explícito de fotogramas es incompatible, se reporta un error antes de la generación. Solo si se acepta explícitamente la aproximación se establece duration_policy:quantize y se revela el error. 15 segundos se pueden planificar como 5 segmentos × 3 segundos × 15 fotogramas, cada fotograma 200ms; no se puede afirmar que 16 fotogramas × 310ms equivalen a 5 segundos. Las tasas de fotogramas bajas son adecuadas para acciones simples; no se garantiza fluidez cinematográfica.
4. Recomendar estilos y comparar candidatos, luego ejecutar style_router.py guide --style ID para leer el texto completo del estilo seleccionado. Verificar materiales, personajes, paleta de colores, acción, movimiento de cámara y tabúes visuales; ignorar requisitos de subtítulos, sonido o motores de código upstream. Ver styles.md.
5. Cuando se necesita coherencia de personajes entre tomas pero no hay referencia principal del usuario, usar style_router.py reference-prompt --style ID --subject-file FILE para generar un plan de prompt de referencia principal, luego llamar al modelo permitido. Primero revisar la referencia principal real, luego reutilizarla en cada toma y bloquear las características del personaje y style_lock; no sustituir resultados a la deriva por la referencia principal.
6. Escribir el JSON de solicitud, prepare congela el prompt, dimensiones, plan de tiempos, hash del texto del estilo y referencias. Verificar parámetros y duración total antes de generar. Los cambios de solicitud usan un nuevo directorio; no se sobrescriben resultados antiguos.

Generación y evidencia de origen

Modo oficial: prepare → official_api.py generate, no se llama a native-request para reservar duplicados. Solo después de que la primera toma reciba un GIF real de múltiples fotogramas, los parámetros técnicos cumplan y haya suficiente evidencia de origen, se continúa; si fallan dimensiones, fotogramas o formato, primero localizar el problema, no repetir ciegamente todo el grupo.

Modo Codex: prepare → native-request → según el esquema real, llamar a la herramienta nativa (conservando gif) → import-native. Si no hay archivo, usar finish-attempt para registrar fallo o desconocido. No se pueden tratar model/size/output_format no expuestos como campos de herramienta.

• model_evidence.reported_model solo registra el modelo real devuelto por el servicio; si falta, se mantiene null, no se adivina el modelo.
• Las solicitudes oficiales pueden usar un endpoint HTTPS fijo oficial, permitir explícitamente el modelo, sin redirección, respuesta 200, ID de solicitud y hash de solicitud para formar official_request_evidence. Esto prueba el origen de la solicitud oficial, no equivale a que el servicio se autodenomine modelo ejecutado.
• Origen desconocido de Codex, acuse de recibo oficial incompleto o conflicto en el informe del modelo todavía no pasan. Los históricos unknown/unverified no se reescriben automáticamente.

Revisión y entrega

Leer quality.md. Las comprobaciones técnicas solo prueban formato, dimensiones, fotogramas, retardo, decodificación y variación de píxeles; no prueban naturalidad del movimiento. La comprobación visual real debe examinar todos los fotogramas y la reproducción completa a velocidad normal, registrando por separado identidad, estilo, estructura, movimiento, semántica, bucle, clean_visual (sin texto ni capas de superposición). Si Jev está disponible, usar muestreo real de fotogramas y referencia principal; el muestreo estático y el rango de reproducción completa se registran por separado.

review vincula el hash del archivo original; solo después de que todos los requisitos de calidad se cumplan se export como ready_gif_assets. Las exportaciones derivadas solo consumen paquetes ready por defecto. Si la calidad técnica y de origen es aceptable pero falta la comprobación de reproducción completa, se puede hacer explícitamente --review-copy para crear un archivo pendiente de revisión, conservando rendered_pending_review y los elementos faltantes; las fallas visuales claras no pueden pasar por el modo pendiente.

Según la elección del usuario, llamar a compose_movie.py --out assets.gif o --out assets.mp4, compatible con lista de tomas de un solo bundle o múltiples bundles. Usar solo un ciclo por toma, manteniendo la velocidad original; no añadir subtítulos ni sonido. La exportación MP4 fuerza solo un stream de video; el GIF largo verifica el retardo total real, dimensiones, orden y reproducción única. Ambos requieren revisión visual real; la revisión de streams no puede detectar texto quemado en la imagen.

Entregar el archivo seleccionado, GIF originales, lista de fuentes, recibo de renderizado y alcance de verificación restante. Mantener historial de resultados y versiones corregidas rastreables. Si la ruta de instalación es un enlace simbólico, actualizar el directorio fuente; empaquetar excluyendo claves y artefactos de ejecución.