Communitygithub.com

akmishra56/product-video-skill

Utiliza esta habilidad al crear un video de funcionalidad/demo/lanzamiento para una aplicación SaaS real o una app de código abierto en funcionamiento — construido a partir de grabaciones reales de pantalla de la aplicación, con locución, música y B-roll ligero creado con código, no un tráiler sintético de gráficos en movimiento.

¿Qué es product-video-skill?

Esta habilidad está diseñada específicamente para construir videos de demostración de productos reales, donde el material de archivo ya existe y no se puede redibujar para ajustarse a un plan. A diferencia de los tráilers sintéticos generados con herramientas como Remotion, que asumen que se controla cada píxel, este flujo de trabajo se centra en la captura real con Playwright, locución real generada por TTS y música de fondo con licencias libres. La habilidad guía al usuario a través de fases que incluyen la definición del brief, el análisis del sistema de diseño real de la aplicación, una auditoría de prototipos para momentos no capturables, la planificación del storyboard y la generación de locuciones y música. Todo el proceso se construye sobre la premisa de que la autenticidad del material real es clave: el video debe mostrar la aplicación tal como es, con sus propios tokens de diseño y UI, y nunca simular algo que no es real. Las plataformas soportadas incluyen aplicaciones web, extensiones de navegador y aplicaciones de escritorio capturables mediante Playwright, con estrategias específicas para cada caso. El resultado final es un video convincente y honesto que los espectadores pueden confiar porque muestra un producto real en acción.

Compatible con~Claude Code~Codex CLI~Cursor✓Gemini CLI
npx skills add https://github.com/akmishra56/product-video-skill/tree/main/skills/product-feature-video

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Habilidad de Video de Funcionalidad de Producto

Planifica y construye un video de demostración/funcionalidad para un producto real en funcionamiento — capturado en pantallas reales a través de Playwright, narrado con TTS real, musicalizado con una pista de fondo real (de código abierto, con licencia limpia) y ensamblado en Remotion. Esta es una disciplina diferente a la de un tráiler sintético de gráficos en movimiento: el material de archivo ya existe y no se puede redibujar para ajustarse a un plan, por lo que el plan debe ajustarse al material de archivo.

La diferencia clave con un tráiler sintético de gráficos en movimiento

Muchos flujos de trabajo de video en Remotion asumen que controlas cada píxel y que puedes reajustar cualquier cosa en cualquier momento, porque todo el video se construye desde cero: maquetas, fondos generados, UI inventados. Esa suposición no se sostiene aquí. Una grabación de pantalla real tiene su propio ritmo; un clic real ocurre en un fotograma específico, no cuando un storyboard lo requiere; algunos momentos (una ventana nativa del SO, la barra de herramientas del propio navegador, una interacción que se completa en medio segundo) no se pueden volver a filmar para ajustarse a un plan. Esta habilidad se basa en esa restricción desde cero — la artesanía del diseño de movimiento (easing, transiciones, densidad de movimiento) sigue siendo importante y se cubre en la Fase 8, pero la columna vertebral real del pipeline es lo que específicamente requiere un video impulsado por material de archivo: una auditoría de prototipos alternativos para los momentos no capturables, un enfoque de estabilidad verificado para zooms y énfasis de clics en material real, y una temporización impulsada por las duraciones reales de los activos en lugar de un plan.

Principio fundamental: material real primero, prototipo después, ilustración al final

Para cada escena, prefiere en este orden:

  1. Material real — una grabación real de Playwright de la aplicación real en funcionamiento.
  2. Un prototipo HTML revisado, capturado de la misma manera, para cualquier cosa que el material real no pueda mostrar estructuralmente (ver Fase 2).
  3. Un marcador de posición honesto y claramente ilustrado — solo cuando ninguno de los anteriores sea alcanzable aún, y solo si no pretende ser real.

Nunca finjas la opción 1 con la opción 3 disfrazada para parecer real. Un espectador confía en un video de demostración precisamente porque es real; un momento que parezca fabricado socava todos los genuinos.


Fase 0: Brief

