motion-video · Crea animaciones verificables con código

Este skill resuelve un problema muy específico: los modelos pequeños (Flash/mini/turbo) pueden escribir CSS y Canvas, pero las animaciones que generan a menudo "parecen escritas, pero en realidad no se mueven" — los estados intermedios se saltan, las curvas de easing son falsas, los elementos clave aparecen en otros momentos o la animación se detiene a mitad de camino. El modelo no puede detectarlo porque no tiene ojos.

Por lo tanto, el enfoque no es "enseñarle a escribir mejor", sino convertir la animación en un artefacto de ingeniería verificable por máquina:

Primero especificaciones, luego código — Traduce los juicios estéticos a valores numéricos en tablas.
El estado de la imagen debe ser una función pura de t — Fuerza estructuralmente la escritura de estados intermedios.
Los números se dejan a los scripts — Bezier, resortes, escalonados, contraste: todo se ejecuta con herramientas, no con cálculo mental.
Usa un renderizador determinista para generar fotogramas uno a uno — El mismo código siempre produce el mismo fotograma.
Verificación por máquina — Primero se verifica la capa numérica, luego la capa de píxeles.
Solo después de que la máquina diga "la estructura está bien", el ojo humano evalúa la composición.

La brecha no se cierra con una frase mágica. Se cierra con estas seis cosas que convierten "no se puede pensar bien" en "se puede descubrir y reparar". De dónde viene la brecha, qué se puede compensar y qué no, se explica en references/delta-vs-opus.md.

Prioridad de calidad: solo ahorra gastos inútiles, no ahorres verificación

Esta regla está por encima de las siguientes. El objetivo de este skill es producir videos de nivel Opus, no el más barato. Por lo tanto, el criterio para "hacer esto o no" no es si es rápido, sino si es mejor.

Solo hay un tipo de gasto que se puede ahorrar: repetitivo, inútil, que compite por recursos. La densidad de verificación, la calidad de renderizado, la tasa de fotogramas, el desenfoque de movimiento — nunca se ahorran.

Ahorro permitido (desperdicio, ahorrarlo no suma ni resta puntos)

Desperdicio	Cómo ahorrar
Iniciar 4 Chrome concurrentes compitiendo por CPU	Serial (más rápido que concurrente), `render.mjs` ya tiene bloqueo de instancia única
Un documento de especificaciones de 20KB por capítulo	Un solo `storyboard.md` que lo escriba todo
Llamar repetidamente a `render --still` para extraer solo un fotograma cada vez	Extraer 6–8 puntos de tiempo de una sola vez
Reanalizar repetidamente el mismo material	Analizar una vez, escribir los resultados en el storyboard
Escribir PNG cuadro por cuadro en disco y luego leerlos	Ya activado `optimizeForSpeed`; para proyectos grandes, usa image2pipe (cinema-grade.md §9)
Verificar la misma cosa tres veces "por seguridad"	Verificar dos veces (numérica + píxeles) es suficiente; una tercera vez no añade información

Ahorro prohibido (ahorrarlo significa bajar la calidad)

No ahorrar	Razón
`audit` completo, incluyendo el procesamiento uno por uno de jump/flat	Último paso antes de la entrega; saltarlo = no verificar
`verify --idempotent`	Si la idempotencia se rompe, todas las verificaciones posteriores no son fiables
`rigcheck` (cada vez que se cambia un personaje o pose)	Las malas posiciones de huesos solo se pueden detectar con números, los ojos no lo ven
Activar desenfoque de movimiento en la versión de entrega	La diferencia en la sensación visual entre tenerlo y no tenerlo es de un nivel, no es un adorno
Usar 60fps cuando hay movimiento rápido	Con 30fps, las extremidades en movimiento rápido se entrecortan; esto es un defecto, no una compensación
Ver fotogramas clave (múltiples momentos + zoom local)	1 imagen no muestra problemas en el medio; al menos 6 fotogramas + zoom 2–3× en partes clave
Volver a ejecutar después de la corrección (en lugar de "debería estar bien")	Si no se vuelve a ejecutar, es como si no se hubiera corregido

Criterio en una frase

Lo que se ahorra es tiempo de espera, se puede ahorrar; lo que se ahorra es "oportunidad de encontrar errores", no se puede ahorrar.

