Video Forge
Créez un projet modifiable et une vidéo terminée. Utilisez la boîte à outils ensemble : HTML/GSAP, React, FFmpeg, enregistrements, SVG, sprites, images, audio et 3D. Choisissez les outils par scène ; préservez le moteur d'un projet existant. Les visuels sont créés en code ou proviennent de médias existants. Ne remplacez pas par des modèles génératifs vidéo/image ou des têtes parlantes. La synthèse vocale et la transcription de parole sont des outils audio autorisés.
Les chemins sont relatifs à ce répertoire, où qu'il soit installé. Aucun MCP privé, agent/modèle particulier, répertoire personnel de l'auteur ou service payant n'est requis par cette compétence.
Chemin d'or — pour une vidéo complète, faites exactement ceci
N'explorez PAS le code, ne créez PAS d'actifs à la main, ne paramétrez PAS les pixels à la main. Le code gère toute la mise en page, l'ajustement de la police et le calcul du timing de narration. Vous ne faites qu'éditer le texte et les paramètres dans un petit fichier JSON. Exécutez ces quatre étapes dans l'ordre :
# 1. Préparez l'environnement local UNE FOIS (Python local au projet + modèles audio)
python3 <skill-dir>/scripts/setup_environment.py --out .video-forge-tools --audio
# 2. Copiez le storyboard fourni ; éditez UNIQUEMENT son texte/secondes/couleurs/composants.
# Réécrivez tout le fichier avec Write — ne faites jamais d'éditions chirurgicales/par correspondance exacte.
cp <skill-dir>/assets/storyboard-production.json ./storyboard.json
# 3. Validez, puis rendez en MP4. run.py est LE point d'entrée : il sélectionne l'interpréteur
# préparé et les chemins des modèles, puis exécute voix→sous-titres→scènes→son→rendu→vérifications.
python3 <skill-dir>/scripts/build_project.py ./storyboard.json --check
python3 <skill-dir>/scripts/run.py ./storyboard.json --out ./film
# run.py BLOQUE jusqu'à ce que le MP4 soit terminé. En cas d'interruption, reprenez la MÊME commande avec
# --resume (ne recommencez pas). Si vos appels bash expirent, ajoutez --background et interrogez
# avec production_job.py status à la place.
# 4. Vérifiez le fichier réel
python3 <skill-dir>/scripts/verify_video.py ./film/out/final.mp4 --require-audio
Règles pour un modèle faible : le JSON du storyboard est la SEULE chose que vous éditez. N'appelez
jamais produce.py/build_project.py avec le python3 système pour la vidéo complète — passez
toujours par run.py. Ne modifiez jamais un fichier source .tsx/.py pour changer la taille, la
mise en page ou le texte ; passez-le plutôt en paramètre du storyboard. Si un titre ou une carte
semble incorrect, modifiez sa valeur JSON, pas son code — le calcul de mise en page est déterministe
et s'adapte déjà au cadre.
Commencez par le plus petit contexte utile
Lisez workflow. Déduisez les valeurs par défaut du brief et de la
marque/référence fournie. Ne demandez que ce qui manque pour les décisions. Pour un nouveau projet,
sauvegardez DESIGN.md et STORYBOARD.md : un objectif par scène, durée, moteur de rendu,
actif, mouvement de caméra et signal audio. Faites correspondre les dimensions/images par seconde
avant de mélanger les moteurs de rendu.
Pour une promotion complète/un tutoriel, la valeur par défaut est la recette de production
ci-dessus, pas l'ancien test fumée silencieux à quatre types. Lisez production direction
et partez de assets/storyboard-production.json. scripts/run.py exécute le plan
à travers la voix, les sous-titres mot à mot, les scènes cohérentes, le son, le rendu et les
vérifications d'export (il appelle produce.py pour vous avec l'interpréteur préparé). Si les
dépendances audio locales sont absentes, scripts/setup_environment.py --out .video-forge-tools --audio prépare un Python local au projet et rapporte les chemins des modèles. Cette configuration
est réutilisable dans différents environnements de codage ; elle ne nécessite pas l'environnement
privé de l'auteur. Voir production-direction.md.
Pour ce chemin, commencez par le brief et l'exemple de production ; exécutez le validateur et le producteur au lieu de parcourir chaque implémentation ou de vérifier chaque dépendance à l'avance. Le producteur signale les outils manquants et les actions concrètes de réparation. Lisez son code source uniquement lorsqu'une erreur observée nécessite un diagnostic. Le modèle pilote choisit le message et les paramètres de la scène ; le code éprouvé fournit le savoir-faire et l'exactitude. Ne considérez pas « il a rempli un JSON » comme un test de production de bout en bout.
Le mode réutilisation d'abord est la valeur par défaut : cherchez dans le catalogue, choisissez un composant démontré, renseignez ses props déclarées, effectuez un rendu court de preuve, puis composez. Lisez model-scaffolding lorsque l'agent rencontre des difficultés ou lorsqu'il construit une évaluation. Le code personnalisé est approprié lorsque le catalogue ne convient vraiment pas.
Cherchez dans le code réel avant d'inventer un mouvement
python3 <skill-dir>/scripts/catalog.py 'personnage'
python3 <skill-dir>/scripts/catalog.py 'sous-titre'
python3 <skill-dir>/scripts/catalog.py 'terminal'
Pour un brief qui correspond au vocabulaire titre/personnage/écran/3D du starter, faites remplir
par le modèle assets/storyboard-example.json en utilisant assets/storyboard.schema.json :
python3 <skill-dir>/scripts/build_project.py ./storyboard.json --check
python3 <skill-dir>/scripts/build_project.py ./storyboard.json --out ./ma-video
Le compilateur écrit le projet et uniquement les dépendances dont ses scènes choisies ont besoin.
Utilisez les valeurs par défaut réelles plutôt que d'inventer un schéma. Pour une vidéo complète,
utilisez le chemin d'or (run.py) plutôt que de vous arrêter à ce squelette silencieux nu.
Il prépare la parole réelle, aligne le script sur les durées ASR mesurées, intègre les temps
de sous-titres dans le rendu, maîtrise la bande sonore et exporte une feuille de contacts.
Voir catalogue de la bibliothèque. Sources incluses, avec licences amont :
library/vendor/rendercomp/: 50 scènes dessinées par code, typographie, transitions, graphiques et personnages SVG. Chaque composant exporte les valeurs par défaut, FPS et durée.library/vendor/curvable/: 14 scènes de lancement vidéo paramétrées ; inspectez les dépendances optionnelles shader/police/WASM avant d'utiliser un composant.library/vendor/onda/: composants, schémas Zod, transitions et aides à la composition. Analysez les valeurs par défaut via le schéma ; préservez les imports relatifs et chargez le thème/les polices.library/vendor/ffmpeg/: aides de montage Python locales exécutables : coupes, jonctions, zoom/re-cadrage, pixelisation/flou, sous-titres animés, étalonnage, mixage, silence, export et QA.library/vendor/blender/: aides Blender exécutables sans tête pour inspection, assemblage de scène, conversion, optimisation, cuisson et rendus. Nécessite Blender.
Ne lisez pas chaque bibliothèque à la fois. UPSTREAM.json enregistre la provenance et LICENSE
conserve les conditions amont. Leur code n'est pas automatiquement testé parce qu'il est inclus.
Aiguillez par le travail
| Travail | Lire / utiliser |
|---|---|
| Mouvement HTML, GSAP, blocs de registre | HyperFrames |
| Composition React / lots de données | Remotion, paramètres |
| Montage d'images, étalonnage, vitesse, audio, assemblage final | FFmpeg |
| Capture de navigateur/bureau, caméra curseur, zoom, censure | enregistrement d'écran |
| Personnages, illustrations, actifs 3D | personnages, approvisionnement en actifs |
| Géométrie procédurale, caméra, lumières, matériaux, armature | 3D |
| Narration, timings des mots, sous-titres animés, son | audio et sous-titres, conception sonore |
| Comparaison d'outils et plans multi-moteurs | routage |
Pour les clips téléchargés/libres de droits, utilisez pipeline média.
Pour les décisions de mouvement, utilisez principes de mouvement.
Consultez recherche pour les compétences/bibliothèques étudiées et
pourquoi elles conviennent. Voir bibliothèques externes (et
research/libraries-catalog.json) pour une carte de routage vérifiée sous licence : ce qui
est sûr d'inclure vs citer pour chaque type de travail. Le registre HyperFrames est une autre
source de réutilisation ; interrogez-le avant de construire un effet. Utilisez --help installé ;
son contrat peut différer de la compétence amont d'aujourd'hui.
La vérification fait partie de la production
Construisez l'image clé avant d'animer. Chaque image doit pouvoir être recherchée dans un ordre arbitraire : pas d'horloge murale, de randomisation non initialisée, de dépendance réseau en direct ou de boucle d'animation autonome. HyperFrames utilise des timelines mises en pause enregistrées ; Remotion utilise des images. Rendez des images représentatives et visualisez-les ; inspectez les entrées, les pauses, les limites de coupe, les changements de sous-titres et la fin. Corrigez le recadrage, le texte illisible, les blancs audio et la synchronisation.
Lorsqu'on vous demande une vidéo, exportez le fichier complet. Une image fixe n'est pas une fin.
python3 <skill-dir>/library/vendor/ffmpeg/scripts/probe.py final.mp4 --json
python3 <skill-dir>/scripts/verify_video.py final.mp4 --require-audio
python3 <skill-dir>/library/vendor/ffmpeg/scripts/look.py final.mp4 --tiles 3x2
Sondez ET décodez l'export final. Confirmez la durée prévue, les dimensions/images par seconde et l'audio. Inspectez réellement la feuille de contacts. Écoutez l'audio lorsque la lecture est disponible ; indiquez lorsque seules des vérifications techniques audio ont été possibles. Le masquage nécessite de vérifier chaque intervalle pertinent après les transformations de caméra, et de censurer l'audio s'il contient le secret.
Fournissez la vidéo lisible, le projet modifiable, les vérifications réelles et toute limitation réelle de dépendance. Préservez les originaux. Ne publiez/téléchargez pas, ne dépensez pas de crédits et n'installez pas de logiciel système à moins que la demande ne l'autorise. Une autorisation existante reste valide.
Discipline du modèle et des preuves
Utilisez des plans structurés, une petite liste restreinte, les valeurs par défaut du schéma et des aides exécutables pour réduire les décisions qu'un modèle plus faible doit inventer. Retournez les erreurs concrètes au modèle et modifiez la plus petite partie défaillante. Lisez évaluation pour les tests appariés de modèles fort/faible. Ne prétendez pas à la parité avec un modèle plus fort sans la mesurer. L'état de récupération appartient au projet, pas à une immense invite.
Notre propre code est MIT. Les moteurs/actifs/voix conservent leurs propres licences. Les outils optionnels sont installés uniquement lorsque nécessaire. Étudiez le workflow de référence de Katana, mais ne supposez jamais que les modèles hébergés de Higgsfield sont un moteur de rendu local ou que Katana desktop a une CLI.