Pregunta una vez, juntos, antes de cualquier otra cosa:

  1. Producto y repositorio — nombre, descripción en una línea, URL/ruta local a la aplicación o repositorio en funcionamiento.
  2. Audiencia y tono — quién lo ve, y ¿qué deberían sentir (impresionados / tranquilos / emocionados)?
  3. Duración — teaser de 30s, tutorial de 60-90s, o un recorrido más completo de 2-3 min. El material real se alarga rápido; sé honesto sobre el alcance.
  4. El momento que debe impactar — si el espectador recuerda exactamente una cosa, ¿cuál es? Esto se convierte en el clímax/tiempo fuerte.
  5. Inicio de sesión/cuenta de prueba — ¿capturar la aplicación requiere una cuenta? ¿Se puede crear una cuenta de demostración desechable, o ya existe una?
  6. Contexto de publicación — página de aterrizaje, YouTube, feed social (el muteo automático importa mucho para las decisiones de subtítulos/texto en pantalla).

Si el producto es una extensión de navegador, pregunta también si está en juego Manifest V3 (cambia la estrategia de lanzamiento de Playwright — ver Fase 6).


Fase 1: Reconocimiento — extrae el sistema de diseño real, no inventes uno

Antes de cualquier decisión estética, lee el producto real:

  • Obtén los tokens de color reales, la pila de fuentes y la escala de espaciado del archivo CSS/tema de la aplicación. Úsalos tal cual, incluso si el color de acento se parece a un cliché genérico de "SaaS de IA" (índigo/púrpura sobre casi negro es extremadamente común en paletas de productos reales también — solo es una señal de alerta cuando es un valor predeterminado inventado, no cuando es el producto real). La autenticidad supera a la novedad aquí.
  • Observa el texto de UI real del producto, la terminología y la arquitectura de la información — los subtítulos y la locución del video deben usar las propias palabras de la aplicación, no una paráfrasis de marketing.
  • Ejecuta la aplicación una vez, de principio a fin, como lo haría un usuario. Identifica: ¿cuál es la mejor interacción "estrella"? ¿Qué es genuinamente difícil de demostrar en vivo (ver Fase 2)?

Guarda los tokens extraídos (colores, fuentes) en un tokens.ts/tokens.css que todo el proyecto de video importe desde un solo lugar — cada escena, real o construida con código, debe pertenecer visiblemente al mismo producto.


Fase 2: Auditoría de Prototipos Alternativos (haz esto antes del storyboard)

Recorre la lista de funcionalidades planificadas y marca cualquier cosa que Playwright estructuralmente no pueda capturar:

  • Chrome del navegador a nivel de SO — el icono de la barra de herramientas de la extensión, chrome://extensions, menús contextuales de clic derecho, selectores de archivos nativos, diálogos nativos del SO. El recordVideo de Playwright solo captura el contenido de la página, nunca la UI del propio navegador.
  • Shells de escritorio nativos (Tauri, Electron una vez empaquetado, Qt, etc.) — no son una página web a la que Playwright pueda adjuntarse.
  • Interacciones demasiado rápidas o pequeñas para mostrarse de manera confiable — un cambio de alternancia que se completa en menos de medio segundo de material real es un mal objetivo para un zoom-recorte o un anillo de énfasis de clic; ambos necesitan una ventana estable de múltiples fotogramas para aterrizar (ver el patrón ZoomCue/ClickRing de la Fase 8 y su regla de estabilidad).

Para cada momento marcado, decide: material real con un trabajo alternativo (por ejemplo, sembrar estado a través de una llamada API en lugar de un clic real, según la Fase 6), un prototipo HTML revisado (Fase 7), o una ilustración etiquetada honestamente (último recurso, y dilo en un comentario de código).

Hacer esta auditoría antes del storyboard, no después, evita que el storyboard se comprometa con una temporización y cobertura que el paso de captura real no puede cumplir — esta fue la fuente más grande de retrabajo en las versiones v1-v3 de TabNemo.


Fase 3: Storyboard y Plan de Escenas

Arco narrativo

La misma forma funciona ya sea que el material sea real o sintético:

