Proyecto-a-Video
Convierte cualquier proyecto en un video de marketing premium. La habilidad se ejecuta dentro del repositorio del proyecto (o contra una URL), analiza qué es realmente el producto y produce un video de Remotion basado en características reales e interfaz de usuario real.
Regla de oro: el pipeline es ANALIZAR → STORYBOARD → APROBAR → CONSTRUIR → RENDERIZAR. Nunca escribas código de Remotion antes de que el storyboard sea aprobado por el usuario.
MODO AUTOMÁTICO: Si la solicitud del usuario contiene "completamente automático", "sin interrupciones", "de una sola vez", "piloto automático" o claramente pide una ejecución ininterrumpida de principio a fin, cambia a modo automático: omite la pausa de aprobación del storyboard (escribe video/storyboard.md, indica que procedes en modo automático y continúa directamente a la construcción), decide automáticamente cualquier pregunta abierta usando valores predeterminados sensatos (arquetipo explicativo, 1080×1920 @ 30fps, tokens de marca según el orden de prioridad estándar), y solo detente por bloqueos reales (sitio inalcanzable, errores de renderizado que sobrevivan a 3 intentos de corrección). Iniciar un servidor de desarrollo local aún requiere autorización explícita del usuario, pero trata "completamente automático" como dicha autorización si el usuario proporcionó el comando de ejecución o el repositorio tiene un comando de desarrollo estándar inequívoco (npm run dev, docker compose up). En modo automático, sigue entregando el storyboard junto con el MP4 para que el usuario pueda revisarlo después y solicitar cambios a nivel de escena.
Fase 0 — Detectar entradas
Establece con qué tienes que trabajar, en orden de prioridad:
- URL en vivo (producción o UAT/staging) — la mejor fuente. Pídesela al usuario si no la proporcionó.
- Servidor de desarrollo local — si el repositorio está presente pero no hay nada ejecutándose, ofrece iniciarlo. Lee
package.json/docker-compose.yml/Makefile/ README para encontrar el comando de desarrollo. Pídele al usuario confirmación antes de iniciar cualquier cosa (las variables de entorno, puertos y bases de datos varían). Si no se puede iniciar, recurre al análisis solo con código. - Solo código — analiza el repositorio estáticamente; los visuales serán recreaciones SVG puras.
También pregunta (o deduce del contexto):
- ¿Qué arquetipo? (explicativo / demo / lanzamiento / avance — consulta
references/video-archetypes.md) - ¿Qué relación de aspecto(s)? Por defecto: 1080×1920 vertical, 30 fps. Ofrece 16:9 y 1:1 como renderizados adicionales.
- ¿Algún token de marca? Busca un JSON de tokens de diseño en el repositorio; si no, extrae colores/fuentes del sitio en vivo; si no, usa los valores predeterminados de
assets/brand-theme.json.
Fase 1 — Analizar el proyecto
Objetivo: un archivo video/project-brief.md del cual cada afirmación posterior pueda rastrearse.
Análisis estático — lee README, docs/, texto de la página de inicio en el repositorio, estructura de rutas/páginas, módulos de funcionalidad, nombre del producto y eslogan.
Análisis en vivo (si existe una URL) — ejecuta scripts/capture-screens.mjs con Playwright para:
- Capturar pantallas de las páginas clave (inicio/hero, panel de control, 3–5 pantallas de funcionalidades principales) en la relación de aspecto objetivo y en tamaño de escritorio
- Grabar capturas de pantalla cortas (3–6s) de 1–2 flujos principales si el arquetipo es demo o lanzamiento
- Extraer los colores, fuentes y texto de titulares reales del sitio
Escribe video/project-brief.md que contenga: qué es el producto, audiencia objetivo, las 5–7 funcionalidades principales (cada una con la fuente de evidencia), identidad visual (colores/fuentes/logo) y la lista de activos capturados con rutas de archivo.
Regla: sin funcionalidades inventadas, sin afirmaciones exageradas. Si no está en el repositorio, docs o sitio en vivo, no va en el video.
Fase 2 — Storyboard (puerta de aprobación obligatoria)
Lee references/video-archetypes.md para la estructura de escenas y duración del arquetipo elegido, luego completa references/storyboard-template.md escena por escena usando SOLO material del resumen del proyecto.
- La narración es texto en pantalla, no voz en off. Mantén las líneas en pantalla cortas (máximo ~8 palabras por línea, máximo 2 líneas a la vez) y ponles ritmo para que cada una sea legible (~0.35s por palabra mínimo en pantalla).
- Presupuesta los fotogramas por escena de antemano para que el total coincida exactamente con la duración del arquetipo.
- Para cada escena, marca qué visuales son SVG y cuáles son capturas de UI reales en marcos de dispositivo (estilo híbrido — consulta el documento de estándares).
- Incluye una sección de sugerencias de música y sonido al final (género, sensación de BPM, dónde caen los acentos). No busques ni incrustes archivos de audio.
Guarda como video/storyboard.md, preséntalo al usuario y DETENTE. No continúes hasta que el usuario lo apruebe o edite. (Excepción: en MODO AUTOMÁTICO, presenta el resumen del storyboard y continúa inmediatamente sin esperar.)
Fase 3 — Construir el proyecto Remotion
Después de la aprobación, lee references/remotion-standards.md completo — contiene los valores de animación requeridos, reglas de transición y los patrones híbridos SVG + captura de pantalla con marco de dispositivo. Luego, crea el scaffold:
video/
├── remotion.config.ts
├── src/
│ ├── index.ts # registerRoot
│ ├── Root.tsx # <Composition> por relación de aspecto
│ ├── config.ts # fps, duraciones, presupuesto de fotogramas por escena
│ ├── theme.ts # TODOS los colores/fuentes/espaciado — fuente única de verdad
│ ├── scenes/ # un archivo por escena del storyboard
│ ├── components/ # DeviceFrame, CountUp, AnimatedChart, ConnectorLine, ParticleField, TextReveal…
│ └── assets/screens/ # Capturas de la Fase 1 (importadas mediante staticFile)
Reglas estrictas:
- Cada color, fuente, radio y sombra proviene de
theme.ts. Sin valores codificados en las escenas. - Las duraciones de las escenas provienen de
config.tsy deben sumar el total del arquetipo. - Todos los gráficos de diagramas/gráficos/iconos son SVG en línea. La UI real del producto aparece solo dentro de componentes
DeviceFrameusando las capturas de pantalla de la Fase 1 — nunca falsifiques una captura de pantalla de producto con SVG cuando exista una real. - TypeScript en todo, Remotion 4.x,
@remotion/transitionspara cambios de escena.
Fase 4 — Vista previa, renderizado, entrega
npx remotion studio— verifica cada animación, comprueba la legibilidad del texto a velocidad de reproducción real, confirma la sincronización.- Corrige problemas, luego
npx remotion render <CompositionId> out/<arquetipo>-vertical.mp4. - Renderiza relaciones de aspecto adicionales si se solicita.
- Entrega: MP4(s),
storyboard.md,project-brief.mdy el proyecto editable. Menciona quetheme.tsyconfig.tsson los dos archivos a modificar para cambiar la marca o el tiempo.
Archivos de referencia
references/video-archetypes.md— estructuras de escenas + duraciones para explicativo (60s), demo (75–90s), lanzamiento de función (30s), avance (15s). Léelo durante la Fase 0/2.references/storyboard-template.md— el formato de tabla por escena. Léelo durante la Fase 2.references/remotion-standards.md— valores de animación, transiciones, patrones híbridos de marco de dispositivo, reglas SVG. Léelo completamente antes de la Fase 3.scripts/capture-screens.mjs— script de captura con Playwright. Ejecútalo durante la Fase 1 (node scripts/capture-screens.mjs <url> <outDir>; requierenpm i playwright+npx playwright install chromium).assets/brand-theme.json— tokens de marca de respaldo; anula con valores extraídos del proyecto siempre que sea posible.