Renderizar 70 minutos es inaceptable, no porque "70 minutos sea demasiado", sino porque el 85% de esos 70 minutos son 4 procesos compitiendo por CPU — la espera no ha aportado ninguna calidad. En cambio, gastar 4 veces más tiempo de renderizado para un obturador de 180° aporta una mejora tangible en la experiencia visual — esa inversión es necesaria.

El orden correcto para acelerar

Primero elimina el desperdicio: cambia concurrente a serial, combina inicios repetidos, elimina documentos redundantes, extrae fotogramas en lote.
Luego optimiza la implementación: parámetros de captura de pantalla, múltiples pestañas en un solo proceso, codificación directa sin escritura en disco.
Finalmente, considera reducir la verificación — y este paso básicamente nunca debería ocurrir; si ocurre, significa que los dos pasos anteriores no se hicieron.

Reglas de hierro

Si se viola alguna, el producto es inverificable y debe rehacerse.

No se escribe código sin especificaciones. Primero produce la tabla de tomas y la tabla de línea de tiempo (PASO 1). Cada elemento en la tabla debe tener tres intervalos de tiempo: enter / active / exit. Si falta uno, significa que aún no has pensado cuándo existe. Pero cuando el usuario solo da una frase ("haz algo impresionante", "muestra tu capacidad", "dale con todo"), no le pidas que haga una entrevista — tú mismo llena los cuatro campos (tema/narrativa central/forma/nivel) y escríbelos en storyboard.md, luego comienza directamente. Ver references/wish-mode.md.
Todos los estados de la imagen son funciones puras de seek(t). Prohibido usar requestAnimationFrame, Date.now(), performance.now(), Math.random(), contadores autoincrementales y @keyframes/transition de CSS que se ejecuten solos. El mismo código y el mismo t deben renderizar siempre el mismo píxel.
Todos los valores numéricos se obtienen de scripts, prohibido el cálculo mental. Puntos de control de curvas, parámetros de resortes, escalonados, conversión de coordenadas, relaciones de contraste, cadenas linear() — todo debe ser generado por ease.mjs. Antes de que aparezcan este tipo de números en tu respuesta, debe haber una salida de herramienta. Ver más abajo «Números a las herramientas, juicios a ti».
Después de modificar, debes ejecutar verify y render + audit. FAIL no se entrega. WARN debe ir acompañado de una explicación "corregir" o "esto es intencional porque...". No está permitido saltarse verify y renderizar directamente — gastar 8 segundos extra solo para obtener un "la imagen no se mueve" sin saber la causa.
Entrega tres cosas: el video final (mp4/webm/gif) + la hoja de contactos (-sheet.png) + la conclusión de audit.
Si no estás seguro estéticamente, da opciones, no adivines. Dos combinaciones de colores, dos ritmos, deja que el usuario elija. Es mejor que entregar una versión mediocre.
No esperes materiales, dibújalos tú mismo. El producto final no debe contener frases como "se sugiere insertar una imagen", "poner una imagen aquí", "esperar a que lleguen los materiales". El pipeline de renderizado solo tiene HTML/CSS/SVG/Canvas — todos los elementos visuales deben ser generados por código. Cuando necesites efectos de luz/texturas/gráficos/iconos, primero consulta references/asset-recipes.md (20 tipos de fragmentos listos para usar, que se pueden pegar directamente: halos, barridos de luz, gránulos, tarjetas de vidrio, neón, rejillas, ilustraciones abstractas, partículas, esferas de alambre, gráficos, siluetas de ciudad, fallas, líneas de escaneo, conjuntos de iconos, haces de luz, profundidad de campo, texturas de tela, bokeh, pseudo 3D), si no, escribe tu propio path SVG. Prohibido usar emojis o símbolos Unicode como gráficos. Cada imagen debe tener al menos tres capas (degradado de fondo/rejilla → sujeto → gránulos de ambiente/bokeh), al menos 2 elementos visuales creados por ti, 1 pista de profundidad (sombra/degradado/superposición de color/gránulos). Una imagen con solo una capa, solo texto y bloques de color = no apta.
Prioriza los activos existentes, prohibido reconstruir. Si en el espacio de trabajo ya hay huesos/especificaciones/componentes/diseños montados, debes usarlos todos, sin reevaluar ni un solo valor. Usa rigcheck.mjs --ref para demostrar que estás usando los valores originales. Registro de incidentes: una reconstrucción cambió head.pos de [-6.8,-182.5] a [0,-248] (desviación de 65.9px), torso.pv de [160,160] a [160,291] (desviación de 131px). El resultado fue que la cabeza flotaba a la izquierda del cuerpo, y "revisar mirando la imagen" no lo detectó — porque el ojo humano lo interpreta como "un personaje". Este tipo de error debe detectarse con números.
Lista blanca de materiales. Solo usa los materiales explícitamente listados en storyboard.md. Otros archivos en el espacio de trabajo (productos de la versión anterior, imágenes de personajes no relacionados, configuraciones de otros proyectos) no se tocan, incluso si parecen utilizables. Cuando necesites un nuevo material, añade una línea en el storyboard explicando su propósito y luego búscalo.
No bajes la guardia en la verificación ni permitas el renderizado concurrente. audit reporta WARN no significa "se puede entregar": los saltos duros (jump) y los fotogramas de color sólido (flat) deben eliminarse o explicarse uno por uno, de lo contrario, se rehace. Si verify/rigcheck tiene FAIL, no se puede continuar. El renderizado solo ejecuta un proceso render.mjs a la vez — el script tiene un bloqueo de instancia única, la concurrencia solo compite por la CPU. Para paralelizar, usa múltiples pestañas en un solo Chrome (ver cinema-grade.md §9), no inicies múltiples procesos.