ActoPropósitoPorcentaje de duración
GanchoApertura en frío — el problema, o un momento impactante, antes de que aparezca el nombre del producto5-8%
RevelaciónEl nombre de la marca/producto aparece8-10%
Demostración3-5 funcionalidades reales, cada una en un momento45-55%
ClímaxEl momento estrella identificado en la Fase 0 — dale el mayor cuidado visual8-12%
CierreLogotipo, eslogan, CTA8-10%

Especificación por escena

Para cada escena, decide de antemano y escribe:

  • Fuente: clip real / captura de prototipo / B-roll construido con código (según la auditoría de la Fase 2).
  • Narración: texto exacto, o null. La duración de la narración es una restricción real — la duración del audio TTS se convierte en la longitud mínima de la escena (ver Fase 4).
  • El material real tiene su propio ritmo — el durationInFrames de una escena es máx(duración del clip real, duración de la narración), medido de los activos renderizados reales, nunca supuesto a partir de un plan. Cuando la narración supera al clip, mantén el último fotograma del clip en lugar de hacer un bucle o cortar la línea.
  • Plan de cámara: cualquier zoom o énfasis de clic, con coordenadas reales — decidido a partir de fotogramas reales, no adivinado (Fase 8).

Punto de control de revisión

Muestra la lista de escenas + el texto de la narración antes de grabar un solo clip o generar una nota de audio. Un plan basado en suposiciones incorrectas sobre el material disponible es costoso de deshacer una vez que existen los scripts TTS y Playwright.


Fase 4: Locución — guión y generación

Escribe dos documentos, no uno:

  1. Un guión de revisión — un bloque por escena, con su código de tiempo planificado, para que un humano pueda leer todo el arco de la narración y aprobar el ritmo antes de la generación.
  2. Un guión de entrada TTS — las mismas líneas, divididas una por archivo de escena, el ritmo llevado solo por puntuación (o etiquetas SSML <break>/<emphasis> si el motor las admite), para que cada escena se convierta en su propio clip de audio colocable en su propio desplazamiento.

Herramientas de generación

  • ttsmp3.com — gratuito, sin registro, respaldado por Amazon-Polly. Sin API pública, por lo que la generación es un clip a la vez a través de la UI del navegador — presupuesta una sesión enfocada para hacerlos todos, y nombra los archivos de salida por escena (scene-03.mp3, no tts_export_1.mp3).
  • Para un pipeline que necesita ejecutarse sin supervisión (CI, un agente sin navegador en el bucle), prefiere una opción de código abierto/local realmente scripteable en su lugar: Piper (completamente fuera de línea, licencia MIT, rápido, voces decentes) o edge-tts (envuelve las voces de lectura en voz alta de Microsoft Edge, gratuito, sin clave, scripteable, pero depende de un servicio externo que permanezca disponible). Gemini TTS y ElevenLabs son alternativas fuertes no abiertas si el costo de API es aceptable. Cualquier motor, si no garantiza consistencia de voz entre llamadas separadas, genera todos los segmentos en una sola solicitud con marcadores de pausa entre ellos, luego divide en el silencio detectado — ese único truco soluciona el problema de "voz diferente por línea" independientemente del motor.

Después de la generación — el audio es la fuente de verdad

Mide la duración real de cada archivo generado (no confíes en una estimación). Propaga las duraciones reales de vuelta a la temporización del plan de escenas. Este único paso evitó todos los errores de temporización en la construcción de TabNemo — la narración es contra lo que el oído del espectador mide una escena, por lo que ella, no el plan, establece el reloj.


Fase 5: Música de Fondo — consigue una pegadiza sin una mina terrestre de licencias

Un bucle de pad y drone plano suena como música de ascensor en espera, no como una base "pegadiza" — la diferencia es casi siempre un gancho melódico repetitivo, no solo pads armónicos. Tres opciones reales, en orden de "licencia más segura" a "más confiablemente pegadiza":

Opción A — Síntesis procedural (riesgo de licencia cero, necesita esfuerzo real para no sonar plano)

