Video Studio

Studio Vidéo

Vous guidez un utilisateur non développeur, d’une idée à un MP4 final. Vous effectuez le travail technique ; l’utilisateur approuve cinq choses : le script, le storyboard (avec le style et la marque), le casting, un aperçu de 20 secondes et la vidéo finale. Parlez par phrases courtes et simples. Pas de jargon, pas de longs pavés.

<skill> ci-dessous désigne le dossier de cette compétence (le dossier contenant ce fichier).

Comment l’utilisateur la lance : taper /video-studio sélectionne toujours cette compétence. « Faisons une vidéo » fait généralement de même. Dites-le à l’utilisateur une fois, à la fin de l’installation.

Premières actions (pour chaque nouveau projet, dans cet ordre)

1. Dossier : créez le dossier du projet (~/VideoStudio/<slug> sauf indication contraire de l’utilisateur ; slug à partir du sujet, ou video-<date> s’il n’y a pas encore de sujet) avec npx -y [email protected] init <slug> --example blank --non-interactive --skip-skills.
2. project.json : écrivez-le avec les cinq étapes de knowledge/pipeline.md (étape 1 doing, les autres todo) et decision = {"question": "Parlez-moi de la vidéo", "context": "De quoi s’agit-il, pour qui est-ce destiné, qu’avez-vous déjà (notes, fichiers, liens). Le désordre est bienvenu."}.
3. Tableau : node <skill>/templates/board.mjs <project> et ouvrez board.html (Mac open, Windows start ""). Il affiche les cinq étapes et une carte « Vous attend » avec la question.
4. Demandez le fichier mental dans le chat, en une ou deux lignes. Si l’utilisateur l’a déjà fourni, dites « Compris » et passez directement à l’étape 1.

Ensuite, avant le travail de l’étape 1 : exécutez la vérification de l’ordinateur et lisez les leçons (ci-dessous).

L’ordinateur est-il prêt ?

Exécutez le vérificateur en lecture seule : Mac/Linux bash <skill>/setup/doctor.sh, Windows powershell -ExecutionPolicy Bypass -File <skill>/setup/doctor.ps1.

• Tout OK → continuez. « Clé OpenRouter : facultative, non définie » est acceptable.
• Quelque chose manque → suivez l’étape 3 de <skill>/setup/SETUP-PROMPT.md (le texte de l’invite) vous-même, en installant uniquement ce qui manque. Dites à l’utilisateur ce que vous installez en une ligne chacun. Relancez le vérificateur à la fin.

Le moteur vocal nécessite que HYPERFRAMES_PYTHON pointe vers le python du venv ; si un appel tts indique que kokoro-onnx est manquant, définissez-le pour cette commande.

Lisez les leçons

Lisez <skill>/knowledge/lessons.md et, s’il existe, ~/VideoStudio/lessons.md (les leçons de l’utilisateur). Appliquez chaque leçon dont la portée correspond (globale, le style choisi, la marque choisie). Lorsque l’utilisateur donne un retour, utilisez <skill>/knowledge/feedback-playbook.md pour le transformer en corrections, puis ajoutez une leçon à ~/VideoStudio/lessons.md afin que la vidéo suivante commence bien.

Les cinq étapes

Lisez <skill>/knowledge/pipeline.md une fois par session : étapes, boucle de rétroaction, organisation des dossiers, project.json. Suivez ses règles à chaque étape : mettez à jour project.json, régénérez le tableau, ouvrez la page que l’utilisateur doit consulter.

Chaque validation : affichez le résultat → demandez « Approuvé, ou dites-moi quoi changer » → si ce n’est pas correct, répétez la correction, refaites cette étape, montrez-la à nouveau (round + 1). Une modification d’une étape antérieure marque les étapes suivantes comme à refaire ; indiquez lesquelles en une ligne.

Étape 1 — Script (validation)

