Video de lanzamiento
Convierte un producto real en una historia visual clara: qué duele, qué cambia, cómo funciona y qué hacer a continuación. Usa HyperFrames como motor. Mantén al modelo seleccionado por el usuario como gestor. No reemplaces el motor ni crees un editor de video, biblioteca de plantillas o marco de animación.
1. Fundamenta el briefing
Lee primero el briefing, producto, activos y proyecto existente proporcionados por el usuario. Reanuda el trabajo existente. Pregunta solo por hechos faltantes que cambiarían el video; no repitas preguntas ya respondidas. Un nombre de producto por sí solo no es evidencia suficiente para afirmaciones de características. Con información escasa, resuelve la audiencia, la promesa útil y la acción de cierre antes de escribir el storyboard.
Para una URL proporcionada, inspecciona el producto real y las fuentes oficiales de la marca. Usa la captura de HyperFrames cuando sea apropiado; sigue las reglas de fallo de captura fijadas en upstream.md. Nunca inventes un sitio de reemplazo cuando la captura falle. Para un video de mostrar-tal-como-es, usa la pantalla real como base. Conserva la copia exacta proporcionada a menos que se autorice la edición. Registra afirmaciones, fuentes, derechos de activos y cualquier suposición en un breve BRIEF.md en el proyecto de video. Nunca incluyas material privado en una demo pública sin autorización.
Usa los colores, tipo, densidad y UI real del producto. Elige una dirección visual específica con movimiento significativo, tipo legible y ritmo deliberado. Lee las referencias creativas y de movimiento ascendentes selectivamente. El estudio de referencia ilustra técnicas, no un estilo de casa obligatorio. Un ejemplo ficticio debe estar explícitamente etiquetado; no lo conviertas en un resultado de cliente real implícito.
2. Prepara el proyecto
Lee upstream.md y verifica la fuente fijada y la CLI antes de confiar en ellas. Usa el contrato de composición HTML ascendente, diagnósticos y renderizado. Lee solo las referencias de dominio necesarias; no copies todo el árbol fuente en el entregable ni actualices silenciosamente a la última versión.
Crea un proyecto de video dedicado. Define project.json usando project-format.md. Acuerda las dimensiones de salida, velocidad de fotogramas, duración y elección de audio en el storyboard. Para X, verifica los requisitos oficiales de carga actuales antes de seleccionar la exportación. Por defecto, crea una película corta y compatible con sonido apagado; no compres medios ni invoques un proveedor de voz de pago sin autorización. Los activos faltantes requieren un reemplazo local y licenciado coherente con el briefing o una pregunta concreta, nunca un marcador de posición roto.
3. Diseña, muestra y obtén aprobación
Escribe un guion ajustado: una idea clara por escena, evidencia real del producto, un beneficio útil. Crea un fotograma HTML estático y diseñado completo para cada escena con la copia, diseño, paleta y activos reales propuestos. Las descripciones de texto y los cuadros de wireframe por sí solos no son el artefacto de revisión. Mantén un ejemplo de producto continuo a lo largo de la película. Muestra la UI importante a una escala legible y deja tiempo para entender cada acción.
Cada fotograma debe ser HTML estático autocontenido con CSS en línea. Usa activos de imagen/fuente locales y declarados; consulta la referencia de formato. Verifica los fotogramas al tamaño de salida completo y a escala de feed. Incluye el título exacto, la narración opcional, la duración y el movimiento previsto en project.json, luego ejecuta:
python3 <SKILL_DIR>/scripts/launch_video.py storyboard <PROJECT_DIR>
Abre el storyboard.html resultante para el usuario. Revisa cada fotograma tú mismo primero. Solicita la aprobación de la versión mostrada, o cambios específicos por escena. Espera la aprobación explícita del usuario antes de la animación o renderizado completos. El silencio, un "sí" genérico anterior, la aceptación de la idea de compilación y el modo automático no aprueban un storyboard no visto. Se permite una sonda de renderizado técnico neutral antes de esta compuerta.
Solo después de que el usuario apruebe la versión mostrada, registra su decisión real:
python3 <SKILL_DIR>/scripts/launch_video.py record-approval <PROJECT_DIR> \
--version <DISPLAYED_SHA256> --approver <USER_NAME> --decision '<ACTUAL_APPROVAL_TEXT>'
python3 <SKILL_DIR>/scripts/launch_video.py check-approval <PROJECT_DIR>
El recibo vincula el manifiesto, los bytes del fotograma, los activos y el storyboard generado. Registra una decisión humana; no autentica al hablante ni interpreta si un texto arbitrario significa aprobación. Nunca fabriques un recibo. Mantén los registros de aprobación privados por defecto.
4. Anima la historia aprobada
Usa las reglas y planos de animación de HyperFrames fijados. Reutiliza los fotogramas diseñados aprobados como base de composición. Cada escena debe revelar una acción y resultado reales; el movimiento debe apoyar la historia. Usa líneas de tiempo seguras para búsqueda. Lee la regla ascendente relevante antes de implementar una técnica. Iguala posición, escala, dirección y opacidad a lo largo de una transición continua. Evita el movimiento que oscurezca el producto o parpadee rápidamente.
Crea index.html y una subcomposición por escena aprobada según lo especificado en la referencia de formato. Mantén IDs/orden, texto exacto, temporización, dimensiones e identidad de activos fieles al tablero aprobado. El ayudante verifica estructura, texto y temporización; inspecciona los visuales y activos tú mismo. No puede probar la fidelidad semántica solo a partir de la fuente. No edites fotogramas aprobados para ocultar desviaciones.
Un cambio solicitado en historia, copia, activo, diseño, duración o audio requiere un storyboard revisado y una nueva aprobación. Conserva la versión anterior. Las reparaciones de movimiento que implementan la intención ya aprobada pueden proceder, luego vuelve a ejecutar las comprobaciones afectadas. Si trabajas con agentes, asigna a cada uno una escena exacta y propiedad de archivos no superpuesta; el gestor es dueño de la composición y el control de calidad.
5. Inspecciona, renderiza y entrega
Usa la CLI fijada desde el directorio del proyecto para lint, check, keyframes . --json y snapshot --at <scene-midpoints-and-transition-boundaries>. Inspecciona cada escena, el inicio/final y ambos lados de cada corte. Abre preview --background y observa el movimiento completo a velocidad normal. Verifica legibilidad, temporización, superposición, recorte, carga de activos, continuidad de transición y comprensión con sonido apagado. Para audio, también verifica derechos, sincronización, recorte y el final. Pasar comprobaciones estáticas no prueba la calidad visual.
Después de la aprobación y el control de calidad visual previo al renderizado, renderiza a través del ayudante:
python3 <SKILL_DIR>/scripts/launch_video.py render <PROJECT_DIR> --output output/video.mp4
Esto invoca HyperFrames 0.8.37 y ffprobe, verifica la exportación contra las dimensiones/fps/duración/audio aprobados y escribe un recibo .qa.json. Su estado de control de calidad visual permanece pendiente: inspecciona el MP4 real, extrae fotogramas representativos y observa la reproducción completa antes de la entrega. Reporta la evidencia por separado del juicio. No marques el resultado como terminado porque la codificación haya tenido éxito.
En caso de fallo, lee el error, corrige su causa concreta y repite la comprobación afectada. Conserva los videos existentes; elige una nueva ruta de salida después de inspeccionar un renderizado fallido parcial. Nunca cambies de motor, uses una salida anterior como nuevo resultado ni ocultes una capacidad faltante. Si estás bloqueado, indica lo que queda y proporciona el trabajo revisable ya completado.
Entrega el MP4, el storyboard diseñado, los IDs de escena para revisiones, las dimensiones/duración/audio, los comandos reproducibles y notas honestas de control de calidad. Publica solo cuando se solicite. No prometas "viral", calidad de un solo intento ni ahorros de tiempo/token no medidos.