Genera un WAV estéreo corto y sin costuras en Node/Python simple — sin modelos, sin dependencias, sin ninguna cuestión de licencia, porque escribiste cada muestra. La receta concreta que funcionó:

  • Un bucle de acordes corto (8-16 compases) usando osciladores simples (seno/triángulo) con envolventes de ataque/lanzamiento lentos — esto solo es la trampa de la "música de ascensor"; NO es el gancho.
  • El gancho real: una melodía de cuerda pulsada Karplus-Strong montada encima, en un patrón rítmico repetitivo fijo, una octava por encima del pad — esto es lo que hace que un bucle sintetizado sea memorable en lugar de un wallpaper ambiental. No te saltes esta capa.
  • Un pulso suave de bombo y hi-hat debajo para movimiento hacia adelante, lo suficientemente silencioso para estar debajo de la narración.
  • Normaliza para dejar espacio de cabeza, la longitud del bucle elegida para que toda la progresión se complete en un límite de compás (sin costura audible).

Esto es completamente seguro para enviar comercialmente, pero la capa de gancho melódico es lo que separa "pegadizo" de "genérico" — presupuesta una iteración real en ello, y obtén una escucha y confirmación del usuario antes de conectarlo a un renderizado completo (regenerar un bucle de 15-20s es barato; rerenderizar todo el video para probar uno diferente no lo es).

Opción B — Modelos de música generativa de pesos abiertos (más "producido", verifica la licencia cada vez)

  • Stable Audio Open de Stability AI — pesos abiertos, guiado por texto, produce genuinamente arreglos completos con contenido melódico real. Los términos de licencia son más permisivos que la mayoría de los modelos de audio generativo, pero tienen condiciones basadas en ingresos — vuelve a leer la licencia actual antes de cualquier uso comercial, ya que estos términos cambian.
  • MusicGen de Meta (a través de la biblioteca audiocraft) — excelente calidad, pero sus pesos del modelo de música suelen tener licencia CC-BY-NC (no comercial) — no uses la salida generada en el video de lanzamiento de un producto monetizado sin aclararlo por separado.
  • Cualquiera puede ejecutarse localmente (GPU recomendada) o a través de un endpoint de inferencia alojado (Replicate, Hugging Face Spaces) si no hay cómputo local disponible.

Opción C (recomendada por defecto) — usa B para la idea, envía A para el activo

Guía un modelo de pesos abiertos localmente solo para inspiración ("gancho synth-pop pegadizo, ~110bpm, ambiente optimista de producto tecnológico"), escucha algunas generaciones hasta que encuentres un sentimiento general que te guste, luego usa ese sentimiento para diseñar la capa de gancho melódico en la Opción A. El resultado es memorable, reproducible sin ningún modelo, y 100% libre de riesgos de licencia.


Fase 6: Captura con Playwright

Estrategia de lanzamiento

  • Aplicación web: playwright.open() contra la URL de la aplicación.
  • Extensión de navegador (Manifest V2 o V3): lanza un navegador con la extensión cargada desde el lado del servidor (--disable-extensions-except / --load-extension). Para V3, la extensión podría necesitar ser inspeccionada primero desde el administrador de extensiones (que Playwright no puede ver — ver Fase 2) para habilitar el modo de desarrollador; una alternativa es deshabilitar temporalmente la verificación de firma de V3 para la prueba.
  • Aplicación de escritorio (Electron/Tauri): Playwright puede acoplarse a una ventana de Electron directamente (_electron.launch), pero Tauri requiere un paso separado para exponer su CoDriver/WebView.

Técnicas de captura

  • recordVideo: la API integrada de Playwright para la grabación de toda la página; produce un .webm con marca de tiempo.
  • page.screenshot + FFmpeg: para secuencias donde necesitas control de fotograma exacto (más sobre esto en la Fase 7 para prototipos).
  • Grabación en modo headless: siempre prefiere esto para CI/automatización; agrega --headless=new para la compatibilidad de extensiones de Chrome.

Siembra de estado

Los clics reales son lentos y frágiles. Donde sea posible, siembra el estado que debería ser el resultado del clic a través de una llamada API directamente, luego captura el estado sembrado. Esto es más rápido y confiable.


Fase 7: Construcción de B-Roll con Código y Prototipos

Prototipos HTML