Números a las herramientas, juicios a ti

Este tipo de modelos (Flash/mini/turbo) tienen una tendencia común: prefieren estimar por su cuenta en lugar de usar herramientas. Creen que el cálculo mental no tiene costo y que las herramientas requieren espera. Esta contabilidad de costos es incorrecta. Primero, aclaremos los números:

	Cálculo mental	Usar `ease.mjs`
Tiempo directo	0 segundos	Aprox. 0.3–0.5 segundos
Probabilidad de acertar a la primera	30–40 (un error en un punto de control de Bezier cambia toda la curva)	100
Costo de equivocarse	Renderizar 90 fotogramas ≈ 8 segundos + revisar, y es probable que no veas el error, solo parece "no es suave"	0
Costo esperado	0 + 0.5 × (8 + 30) ≈ 19 segundos, y la calidad disminuye silenciosamente	0.5 segundos

Los 0.5 segundos que ahorra el cálculo mental son el tipo de ahorro más caro. Así que esto es un requisito estricto, no una sugerencia:

Los siguientes números deben provenir de la salida de la herramienta, no se permite escribir valores inferidos a mano en la respuesta:

Qué quieres	Qué ejecutar
Propiedades de cualquier Bezier (overshoot, plataforma, tabla de muestreo)	`node scripts/ease.mjs cubic 0.22 1 0.36 1`
Parámetros de resorte (cuánto rebota, cuánto tarda en detenerse, si se detiene a mitad de camino)	`node scripts/ease.mjs spring 120 14 1 1.2`
Comprimir una curva en CSS `linear()`	`node scripts/ease.mjs css-linear --preset silkIn`
Escalonado de un grupo de elementos, si excede la duración total	`node scripts/ease.mjs stagger 7 2.4 0.5`
Si el contraste de texto es suficiente	`node scripts/ease.mjs contrast "#0b0e14" "#6d8bbd"`
Generar una escala de grises legible a partir de un color de fondo	`node scripts/ease.mjs ramp "#0b0e14" 5`

Tres preguntas de autocomprobación (pregúntate antes de entregar; si no puedes responder, es una infracción):

¿Cada parámetro de curva en mi respuesta puede estar vinculado a la salida de un comando anterior?
¿He escrito en alguna línea un número estimado como "aproximadamente 0.3"? Si es así → bórralo y ejecuta el comando.
¿Digo "esta curva es muy suave" porque he visto el gráfico ASCII y el porcentaje de overshoot de ease.mjs, o porque lo supongo?

El modelo también quiere verificarse por sí mismo, así que usa el verificador para que esté tranquilo: verify.mjs lee los estilos calculados reales, no suposiciones. Cuando quiera "confirmar algo", la acción correcta es ejecutar verify, no simularlo en su propia mente.

Entorno

Sin dependencias npm. Necesita Chrome o Edge (ya instalado) + ffmpeg + ffprobe.

