Video de lanzamiento para un producto de software
Produce un video de 30 a 60 segundos que haga que alguien entienda y quiera el producto.
La decisión que lo define todo: reconstruir, no grabar
Las grabaciones de pantalla te complican la vida. La latencia real es tiempo muerto. Las retomas son costosas. No puedes mantener un fotograma, no puedes ralentizar un ritmo y acelerar otro, y no puedes recortar con precisión sin llegar a la compresión granulada.
Por lo tanto, reconstruye la interfaz de usuario como React guiado por fotogramas dentro de Remotion. Cada elemento visual es una
función pura de useCurrentFrame(). La escritura llega en una curva exacta, un
estado de carga se resuelve al compás, y una retoma cuesta un número.
Esto solo es razonable porque puedes leer el código real del producto (si es local) o el DOM+CSS (si está alojado) y reproducirlo fielmente. Hazlo — toma los nombres de clase reales, los colores reales, el texto real. La reconstrucción debe ser indistinguible de una grabación, y luego mejor.
Cuándo grabar en su lugar: 3D pesado, contenido de video dentro del producto, una
superficie de canvas/WebGL, o una aplicación de escritorio nativa. Si una superficie específica no puede
reconstruirse, graba solo esa superficie y compónela con <OffthreadVideo>.
Fase 1 — Comprender el producto
Lee references/discovery.md antes de comenzar esta fase. Cubre el
procedimiento de exploración y clasificación, la conversación sobre credenciales y cómo extraer
un sistema de diseño de un sitio en vivo.
Versión corta:
- Dada una URL: explórala. Primero la página de aterrizaje (te dice cómo se posicionan), luego la aplicación en sí. Averigua qué trabajo hace el producto para quién.
- Dado un repositorio local/servidor de desarrollo: lee el código. Mucho más rico — obtienes los componentes reales, los tokens de tema reales, los datos de semilla reales.
- Clasifica las páginas. La mayoría de los productos tienen 20 pantallas y 3 que importan. Autenticación, configuración, facturación, privacidad, cuenta, plantilla de incorporación — estos casi nunca son la historia. Encuentra la pantalla donde el producto hace lo que solo él puede hacer.
- Si lo bueno está detrás de un inicio de sesión, pregunta primero — credenciales de prueba, o una
cuenta con datos de semilla en su entorno de desarrollo local. Si ninguno está disponible, no te
rindas y no inventes una sesión que nunca viste: cambia a la forma de capítulos y
construye a partir de las propias tarjetas de características, texto y componentes de la página de aterrizaje.
discovery.mdtiene el procedimiento de recolección y las reglas de honestidad.
Luego confirma tu interpretación con el usuario antes de construir — una interpretación incorrecta del producto cuesta todo el proyecto. Muéstrales: lo que crees que hace el producto, las 2–4 pantallas que planeas destacar, el escenario principal, la lista de tomas y la pregunta sobre la música (consulta la Fase 4). Un punto de control, luego ejecuta.
Fase 2 — Elegir la forma
Lee references/structure.md. Dos formas funcionan; elegir mal cuesta el proyecto.
Forma A — la narrativa única. La opción predeterminada. Un usuario haciendo un trabajo y obteniendo un resultado. No es un recorrido de funciones.
| tiempo | trabajo |
|---|---|
| Gancho (0–5s) | Plantea el problema en las propias palabras del espectador. Aún sin interfaz de usuario. |
| Solicitud (5–12s) | El usuario solicita la cosa. Enfoque en la entrada. |
| Trabajo (12–25s) | El producto hace visiblemente algo difícil. Muestra las pruebas. |
| Resultado (25–35s) | La salida, completa, a un tamaño legible. |
| Control (35–45s) | El usuario lo cambia y sigue al mando. |
| Cierre (45–50s) | Logotipo, una línea, dominio. |
Los tiempos de Trabajo y Control son lo que separa una demo real de una maqueta. "Me preguntó en lugar de adivinar" y "Pude editar lo que hizo" son argumentos de confianza, y la confianza es lo que realmente vende un video de lanzamiento.
Elige el momento en que el producto hace algo que una persona no podría hacer fácilmente por sí misma, y haz que la salida sea concreta y visible — un documento generado, un gráfico construido, un error corregido, un sitio desplegado. Los resultados concretos son lo que la gente recuerda.
Forma B — la película con capítulos. Tres características, cada una presentada por una tarjeta de etiqueta en lenguaje sencillo, luego mostrada.
gancho → [01 etiqueta → característica] → [02 etiqueta → característica] → [03 etiqueta → característica] → cierre
Úsala cuando el producto está restringido y trabajas desde su página de aterrizaje, o cuando las características genuinamente no comparten un recorrido de usuario, o cuando quieres tres clips independientes de una sola compilación. Tres es el número — cuatro significa que ninguno impacta.
No dividas en capítulos una secuencia. Si las capacidades ocurren una tras otra en una sola sesión (investigación → borrador → edición), eso es un solo flujo de trabajo, y etiquetarlo como tres características va en contra del material. Si alguien pide capítulos en un producto secuencial, ofrece el camino intermedio: mantén la narrativa única y coloca las etiquetas sobre la acción a medida que aparece cada capacidad. Misma legibilidad, mismos límites de clip, sin costo adicional, historia intacta.
structure.md cubre el diseño de las tarjetas de capítulo, cómo escribir las etiquetas (nombra
el resultado, no el mecanismo; roba las palabras del producto), transiciones y
orden.
Fase 3 — Fundamentar todo
Sea cual sea el dominio del producto, no inventes su contenido. Si es un producto legal, la ley debe ser real. Si es análisis, los números deben ser plausibles e internamente consistentes. Si es una herramienta de código, el código debe compilar en la cabeza del lector.
Extrae lo real del repositorio, la API, los datos de semilla o la documentación. Los expertos en el dominio ven estos videos y un detalle inventado te cuesta a todos ellos. Nombres de partes, fechas y cifras en dólares están bien inventarlos — esos son específicos de un cliente, no afirmaciones sobre el mundo.
Mantén una nota de procedencia en el archivo de datos que indique de dónde proviene cada hecho. El tú del futuro lo agradecerá.
Fase 4 — Construir
Ejecuta el andamio, que fija las versiones que realmente funcionan juntas y escribe la configuración:
python3 <ruta-del-skill>/scripts/scaffold_video.py <directorio-destino> \
--name "product-launch" --fps 60 --seconds 45
Crea un proyecto Remotion independiente (su propio repositorio git — nunca agregues
herramientas de video al repositorio del producto a menos que se te pida), copia
useCamera.ts, y te deja un módulo de línea de tiempo para completar.
Luego, en orden:
-
src/timeline.ts— matemáticas de fotogramas y límites de toma. Elige un BPM cuyo tiempo sea un número entero de fotogramas (a 60fps: 120 BPM = 30 fotogramas, 90 BPM = 40). Pon cada límite de toma en un tiempo. Incluso sin música, esto le da al corte un ritmo interno, y significa que se puede agregar una banda musical más tarde sin volver a editar. -
src/data/script.<idioma>.ts— cada cadena, cada número, cada pieza de contenido del documento, en un archivo con comentarios de procedencia. Nada codificado en componentes. Reajustar tiempos y traducir se vuelve trivial. -
Componentes — recrea la interfaz de usuario del producto. Copia los nombres de clase reales. Si el producto usa Tailwind, internaliza su configuración y CSS del tema; si usa variables CSS para el color, debes traerlas o todo se renderizará sin color.
-
src/scenes/ProductScene.tsx— un objetoBexportado que contiene cada tiempo como un número de fotograma absoluto. Todo se lee de ahí: el DOM, la cámara, el sonido. Reajustar tiempos significa editar ese bloque y nada más.
Lee references/camera.md para el sistema de tomas, references/motion.md para
duraciones y tipografía.
Fase 5 — Audio
Dos pistas, dos archivos, dos etiquetas <Audio>: efectos y música. Mantenlas
separadas para que cualquiera pueda reemplazarse sin regenerar la otra.
Efectos — references/sound.md. La moderación es toda la disciplina: un
video de 45 segundos generalmente necesita de tres a cinco eventos en total. Un pop significa que algo
apareció, un swish significa que un elemento se movió dentro de la toma, un whoosh significa que la toma
se movió.
python3 <ruta-del-skill>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Música — references/music.md. Pregunta antes de construir una. La mayoría de la gente
tiene una opinión y muchos ya tienen una pista; preguntar cuesta una oración y puede
ahorrar todo el esfuerzo:
¿Quieres una banda musical? Si tienes una pista, envíala y cortaré al compás de ella. Si no, puedo sintetizar una — ¿enérgica, tranquila, cinematográfica, minimalista, cálida, o tensa?
Si tienen una pista, corta al compás de ella: encuentra su BPM, establece la línea de tiempo para que coincida, mueve los límites de las tomas a sus compases. De lo contrario, sintetiza una banda cuyo arreglo cambie en tus cortes al fotograma:
python3 <ruta-del-skill>/scripts/make_music.py music.spec.json public/music.wav
Pon una entrada sections en cada límite de toma real, una entrada hits en tu
corte más grande, y una entrada ducks debajo de cualquier línea sostenida que quieras que se lea
en lugar de que se sienta. Música a pico ~0.30, efectos a ~0.62. Elige el estado de ánimo según lo que el producto
es — un tema serio requiere una banda más tranquila, y un corte ocupado necesita una
más escasa.
Fase 6 — Verificar con imágenes fijas, antes de renderizar
Este es el ciclo rápido, y saltarlo desperdicia horas.
npx remotion still <CompositionId> out/f0700.png --frame=700
Luego mira realmente el PNG. Renderiza una imagen fija por toma, más una en cada transición. Verifica: ¿está el sujeto en el encuadre, está algo recortado a mitad de palabra, hay espacio muerto, encaja el texto.
Agrega una composición silenciosa (defaultProps: { withAudio: false }) para que las imágenes fijas
no necesiten que el archivo de audio exista.
Ajusta numéricamente siempre que puedas. Curvas de easing, distancias de desplazamiento, contenido espectral — todos son computables. Escribe un script de Python desechable que muestree la curva e imprima lo que de otro modo estarías adivinando. Es más rápido que un renderizado y es correcto.
Solo renderiza la versión completa una vez que las imágenes fijas sean correctas.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limita la concurrencia a aproximadamente 4 en una máquina de 16 GB — Remotion genera una pestaña de Chrome por ranura y el valor predeterminado (número de núcleos) hará intercambio.
Fase 7 — Entregarlo con honestidad
Envía el archivo. Luego di claramente:
- Lo que no pudiste verificar. Puedes leer imágenes fijas; no puedes juzgar cómo se sienten ocho segundos, y no puedes escuchar el audio. Dilo.
- Cualquier pantalla que reconstruiste en lugar de observaste — especialmente en un producto con restricciones. Enuméralas y ofrece rehacer esos tiempos si comparten acceso.
- Dónde tomaste una decisión subjetiva con la que podrían no estar de acuerdo.
- Cómo cambiar la música: coloca cualquier WAV o MP3 en
public/music.wavy vuelve a renderizar. - Cualquier cosa que encontraste en su producto mientras construías — un error de renderizado, una etiqueta incorrecta, un estado faltante. Acabas de leer su interfaz de usuario más cuidadosamente de lo que la mayoría de la gente jamás lo hará. Esa observación a menudo vale más que el video.
Archivos de referencia
Léelos cuando llegues a la fase correspondiente — son detallados y no tiene valor cargarlos todos de antemano.
| archivo | cuándo |
|---|---|
references/discovery.md | Fase 1 — navegación, clasificación de páginas, credenciales, sistemas de diseño, y construcción desde la página de aterrizaje de un producto restringido |
references/structure.md | Fase 2 — narrativa única vs capítulos, diseño de tarjetas de capítulo, escribir etiquetas de características, transiciones, orden |
references/camera.md | Construcción de tomas — espacio de diseño, cámara de punto de enfoque, corte vs push vs morph, aislamiento de componentes |
references/motion.md | Duraciones de animación, tipografía, patrones de gancho, el carrete de preguntas |
references/sound.md | Diseño de sonido — el vocabulario pop/swish/whoosh, moderación, sintetización de teclado y clics |
references/music.md | Obtener vs sintetizar una banda, elegir un estado de ánimo, alinear secciones a los cortes, mezclar debajo de los efectos |
references/pitfalls.md | Léelo antes de tu primer renderizado. Errores que cuestan horas reales, cada uno con la solución. |
Scripts incluidos
<ruta-del-skill> abajo es el directorio propio de este skill — la ruta que se te dio cuando
se cargó el skill. No asumas una ubicación de instalación fija; el skill puede estar instalado
personalmente, como un complemento, o verificado en un proyecto.
| script | qué hace |
|---|---|
scripts/scaffold_video.py | Crea el proyecto Remotion con bloqueos de versión funcionales y configuración |
scripts/make_sfx.py | Sintetiza una pista de efectos de sonido a partir de una lista de eventos JSON. Sin muestras, sin dependencias más allá de numpy. |
scripts/make_music.py | Sintetiza una banda musical en uno de seis estados de ánimo, con su arreglo alineado a tu corte. Mismas dependencias. |
assets/useCamera.ts | El hook de cámara de punto de enfoque — copia en src/hooks/ |
assets/ChapterCard.tsx | Tarjeta de capítulo para la forma con capítulos — copia en src/components/ |
La versión corta
Reconstruye en lugar de grabar. Una historia, un resultado — a menos que el producto esté restringido o sus características sean genuinamente separadas, entonces tres capítulos con etiquetas sencillas. Fundamenta cada hecho del dominio. Los fotogramas son la unidad de todo. Aísla un componente en lugar de recortar la página. El movimiento de la interfaz de usuario es de 150 a 300 ms, los movimientos de cámara son ~1 s. Cuatro sonidos es suficiente. Pregunta antes de hacer música. Mira las imágenes fijas antes de renderizar. Di lo que no pudiste verificar y lo que inferiste.