Production vidéo Remotion
Transformer du matériel source en une vidéo cohérente et éditable. Créer la vidéo en React ; effectuer le rendu à partir des médias sauvegardés. Suivre les étapes ci-dessous, en s'adaptant aux instructions de l'utilisateur et au projet existant. Conserver un enregistrement de production concis afin qu'un autre agent puisse continuer sans avoir à reconstruire les décisions.
1. Inspecter le brief, les assets et les capacités
Identifier le public, le message clé visé, le format de livraison, le ton et les assets disponibles. Distinguer les faits sources, l'interprétation éditoriale et les informations non résolues ; ne pas inventer d'étapes factuelles, de capacités ou de résultats manquants. Extraire les assets volumineux intégrés avant de lire le document dans le contexte. Conserver une correspondance source-scène dans le projet de production.
Inspecter les images et enregistrements pertinents, pas seulement les noms de fichiers. Noter le cadrage, les étiquettes intégrées, le son et les actions réellement visibles. Vérifier si cet agent peut inspecter les images, entendre l'audio, exécuter du code et fournir un aperçu accessible à l'utilisateur. L'absence de capacité perceptuelle nécessite le recours aux procédures de repli dans references/runtime.md ; un script ne peut pas déterminer ces capacités du modèle ni remplacer le jugement humain.
Pour un projet Node existant, exécuter éventuellement node <skill-dir>/scripts/doctor.mjs <project-dir>. Il dresse l'inventaire des dépendances ; il ne prouve pas l'état de préparation au rendu. Utiliser le gestionnaire de paquets et le fichier de verrouillage du projet. Suivre la compétence Remotion des bonnes pratiques actuelle lorsqu'elle est disponible, sinon la documentation officielle.
2. Proposer une direction et clarifier uniquement les incertitudes significatives
Donner une direction recommandée : public/message clé, durée approximative et format d'image, progression des scènes, ton visuel et approche narrative. Expliquer comment la source et l'objectif de visualisation l'ont informée. Pour les choix de structure et de style, utiliser references/editorial.md.
Poser un petit nombre de questions ciblées lorsque les réponses modifieraient le contenu factuel, le public, la direction ou l'utilisation d'assets indisponibles. Ne pas répéter les questions déjà répondues ni exiger un questionnaire pour chaque travail. Continuer le travail indépendant en attendant ; les faits essentiels non résolus ne doivent pas être inventés. Si des préférences optionnelles restent non spécifiées, énoncer des hypothèses raisonnables et procéder dans le cadre de l'autorisation de l'utilisateur.
3. Rédiger un storyboard compact
Pour chaque scène, enregistrer son but, les preuves source, les paroles prononcées, l'accent visuel à l'écran, le mouvement visuel/audio prévu et la durée approximative. Garder la narration distincte des titres et légendes. Lister les faits non résolus séparément. Traiter le storyboard comme un document éditorial, pas comme un nouveau langage de programmation. Tester une séquence représentative tôt si la direction visuelle ou audio est incertaine.
4. Préparer les médias et le timing mesuré
Attribuer à chaque type de média un adaptateur approprié. Une demande de discours et une demande de génération vidéo n'ont pas besoin de partager une forme d'entrée. Normaliser leurs résultats en fichiers sauvegardés et métadonnées utiles, incluant la durée, les dimensions, les paramètres de génération, la provenance et l'attribution requise le cas échéant.
Résoudre la génération des médias avant de prévisualiser ou d'effectuer le rendu. Mettre en cache les sorties par contenu d'entrée et paramètres effectifs du fournisseur, et vérifier les fichiers en cache. Ne pas déclencher de génération payante ou non déterministe à partir des fonctions de rendu React ou de l'évaluation des métadonnées.
Pour la narration, séparer le texte affiché du texte de prononciation lorsque nécessaire. Mesurer la durée audio réelle, puis laisser suffisamment de temps pour que l'image et le texte associés soient compris. Utiliser le timing par phrase ou par phrase lorsque cela suffit. La mise en évidence des mots nécessite des horodatages ou un alignement fiables ; répartir uniformément les caractères n'est pas un alignement précis.
Pour les enregistrements existants, préserver ou couper délibérément le son original et dériver les sous-titres d'une transcription. Prendre en compte les décalages de scène, l'intro audio, les pauses et les transitions qui se chevauchent. Utiliser references/pipeline.md pour les contrats d'adaptateur, de timing, de cache et de révision. Des aides optionnelles groupées extraient les images intégrées et valident les plages de sous-titres ; l'utilisation et les limitations sont dans references/runtime.md.
5. Implémenter en React/TypeScript ordinaire
Réutiliser de petits composants pour les traitements récurrents et permettre du React arbitraire pour les scènes spécifiques au sujet. Les données peuvent contenir du texte, des chemins de médias, le timing, des références sources et des jetons de conception. Introduire un schéma de template uniquement lorsque la sortie répétée d'un format connu le justifie. Ne pas créer d'interpréteur de timeline général, de registre de plugins ou de service d'orchestration pour une vidéo locale.
Piloter le mouvement à partir des numéros d'image ; éviter les minuteries basées sur l'horloge murale et l'aléatoire non contrôlé. Charger les polices et assets requis localement. Le style peut modifier la typographie, la composition, le mouvement, le texte d'accentuation, le rythme et l'audio ; modifier uniquement une palette n'est pas un changement de style complet. Réutiliser les médias et le timing approuvés lorsque seule la présentation change.
Exécuter des vérifications ciblées de type, d'asset, de durée et de sous-titres. Utiliser le check-captions.mjs fourni uniquement pour son contrat de timing documenté. Les tests doivent porter sur la logique réutilisable de timing, d'import et de cache, pas sur chaque décision esthétique. Privilégier les composants existants et les petites modifications vérifiées lorsque l'agent a une capacité de codage limitée.
6. Prévisualiser avant de consacrer du temps à l'exportation finale
Privilégier Remotion Studio lorsque l'utilisateur peut y accéder. Montrer la composition et expliquer ce qui doit être révisé : fidélité à la source, style, recadrage du texte/sujet, lisibilité des sous-titres, mouvement et son. Inspecter les scènes représentatives, les limites et la fin vous-même, si pris en charge. Lorsque l'utilisateur a demandé une révision avant l'exportation, fournir l'aperçu et attendre cette révision avant l'exportation finale. Une approbation existante ou une demande explicite de rendu peut autoriser la poursuite ; ne pas ajouter de porte de confirmation inconditionnelle.
Si Studio interactif n'est pas disponible, produire des images fixes représentatives et, lorsque le mouvement/l'audio nécessite une révision, un brouillon basse résolution court. Une URL localhost d'un environnement distant peut être inaccessible à l'utilisateur ; fournir un aperçu accessible ou un artefact local. Les images fixes n'établissent pas la qualité du mouvement ni de l'audio. Appliquer les procédures de repli de révision humaine dans references/runtime.md et signaler exactement ce qui a été et n'a pas été révisé.
7. Exporter, vérifier et livrer
Une fois toute révision demandée terminée, utiliser le CLI Remotion installé du projet pour l'exportation de routine. Voir references/runtime.md pour les commandes npx. Utiliser l'API de rendu uniquement lorsque l'intégration programmatique ou le traitement par lots le justifie. Préserver les modifications de l'utilisateur et ne régénérer que les médias affectés lors de la révision.
Vérifier les dimensions, la fréquence d'images, la durée, la présence audio, la première/dernière image, les changements de sous-titres et les limites de scène du fichier exporté. Lire le résultat complet lorsque la révision perceptuelle est disponible ; sinon identifier la révision humaine restante. Un rendu réussi ou un décodage audio n'établit pas la qualité éditoriale, la prononciation correcte ou un mix agréable. La révision de l'aperçu et la vérification du fichier final sont des preuves distinctes.
Livrer le projet éditable, l'emplacement de l'aperçu/exportation, les commandes de reproduction et un état concis : implémenté, aperçu vérifié, révisé par l'utilisateur, exporté, fichier final vérifié. Ne déclarer que les étapes terminées. Conserver l'enregistrement de production avec la production.
Garder les conseils réutilisables indépendants des productions
Les compétences et exemples distribuables doivent être autonomes et neutres en termes de sujet. Garder le texte source privé, les images, l'audio, les noms, les liens, les identifiants, les chemins de fichiers et les instructions spécifiques à la production dans le projet de production. Ne pas les inclure dans une compétence réutilisable, ses métadonnées, références, fixtures ou assets. Utiliser des exemples nouvellement inventés si un exemple est nécessaire.
Documenter les méthodes et critères de décision appris d'une production sans coder son sujet comme une exigence universelle. Vérifier le contenu réel du paquet de la compétence avant de le partager ou de l'installer.