ffprobe solo se usa en audit para verificar resolución/duración. Si falta, no se permitirá el paso en silencio: si se declaran --width/--height/--duration, FAIL; si no se declaran, WARN e imprime "Resolución desconocida (no verificada)".

node scripts/render.mjs --check      # Imprime capacidades de chrome / ffmpeg / node / WebSocket

Si en la salida chrome aparece como NOT FOUND, especifícalo con --chrome <ruta>, o instala un navegador primero.

Qué hacer cuando no hay comprensión de imágenes

Algunos modelos (por ejemplo, versiones de inferencia de solo texto) no pueden read_image. El juicio de este pipeline es todo numérico, no de imágenes, por lo que aún se puede completar: ease (parámetros) → verify (trayectoria numérica + idempotencia) → audit (estadísticas de píxeles, conclusión son números) → rigcheck (aserciones geométricas).

Se puede hacer: estructura, movimiento, geometría, legibilidad.
No se puede hacer: calidad de la composición, armonía de colores, unidad de estilo, clipping visual.

Esto último debe dejarse a personas que puedan ver imágenes o modelos visuales. Pero se puede posponer hasta el final: primero usa números para detectar todos los errores posibles, y luego de una sola vez muestra 6–8 fotogramas a la persona (--still extracción por lotes + --guides superponer zonas seguras).

Índice de documentos (léelos según sea necesario, no todos a la vez)

Archivo	Cuándo leerlo
references/wish-mode.md	Cuando el usuario solo da una frase, léelo primero: cuatro campos, derivación de capítulos, tabla de valores predeterminados, no se permiten entrevistas en modo deseo
references/spec-and-prompt.md	Al escribir la tabla de especificaciones en PASO 1; cuando necesites una plantilla de prompt reproducible; para tratar con modelos que "no quieren usar herramientas"
references/code-patterns.md	Al escribir código en PASO 2: patrón `seek(t)`, bibliotecas de easing, tabla de fotogramas clave `keys()`, `spring(f,z)`, SVG/Canvas, 20 efectos CSS modernos
references/asset-recipes.md	Cuando a la imagen le falte algo, consulta primero: halos, barridos de luz, gránulos, vidrio, neón, rejillas, ilustraciones, partículas, esferas de alambre, gráficos, conjuntos de iconos, bokeh, pseudo 3D
references/rig-characters.md	Cuando haya personajes en la imagen que deban moverse: partes, cadena de transformación padre-hijo, tabla de poses, cómo aplicar los 12 principios a los campos
references/cinema-grade.md	Antes de la finalización: desenfoque de movimiento, parámetros de codificación (anti-banding), viñeteado, sistema HUD, barridos de cámara, selección de fps, organización de videos largos, aceleración paralela
references/review-checklist.md	Inspección ocular humana en PASO 5 + revisión uno por uno antes de la entrega
references/failure-modes.md	Cuando audit/verify den error, busca la causa correspondiente
references/delta-vs-opus.md	Cuando quieras saber "hasta dónde puede llegar este sistema" o necesites decidir si cambiar de modelo

Primero, bifurca: ¿Deseo o requisito?

Cómo es la entrada	Qué camino tomar
Ha dado la mayoría de: dimensiones/duración/contenido/estilo; o está respondiendo a tus preguntas	Modo especificaciones: PASO 0 preguntar → PASO 1 tabla de especificaciones → …
Una frase + tono de autorización ("haz algo impresionante", "muestra tu capacidad", "como tal tipo de video", "dale con todo")	Modo deseo: saltar PASO 0, no está permitido preguntar. Primero escanea el espacio de trabajo para encontrar el tema, llena los cuatro campos tú mismo, luego comienza desde el PASO 1. Ver wish-mode.md

El criterio es simple: Lo que no ha aclarado, ¿es "espera a que pregunte" o "tú decides"? Si el tono incluye "tú decides/da lo mejor de ti/enséñame", es lo segundo. El modo deseo también requiere escribir storyboard.md — la diferencia es que la tabla la escribes tú, no se pregunta.

Flujo de trabajo

PASO 0 · Pregunta tres cosas (solo modo especificaciones; saltar en modo deseo)

Propósito: intro de presentación / video corto para redes sociales / animación hero de página web / inserto explicativo / animación de crecimiento de datos / GIF
Dimensiones y duración: ver valores predeterminados en la tabla a continuación, a menos que el usuario lo solicite explícitamente
Emoción: estable (empresa/finanzas), rápido (tecnología/lanzamiento), suave (vida/marca), duro (juego/deporte)

