Lancement vidéo
Transformez un produit réel en une histoire visuelle claire : ce qui fait mal, ce qui change, comment cela fonctionne et que faire ensuite. Utilisez HyperFrames comme moteur. Gardez le modèle sélectionné par l'utilisateur comme gestionnaire. Ne remplacez pas le moteur et ne créez pas d'éditeur vidéo, de bibliothèque de modèles ou de framework d'animation.
1. Établir le brief
Lisez d'abord le brief, le produit, les actifs et le projet existant fournis par l'utilisateur. Reprenez le travail existant. Ne demandez que les faits manquants qui changeraient la vidéo ; ne répétez pas les questions déjà répondues. Un simple nom de produit ne constitue pas une preuve suffisante pour des affirmations de fonctionnalités. En cas d'entrée limitée, déterminez le public, la promesse utile et l'action de clôture avant d'écrire le storyboard.
Pour une URL fournie, inspectez le produit réel et les sources officielles de la marque. Utilisez HyperFrames capture le cas échéant ; suivez les règles de capture en cas d'échec définies dans upstream.md. N'inventez jamais de site de remplacement en cas d'échec de capture. Pour une vidéo de type « montrez-le tel quel », utilisez l'écran réel comme base. Conservez la copie exacte fournie sauf si une modification est autorisée. Enregistrez les affirmations, les sources, les droits d'actifs et toutes les hypothèses dans un court fichier BRIEF.md dans le projet vidéo. N'incluez jamais de contenu privé dans une démo publique sans autorisation.
Utilisez les couleurs, la typographie, la densité et l'interface utilisateur réelles du produit. Choisissez une direction visuelle spécifique avec un mouvement significatif, un texte lisible et un rythme réfléchi. Lisez les références créatives et de mouvement en amont de manière sélective. La étude de référence illustre des techniques, pas un style imposé. Un exemple fictif doit être explicitement étiqueté ; ne le transformez pas en résultat client réel implicite.
2. Préparer le projet
Lisez upstream.md et vérifiez la source épinglée et le CLI avant de vous y fier. Utilisez le contrat de composition HTML en amont, les diagnostics et le rendu. Lisez uniquement les références de domaine nécessaires ; ne copiez pas tout l'arbre source dans le livrable et ne mettez pas à jour en silence vers la dernière version.
Créez un projet vidéo dédié. Définissez project.json en utilisant project-format.md. Convenez des dimensions de sortie, de la fréquence d'images, de la durée et du choix audio dans le storyboard. Pour X, vérifiez les exigences officielles de téléchargement actuelles avant de sélectionner l'exportation. Par défaut, optez pour un film court et adapté au son coupé ; n'achetez pas de médias et n'invoquez pas de fournisseur vocal payant sans autorisation. Les actifs manquants nécessitent un remplacement local et sous licence cohérent avec le brief ou une question concrète, jamais un espace réservé cassé.
3. Concevoir, montrer et obtenir l'approbation
Rédigez un script concis : une idée claire par scène, des preuves réelles du produit, un résultat utile. Créez une trame HTML statique et conçue complète pour chaque scène avec la copie, la mise en page, la palette et les actifs réellement proposés. Les descriptions textuelles et les boîtes fil de fer seuls ne sont pas l'artefact de révision. Gardez un exemple de produit continu tout au long du film. Montrez l'interface utilisateur importante à une échelle lisible et laissez le temps de comprendre chaque action.
Chaque trame doit être du HTML statique autonome avec CSS en ligne. Utilisez des actifs d'image/police locaux et déclarés ; voir la référence de format. Vérifiez les trames à la taille de sortie complète et à l'échelle du fil. Incluez le titre exact, la narration optionnelle, la durée et le mouvement prévu dans project.json, puis exécutez :
python3 <SKILL_DIR>/scripts/launch_video.py storyboard <PROJECT_DIR>
Ouvrez le fichier storyboard.html résultant pour l'utilisateur. Examinez chaque trame vous-même d'abord. Demandez l'approbation de la version affichée, ou des modifications spécifiques à une scène. Attendez l'approbation explicite de l'utilisateur avant l'animation complète ou le rendu. Le silence, un « oui » générique antérieur, l'acceptation de l'idée de construction et le mode automatique n'approuvent pas un storyboard non visualisé. Une sonde de rendu technique neutre est autorisée avant cette étape.
Après que l'utilisateur approuve la version affichée, enregistrez sa décision réelle :
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>
Le reçu lie le manifeste, les octets des trames, les actifs et le storyboard généré. Il enregistre une décision humaine ; il n'authentifie pas l'intervenant ni n'interprète si un texte arbitraire signifie une approbation. Ne fabriquez jamais de reçu. Gardez les enregistrements d'approbation privés par défaut.
4. Animer l'histoire approuvée
Utilisez les règles d'animation et les plans d'HyperFrames épinglés. Réutilisez les trames conçues approuvées comme base de composition. Chaque scène doit révéler une action et un résultat réels ; le mouvement doit soutenir l'histoire. Utilisez des timelines sécurisées. Lisez la règle en amont pertinente avant d'implémenter une technique. Faites correspondre la position, l'échelle, la direction et l'opacité à travers une transition continue. Évitez le mouvement qui obscurcit le produit ou qui flash rapidement.
Créez index.html et une sous-composition par scène approuvée comme spécifié dans la référence de format. Gardez les identifiants/l'ordre, le texte exact, le timing, les dimensions et l'identité des actifs fidèles au storyboard approuvé. L'outil d'assistance vérifie la structure, le texte et le timing ; inspectez les visuels et les actifs vous-même. Il ne peut pas prouver la fidélité sémantique à partir de la seule source. Ne modifiez pas les trames approuvées pour masquer une dérive.
Un changement demandé dans l'histoire, la copie, l'actif, la mise en page, la durée ou l'audio nécessite un storyboard révisé et une nouvelle approbation. Conservez la version précédente. Les réparations de mouvement qui mettent en œuvre l'intention déjà approuvée peuvent se poursuivre, puis réexécutez les vérifications concernées. Si vous travaillez avec des agents, donnez à chacun une scène exacte et une propriété de fichier non chevauchante ; le gestionnaire possède la composition et l'assurance qualité.
5. Inspecter, rendre et livrer
Utilisez le CLI épinglé depuis le répertoire du projet pour lint, check, keyframes . --json et snapshot --at <scene-midpoints-and-transition-boundaries>. Inspectez chaque scène, le début/la fin et les deux côtés de chaque coupe. Ouvrez preview --background et regardez le mouvement complet à vitesse normale. Vérifiez la lisibilité, le timing, le chevauchement, le découpage, le chargement des actifs, la continuité des transitions et la compréhension sans son. Pour l'audio, vérifiez également les droits, la synchronisation, le clipping et la fin. Le succès des vérifications statiques ne prouve pas la qualité visuelle.
Après l'approbation et l'assurance qualité visuelle pré-rendu, effectuez le rendu via l'outil d'assistance :
python3 <SKILL_DIR>/scripts/launch_video.py render <PROJECT_DIR> --output output/video.mp4
Cela invoque HyperFrames 0.8.37 et ffprobe, vérifie l'exportation par rapport aux dimensions/fps/durée/audio approuvés et écrit un reçu .qa.json. Son statut d'assurance qualité visuelle reste en attente : inspectez le MP4 réel, extrayez des trames représentatives et regardez la lecture complète avant la livraison. Rapportez les preuves séparément du jugement. Ne marquez pas le résultat comme terminé parce que l'encodage a réussi.
En cas d'échec, lisez l'erreur, corrigez sa cause concrète et répétez la vérification concernée. Conservez les vidéos existantes ; choisissez un nouveau chemin de sortie après avoir inspecté un rendu partiel échoué. Ne changez jamais de moteur, n'utilisez pas une ancienne sortie comme nouveau résultat et ne cachez pas une capacité manquante. En cas de blocage, indiquez ce qui reste et fournissez le travail déjà effectué et révisable.
Livrez le MP4, le storyboard conçu, les identifiants de scène pour les révisions, les dimensions/durée/audio, les commandes reproductibles et les notes d'assurance qualité honnêtes. Publiez uniquement sur demande. Ne promettez pas un résultat « viral », une qualité du premier coup ou des économies de temps/token non mesurées.