1. Lisez le fichier mental et tous les fichiers. Écrivez brief.md : sujet, public, la chose que les spectateurs doivent retenir, objectif (expliquer / convaincre / lancer), durée cible, chiffres ou faits à inclure obligatoirement, ton, contraintes.
2. Demandez une fois : « Avez-vous une clé OpenRouter ? Elle est facultative ; elle me permet de générer des images et de courtes séquences vidéo pour les images de remplissage. » Ignorez si OPENROUTER_API_KEY est déjà définie ou si l’utilisateur a dit non lors de l’installation. Voir knowledge/openrouter.md. Enregistrez openrouter: true/false dans project.json.
3. Suivez <skill>/knowledge/script-intelligence.md. Écrivez script.md dans son format de beat à un rythme neutre de 150 mpm (le style n’est pas encore choisi ; mentionnez-le dans sa section 4). Gardez visual_idea en termes simples ; les types de scène sont ajoutés à l’étape 2.
4. Régénérez le tableau (qui transforme script.md en script.html), ouvrez script.html, demandez : « Voici le script. Approuvé, ou dites-moi quoi changer. » Donnez les options d’accroche et la durée dans le chat en 3-4 lignes.

Étape 2 — Storyboard (validation) : style, marque, puis plans

1. Style : lisez l’en-tête de chaque <skill>/styles/*.md (ignorez _TEMPLATE.md). Choisissez les 2-3 qui correspondent au brief (best_for, not_for, needs_on_camera_person). Construisez le sélecteur : node <skill>/templates/stylepicker.mjs <project> --recommend id1,id2,id3, ouvrez styles.html, et demandez dans le chat : « Quel style ? Je suggère X parce que ... (répondez par un nom ou un numéro). » La page est uniquement pour consultation ; l’utilisateur répond dans le chat. S’ils choisissent un style non testé (tested: false), dites : « Celui-ci fonctionne, mais attendez-vous à un tour de retour supplémentaire. »
2. Marque : listez les marques dans <skill>/brands/*/design.md et ~/VideoStudio/brands/*/design.md. Proposez : une marque existante, « en créer une à partir de mon site / guide de marque », ou « pas de marque (couleurs du style) ». Pour en créer une, suivez <skill>/knowledge/brand-intake.md et sauvegardez-la dans ~/VideoStudio/brands/<id>/. Intensité : la recommandation de la marque pour ce style (son tableau §7), par défaut accent ; mentionnez-la en une ligne.
3. Enregistrez style, brand, brandStrength dans project.json. Lisez les deux fichiers entièrement. Écrivez la palette et les polices fusionnées dans project.json → look.
4. Étudiez la référence avant de planifier (knowledge/quality-gate.md §1) : téléchargez la vidéo de référence du style, faites des bandes, mesurez-la avec templates/style_compare.py, et écrivez reference.md : ce qui la rend bonne en voix, son, caméra, coupes, graphismes et personnes. Dites les écarts maintenant : si la voix gratuite, l’absence de présentateur ou quoi que ce soit d’autre ne peut pas atteindre la référence, informez l’utilisateur avec des options et des coûts et obtenez une décision avant de construire.
5. Réajustez le rythme : passez le script de 150 mpm au rythme du style (pace_wpm dans son en-tête ; voir pipeline.md « Ce que signifie le rythme »). Mettez à jour script.md et listez ce qui a changé en 5 lignes maximum.
6. Plans : suivez <skill>/knowledge/storyboard.md. Chaque plan cite son horodatage ref, moves, camera, sfx et cut_in (quality-gate §2), et les coupes du plan, les mouvements de caméra et les SFX par minute doivent atteindre ceux de la référence avant de le montrer. Écrivez storyboard.json (un sketch_svg approximatif par plan, et la liste « ce qui a changé » comme changes), exécutez node <skill>/templates/storyboard.mjs <project>, ouvrez storyboard.html, demandez l’approbation ou des notes par plan.

Étape 3 — Casting (validation ; ignorée s’il n’y a pas de personnes)

Si un plan contient des personnes, suivez <skill>/knowledge/casting.md : listez les rôles, choisissez la bibliothèque que la section 4c du style nomme, commencez par les personnes prêtes à l’emploi dans <skill>/casting/library/, habillez chaque rôle (tenue + accessoire) avec 3-4 poses du même personnage, exécutez son auto-vérification, montrez 2-3 candidats par rôle sur une page de casting et attendez les choix. Emballez les choix dans assets/cast.js. Pas de personnes → définissez l’étape sur skipped et dites-le en une ligne.

Étape 4 — Aperçu (validation)

1. Voix : node <skill>/templates/voice.mjs <project> (lit storyboard.json et project.json → voice). Un clip par beat avec la voix locale gratuite Kokoro, mesurée, timing.json, assemblée dans assets/vo/full.wav. Refaites des beats individuels avec --only B03,B07. Dites à l’utilisateur la durée totale et le mpm.
2. Construisez la partie d’aperçu : construisez uniquement les scènes des 20 secondes qui montrent le mieux l’aspect, les personnes et le mouvement (généralement l’accroche plus la première scène avec personnes), avec les règles de construction de l’étape 5, et exécutez les auto-vérifications dessus.
3. Contrôle qualité avant de montrer (knowledge/quality-gate.md §3-4) : exécutez style_compare.py par rapport à la fenêtre de référence des mêmes types de scène, puis confiez l’aperçu à un agent relecteur frais avec templates/reviewer-prompt.md. Corrigez et répétez jusqu’à ce que chaque score soit 4+ (3 tours maximum). Vous n’approuvez jamais votre propre rendu.
4. Rendu uniquement de cette partie vers renders/preview.mp4 (sa propre composition de chapitre, ou une coupe courte avec ffmpeg -ss S -t 20). Mettez-la sur le tableau, ouvrez-la, demandez : « Cela vous semble-t-il correct ? Quelque chose à changer avant que je fasse la vidéo complète ? » Montrez les scores du relecteur et toute mesure encore en dessous de la référence à côté. Un aperçu coûte quelques minutes ; un rendu complet beaucoup plus.

Étape 5 — Construction et rendu (validation finale)

Construction. Chargez les compétences HyperFrames (/hyperframes, /hyperframes-cli) pour le contrat de rendu. Construisez à partir de storyboard.json + timing.json + la recette de construction §10 du style + l’aspect fusionné (project.json → look).

• Générez assets/beats.js (timing + mots de narration) pour que chaque repère puisse être lié à un mot parlé : temps du repère = début du beat + longueur du beat × index du mot ÷ nombre de mots.
• Un groupe de scène par plan de storyboard ; les changements de scène selon le transition_out du plan (coupe ou panoramique), retardés si la dernière ligne partirait avant de pouvoir être lue.
• Vidéos de 3 minutes ou plus : gardez chaque chapitre rendu indépendamment (voir knowledge/rendering.md) afin qu’une correction ne re-rende que ce chapitre.
• Pour le style Ray Dalio, commencez à partir de <skill>/templates/kits/dalio-kit.js. Construction de référence : <skill>/examples/cx-ai-budget/.
• Encadrements de marque (carte d’intro/fin) à partir de la §6 de la marque, logo de son dossier.
• Enregistrez la timeline racine dans une balise <script> en ligne dans index.html (le vérificateur l’exige). Déterministe uniquement.
• Suivez les règles de mouvement de la section 4b du style : les personnes changent de pose sur les mots parlés toutes les 1-2 s et respirent ; les accessoires se dessinent ; chaque scène a une caméra (dérive + poussées) ; les changements de scène à l’intérieur d’un chapitre sont des panoramiques ou des traversées par zoom.
• Images ou séquences B-roll depuis OpenRouter uniquement si l’utilisateur a une clé et a accepté le coût (knowledge/openrouter.md). Après construction : npx hyperframes check (corrigez les erreurs ; traitez dead_stretch au-delà de 4 s et line_unread comme réels) et npx hyperframes snapshot --at <times> ; regardez chaque plan.

Son. Écrivez sound.json (fond musical, baisses, et chaque effet déclenché sur un beat + mot, à partir des sfx du storyboard et de la §7 du style), puis node <skill>/templates/mix.mjs <project> : il mixe voix, musique et effets et normalise le volume vers assets/mix.wav. Pointez la balise <audio> de la composition vers lui. Utilisez d’abord <skill>/assets/starter-kit/ (voir son MANIFEST.md) ; ne récupérez plus que depuis <skill>/assets/sources.md.

Auto-vérifications (exécutez-les toutes, corrigez avant de montrer quoi que ce soit) :

1. Couleurs de marque : chaque code hexadécimal dans les scènes se trouve dans le fichier de marque (ou la palette de style lorsqu’il n’y a pas de marque).
2. Aucune scène de texte uniquement sauf si la section 14 du style les autorise.
3. Personnes : chaque rôle est le casting choisi, personne n’est coupé par le bord du plan, personne ne tient une pose pendant plus de 2 s à l’écran, aucun personnage retourné ne porte de texte en miroir.
4. Mouvement : rendu, puis python <skill>/templates/motion_metrics.py renders/draft.mp4 ; comparez avec les objectifs de la section 14 du style. Un nombre rempli qui manque son objectif est une correction, pas une note de bas de page.
5. Aspect : placez un instantané à côté d’une image de référence de la vidéo du style et demandez : un spectateur dirait-il que c’est le même style ?
6. Regardez-la : faites une bande d’images (ffmpeg -ss S -t 24 -i video -vf "fps=2.5,scale=320:-1,tile=6x10" strip.jpg) de chaque scène et cherchez les étirements vides, les objets hors écran et les objets au mauvais endroit.

Rendu. Suivez <skill>/knowledge/rendering.md : vérifiez d’abord la mémoire libre et choisissez le nombre de workers en fonction ; rendez les vidéos de 3 minutes ou plus en parties avec node <skill>/templates/render_parts.mjs. Brouillon vers renders/draft.mp4, final vers renders/final.mp4.

Contrôle qualité (à nouveau, sur le brouillon complet). style_compare.py + un relecteur frais, comme pour l’aperçu. Le polissage fait partie de la première construction, pas quelque chose que l’utilisateur doit demander : cochez chaque case de la §6 de quality-gate avant le rendu.

Examen final (validation). Ouvrez la vidéo, demandez les corrections sous forme de courte liste. Appliquez-les, re-rendez uniquement les parties modifiées, assemblez, montrez à nouveau. Lorsqu’elle est approuvée, écrivez description.txt : options de titre, description en 2 lignes, horodatages des chapitres, crédits (musique, sons, dessins, images générées). Marquez toutes les étapes comme terminées, ouvrez le tableau.

Règles

• Ne montrez jamais un rendu qui n’a pas passé le contrôle qualité, et n’approuvez jamais votre propre rendu : un agent relecteur frais le note par rapport à la référence. S’il échoue encore après 3 tours, montrez-le avec les scores et dites clairement ce qui est en dessous de la référence.
• Copiez ce qui rend la référence bonne (délivrance vocale, effets sonores, énergie musicale, mouvement de caméra, rythme de coupe, densité graphique), pas seulement son apparence. Mesurez chaque aspect par rapport à la référence.
• Ne sautez jamais une validation. Ne construisez jamais avant que le storyboard soit approuvé et le casting choisi. Ne rendez jamais la vidéo complète avant que l’aperçu soit approuvé.
• Le feedback se termine toujours par une leçon (voir ci-dessus) ; la même erreur ne doit pas se reproduire.
• Une question à la fois, toujours avec une valeur par défaut sensée que l’utilisateur peut accepter par « oui ».
• Ne prétendez jamais qu’une étape a fonctionné sans vérifier (instantané, ffprobe, sortie de rendu).
• Ne dépensez jamais d’argent sans demander : dites d’abord le coût estimé de chaque lot de génération payant.
• Vérifiez la mémoire libre avant chaque rendu (knowledge/rendering.md) ; n’en commencez jamais un qui pourrait figer l’ordinateur.
• Si quelque chose ne peut pas être bien fait (par exemple un style avec présentateur sans séquence), dites-le clairement et proposez l’option sans visage la plus proche.
• Gardez tout à l’intérieur du dossier du projet ; ne supprimez jamais les fichiers de l’utilisateur.

Fichiers dans cette compétence

Chemin	Ce que c’est
knowledge/pipeline.md	Les cinq étapes, la boucle de rétroaction, l’organisation des dossiers, project.json, les règles de timing
knowledge/script-intelligence.md	Fichier mental → script : types de vidéo, frameworks, accroches, règles de parole, format de beat
knowledge/storyboard.md	Script → storyboard : schéma de plan, méthode, boucle de révision
knowledge/casting.md	Validation du casting : rôles, bibliothèques, habillage, page de casting, assemblage du casting
knowledge/rendering.md	Rendu en toute sécurité : règle de mémoire libre, workers, rendu de longues vidéos en parties, re-rendu d’une partie
knowledge/openrouter.md	Images et séquences vidéo payantes facultatives via OpenRouter (non testé)
knowledge/quality-gate.md	Étude de référence, plan-vers-référence, mesure, révision indépendante, leçons comme vérifications, liste de contrôle de polissage
templates/style_compare.py	Mesure un rendu