Propósito	Dimensiones	Duración	fps	Formato
Intro / Presentación	1920x1080	3–6s	30	mp4
Vertical para redes sociales	1080x1920	5–15s	30	mp4
Hero / Banner de página web	1920x800 o 1440x600	2–4s, puede ser en bucle	30	webp / apng (necesita transparencia); webm requiere verificación alpha primero
Animación de datos / Gráficos	1920x1080	3–8s	30	mp4
GIF en bucle	800x800 / 1080x1080	1–3s, debe poder hacer bucle sin problemas	15–20	gif / webp
Inserto explicativo	1920x1080	2–5s por toma, luego se monta todo	30	mp4

Si supera los 10 segundos o 3 tomas: divídelo en múltiples archivos de escena, renderiza y verifica cada uno por separado, y luego únelos con ffmpeg. No permitas que un solo seek() maneje 30 segundos — nadie podrá revisarlo por sí mismo.

PASO 1 · Escribe las especificaciones (el único paso donde hay libertad creativa)

Produce storyboard.md, dos cosas son indispensables:

① Tabla de tomas

#	Tiempo	¿Qué hace la imagen?	Movimiento principal	Estado final
1	0.00–1.10s	Título flotando letra por letra	y: +96→0, cada letra escalonada 75ms	Título en su lugar
2	1.10–2.40s	Línea de progreso se llena + tres puntos aparecen	scaleX: 0→1 (ease-in-out)	Línea al borde, puntos alineados

② Tabla de línea de tiempo de elementos (una fila por elemento, esta es la única base para el código posterior)

Elemento	enter	active	exit	Propiedad	Curva
#title span	0.15 + i*0.075	Hasta el final	—	translateY 96→0, opacity 0→1	easeOutCubic
#bar b	0.30	0.30–2.40	—	scaleX 0→1	easeInOutCubic
.dots i	1.50 + i*0.15	Hasta el final	—	scale 0→1	easeOutBack

Si no puedes escribir esta tabla = aún no lo has pensado bien. No la saltes para escribir código; lo que escribas será solo "fotograma inicial y final".

La columna «Curva» no es para que solo escribas un nombre. Después de decidir el nombre, ejecuta la herramienta una vez para fijar "cómo será esta curva en tu duración específica", y luego completa la fila con valores numéricos:

node scripts/ease.mjs cubic 0.33 1 0.68 1     # easeOutCubic → ver sección plana/overshoot
node scripts/ease.mjs stagger 6 2.4 0.7       # 6 letras de título en 2.4s, cada una 0.7s → escalonamiento y desbordamiento

Así, esas dos filas en la tabla se convierten en:

Elemento	enter	active	exit	Propiedad	Curva (confirmada por herramienta)
#title span	0.15 + i*0.075	Hasta el final	—	translateY 96→0, opacity 0→1	cubic-bezier(0.33,1,0.68,1), overshoot 0%, sección plana después de 0.75 → duración reducida a 0.7s
.dots i	1.50 + i*0.15	Hasta el final	—	scale 0→1	spring(120,14) overshoot 7.1%, estable en 0.67s → duración del segmento 0.75s

Criterios para una buena curva (la herramienta te lo dirá directamente): overshoot ≤ 15%, sin sección plana en el medio, tiempo de estabilización del resorte no mayor que la duración del segmento. Si no se cumple alguno, cambia los parámetros y ejecuta de nuevo, no "escribe esto primero y mira cómo queda".

Plantillas y más patrones: references/spec-and-prompt.md

PASO 2 · Implementación

Comienza desde el esqueleto, no escribas toda la escena de una vez. Esqueleto = fondo + un elemento que se mueve + contrato seek.

window.scene = {
  duration: 3.0, fps: 30, width: 1920, height: 1080, ready: true,
  seek(t) {
    // Cada elemento: traduce "esa fila de la tabla de línea de tiempo" literalmente a 3 líneas de código
    // k = curva(seg(t, enter, enter + duración)) → usa k para interpolar la propiedad
  },
};

El CSS y JS deben estar en línea. No uses CDN externos (fallará como si no hubiera red durante el renderizado). Usa fuentes del sistema ("Segoe UI", "Microsoft YaHei", Arial).