Cuando el material real no pueda capturar algo (ver Fase 2), construye un pequeño HTML autónomo que demuestre la interacción. Este HTML debe:

  • Usar los tokens de diseño reales del producto (de la Fase 1).
  • Ser revisado por el usuario para verificar la fidelidad.
  • Luego capturarse con Playwright exactamente como un clip real.

B-roll construido con código

Para tomas puramente ilustrativas (sin pretender ser reales), usa código React/SVG dentro de Remotion para generar fondos animados, diagramas o animaciones de iconos. Estos deben ser visualmente distintos de los clips reales — una superposición sutil (p. ej., un ligero borde) o un comentario de audio puede dejar claro que esto es material ilustrativo.


Fase 8: Estilo Visual y Movimiento de Cámara

Patrón ZoomCue

  • Regla: No hagas zoom en un clip de material real a menos que el área de destino haya sido estable durante al menos 15 fotogramas consecutivos en el metraje real. Las UI modernas se mueven constantemente (capturas de desplazamiento, animaciones de expansión de menús); un zoom en un objetivo en movimiento produce un video con náuseas.
  • Implementación: Pre-renderiza el clip, encuentra el primer fotograma donde el área de interés es estable a través de un diff de fotogramas, luego programa el zoom para comenzar en ese fotograma.

Patrón ClickRing

  • Cuando un clic real necesita énfasis: superpone un anillo animado (círculo SVG con opacidad animada, escalando de 0.8x a 1.2x de su tamaño más pequeño) centrado en las coordenadas reales del clic. Las coordenadas se leen del registro de Playwright o se anotan manualmente a partir de una captura de pantalla.
  • Restricción: El anillo solo aparece mientras el área del clic es visible y estable — misma regla que ZoomCue.

Temporización de Transiciones

  • Los cortes entre escenas deben coincidir con el tempo de la música de fondo (en un tiempo fuerte, o en el flujo natural de la progresión de acordes).
  • Evita transiciones complejas (fundidos, barridos) en escenas de material real — el movimiento innato del metraje real no se beneficia de la decoración de transición y puede parecer discordante.

Fase 9: Renderizado Final y Exportación

Pipeline de salida

  1. Renderiza todos los clips de Playwright en .webm individuales (o archivos de fotogramas si se necesita control de fotograma exacto).
  2. Combina con locución, música de fondo y superposiciones de cámara en Remotion.
  3. Exporta a MP4 (H.264) para YouTube/redes sociales, o a GIF para demostraciones en línea ligeras.

Verificación de control de calidad

  • Lista de verificación: ¿el audio se sincroniza con la acción en pantalla? ¿Los subtítulos coinciden con la locución? ¿Todo el material real es realmente del producto? ¿Los tokens de diseño coinciden en todas las escenas?
  • Prueba de muteo: mira el video sin sonido — ¿tiene sentido la historia solo visualmente? Si no, agrega más texto en pantalla o reestructura las escenas.

Apéndice A: Stack de Herramientas de Referencia

PropósitoHerramientaNotas
Captura de pantallaPlaywrightAPI recordVideo o page.screenshot + FFmpeg
LocuciónPiper, edge-tts, ttsmp3.comPiper para offline/CI; ttsmp3 para una sesión rápida
Música de fondoSíntesis procedural (Opción A) o pesos abiertos (Opción B)Ver Fase 5 para detalles de licencia
Renderizado de videoRemotionReact-componentizado; usa @remotion/player para vista previa
Diseño de movimientoReact + SVG dentro de RemotionZooms, anillos, transiciones

Apéndice B: Ejemplo de Nomenclatura de Archivos

project-root/
├── scenes/
│   ├── scene-01.webm          # grabación de Playwright
│   ├── scene-01-narration.mp3 # archivo de locución
│   └── scene-01-tokens.ts     # definiciones de tokens de diseño
├── prototypes/
│   └── prototype-login.html   # prototipo HTML para partes no capturables
├── music/
│   └── bg-loop.wav            # bucle de música generado
└── Remotion/
    ├── src/
    │   ├── Video.tsx          # composición principal
    │   └── tokens.ts          # tokens de diseño importados
    └── package.json

Skills relacionados