Patrones disponibles (DOM/CSS/SVG/Canvas/GSAP/Web Animations, bibliotecas de easing, orquestación de múltiples segmentos, texto letra por letra, trazado de path, desplazamiento numérico, transiciones de máscara, CSS linear(), usos de filter/blend-mode/mask): references/code-patterns.md

Cuando necesites dibujar algo (efectos de luz, texturas, gráficos, iconos, gráficos estadísticos, ilustraciones, pseudo 3D), consulta primero references/asset-recipes.md. Allí hay 20 tipos de fragmentos sin dependencias, todos se pueden pegar directamente en un archivo HTML único y aceptan el control de seek(t). No crees desde cero por intuición ni esperes materiales.

PASO 3 · Verificación numérica (primero revisa los números, no te apresures a renderizar)

Este es el primer paso de "verificar más": en segundos, sin codificación, y puede señalar elementos específicos.

# Ver la trayectoria real de cada elemento: quién se mueve, hasta dónde, dónde se atasca
node scripts/verify.mjs --html scene.html --select "#bar b,#title span" --props transform,opacity --steps 31

# Verificar que "la imagen solo está determinada por t" (la misma t debe dar el mismo resultado dos veces)
node scripts/verify.mjs --html scene.html --select ".item" --idempotent

Te dirá directamente las respuestas a este tipo de cosas:

⚠ #b[0] · sx — se detiene a mitad de camino 0–2s y luego continúa cambiando → la interpolación de este segmento está rota o falta
ℹ #card[0] · (todos) — este elemento no tiene ningún cambio en todo el segmento → el selector no coincide / el estilo no está en el DOM
✖ seek no es idempotente: 13 lugares donde la misma t da resultados diferentes en dos llamadas → se usó estado acumulativo en seek

Si la capa numérica está bien, continúa. No renderices todo si la capa numérica tiene problemas — solo obtendrás un vago "la imagen parece no moverse" y luego tendrás que deducir la causa desde los píxeles. Deja que los números hablen primero.

PASO 4 · Renderizado + verificación de píxeles

Primero solo genera fotogramas clave, es rápido y suficiente para juzgar si la composición es correcta:

node scripts/render.mjs --html scene.html --still 0.2,1.0,2.2 --out out/stills

Mira estas imágenes (usa read_image para verlas tú mismo, no las saltes). Si la composición está bien, renderiza todo:

node scripts/render.mjs --html scene.html --out out/v.mp4 --fps 30 --sheet
node scripts/audit.mjs --video out/v.mp4 --fps 30 --duration 3 --width 1920 --height 1080

audit te dará: curva de píxeles cambiantes, barra de ritmo y conclusión jerárquica. Corrige según la conclusión, solo corrige la parte señalada una vez, y luego vuelve a ejecutar audit inmediatamente. Máximo 5 rondas; si en la quinta ronda aún FAIL, vuelve al PASO 1 para modificar las especificaciones (significa que la especificación en sí misma está mal).

Errores comunes y sus causas: references/failure-modes.md

PASO 5 · Inspección ocular humana

La máquina solo garantiza que "la estructura es correcta". Estas cosas debes revisarlas tú mismo mirando las imágenes:

¿El texto se desborda / se recorta / choca con el fondo?
¿El centro visual está en la posición esperada (regla de los tercios / centrado / centro de gravedad del grupo de elementos)?
¿El contraste es suficiente (texto gris con 40% de transparencia sobre fondo oscuro es invisible)?
¿Las entradas y salidas son limpias (hay elementos que comienzan a moverse fuera de la imagen o desaparecen repentinamente dentro de la imagen)?

Lista de verificación: references/review-checklist.md

PASO 6 · Entrega

# Añade una línea más para el formato necesario
node scripts/render.mjs --html scene.html --out out/v.webm --format webm
node scripts/render.mjs --html scene.html --out out/v.gif --format gif --fps 15

Al entregar, proporciona: la ruta del video final, la hoja de contactos, las líneas de veredicto de audit, storyboard.md. Si audit tiene WARN pero tu juicio es que es intencional, indica claramente cuál es y por qué.

La versión final debe volver a renderizarse con desenfoque de movimiento activado.

node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 30 --motion-blur 180

Esta es la línea divisoria entre "se ve suave" y "parece una grabación de pantalla". Durante la fase de iteración, puedes desactivarlo temporalmente para ahorrar tiempo, pero la versión de entrega no puede carecer de obturador — ahorrar esto es bajar la calidad. Después de activarlo, vuelve a ejecutar audit para confirmar que la duración y los fps no se han modificado. Si hay movimiento rápido (acciones de personajes, barridos de cámara, partículas), activa también --fps 60.

Referencia rápida de comandos

# Comprobación de salud
node scripts/render.mjs --check

# Cálculos (curvas / resortes / escalonados / contraste) — estos no se calculan mentalmente
node scripts/ease.mjs cubic 0.22 1 0.36 1
node scripts/ease.mjs spring 120 14 1 1.2
node scripts/ease.mjs css-linear --preset silkIn
node scripts/ease.mjs stagger 7 2.4 0.5
node scripts/ease.mjs contrast "#0b0e14" "#6d8bbd"
node scripts/ease.mjs ramp "#0b0e14" 5
node scripts/ease.mjs presets

# Comprobación de geometría de huesos (obligatorio si hay personajes; si hay rig existente, debe usar --ref para alinear)
node scripts/rigcheck.mjs --rig rig/ander.rig.json
node scripts/rigcheck.mjs --rig lib/rig.json --ref rig/ander.rig.json
node scripts/rigcheck.mjs --rig rig.json --pose '{"head":{"rot":0.2}}' --assert

# Comprobación de frontmatter de SKILL.md (ejecuta cada vez que modifiques el skill, para evitar que "todo el skill no se cargue")
node scripts/lint-skill.mjs

# Verificación numérica (en segundos, puede señalar elementos)
node scripts/verify.mjs --html scene.html --select "#bar b" --props transform,opacity --steps 31
node scripts/verify.mjs --html scene.html --select ".item" --idempotent
node scripts/verify.mjs --html scene.html --all --json

# Fotogramas clave (para revisar, el más rápido)
node scripts/render.mjs --html scene.html --still 0,0.5,1.5,2.9 --out out/stills

# Fotogramas clave + líneas guía de composición (rejilla de 100px / zona segura de 80px / líneas de tercios / cruz central)
node scripts/render.mjs --html scene.html --still 1.6 --guides --out out/guides

# Video completo + hoja de contactos
node scripts/render.mjs --html scene.html --out out/v.mp4 --fps 30 --sheet

# Versión final con desenfoque de movimiento (obturador de 180° = estándar cinematográfico; renderizado ×4, solo para la versión final)
node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 30 --motion-blur 180

# Solo para movimiento rápido (acciones de personajes, barridos de cámara, partículas) usar 60fps
node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 60 --motion-blur 180

# Sobremuestreo 2x (más nítido, 3–4 veces más lento)
node scripts/render.mjs --html scene.html --out out/v.mp4 --scale 2

# Fondo transparente: webp / apng / png son fiables
node scripts/render.mjs --html scene.html --out out/v.webp --format webp --alpha
node scripts/render.mjs --html scene.html --out out/v.apng --format apng --alpha

# El alpha de webm depende de la compilación de ffmpeg. Las pruebas locales muestran que VP8/VP9 degradan a sin alpha.
# El script lee el primer fotograma después de la codificación para verificarlo — si no hay píxeles transparentes, muestra un error y te dice qué formato usar.
node scripts/render.mjs --html scene.html --out out/v.webm --format webm --alpha

# GIF en bucle
node scripts/render.mjs --html scene.html --out out/v.gif --format gif --fps 15

# Verificación de píxeles
node scripts/audit.mjs --video out/v.mp4 --fps 30 --duration 3 --width 1920 --height 1080
node scripts/audit.mjs --video out/v.gif --loop           # Comprobación de unión en bucle
node scripts/audit.mjs --video out/v.mp4 --json out/audit.json

Parámetros de render.mjs: --html --out --fps --duration --width --height --scale --format(mp4|webm|gif|webp|apng|png) --still --sheet --alpha --file --keep-frames --chrome --check --quiet Parámetros de verify.mjs: --html --select --props --steps --idempotent --all --json --duration --fps --out Parámetros de audit.mjs: --video --fps --duration --width --height --loop --json --threshold Parámetros de rigcheck.mjs: --rig --ref --pose --assert --json

motion-video-skill

¿Qué es motion-video-skill?

Preguntar en tu IA favorita

Documentación