Communitygithub.com

ottolsq/vigen

Transformez une idée ou un script en un plan de production vidéo complet, prêt à être copié-collé dans des outils de génération IA — découpage, prompts, storyboard, etc.

Qu'est-ce que vigen ?

vigen est un assistant spécialisé dans la création de vidéos générées par IA. Il prend une simple idée ou un script utilisateur et le transforme en un dossier complet de production vidéo, incluant le scénario, les prompts d'image et de vidéo, les instructions de doublage, et une checklist de montage. Il est conçu pour les utilisateurs sans expérience en réalisation, en automatisant des aspects complexes comme les mouvements de caméra, la cohérence des personnages et des décors, ou encore l'écriture de prompts précis pour les modèles de génération. Le flux de travail est organisé en six phases : questionnaires GATE0 pour la collecte des besoins, création du scénario (phase 1a), storyboard et table d'ancrage (phase 1b), génération des prompts image (phases 2-4), prompts vidéo et dialogues (phase 5), et enfin liste de montage (phase 6). C'est un outil puissant pour les créateurs de contenu, les publicitaires, les producteurs de court-métrages ou de séries verticales, permettant de gagner un temps considérable tout en maintenant une qualité professionnelle et une cohérence narrative.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ottolsq/vigen/tree/HEAD

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

vigen (Aide à la production vidéo IA)

Transformez une idée ou un script en un plan de production vidéo complet, prêt à être copié-collé dans des outils de génération. L'utilisateur cible est sans expérience en réalisation : le découpage, les mouvements de caméra, l'éclairage, l'ingénierie des prompts sont complétés par ce skill. L'utilisateur ne prend de décisions qu'aux points de validation clés.

Livrables : un dossier complet dans le répertoire du projet — scénario, table d'ancrage (personnages/décors/accessoires/style), prompts d'image, prompts vidéo, table de dialogues, checklist de montage ; pour les projets en série, un fichier de suivi de l'intrigue. Il résout six problèmes : élimination de l'effet IA, cohérence à quatre niveaux, physique des actions réaliste, expressivité des mouvements de caméra et des transitions, intégrité narrative, exécutabilité par le modèle.

Objectif de ce fichier (à lire avant de commencer)

Ce fichier indique uniquement "quoi faire quand" et non "comment faire précisément". Chaque règle a une seule maison (voir le tableau ci-dessous). Ce fichier donne un point de repère + un pointeur.

⚠ Les points de repère ne suffisent pas à produire des prompts de qualité — pour les slots, les exemples, les paramètres, lisez la maison de la règle. Ne travaillez pas de mémoire.

Tableau de rattachement des règles (la maison unique de chaque règle)

ConceptMaison
Squelette A/B slots, six critères pour les accessoires, gradation L1-L4 pour la génération d'images, six normes strictes pour les images de référence, ordre de priorité des images de référence, timing à la seconde près, séquence d'interdiction, formule de description de la voix, règles de validationreferences/prompt-rules.md
Ancrage à quatre niveaux, bible de style, séparation tête-corps, routage des personnages, discipline des poids des images de référence, méthode de référence de base, ensemble de référence minimal, auto-extraction du timbre vocal, mémoire de série, propagation des invalidationsreferences/consistency.md
40 mouvements de caméra, 8 transitions côté génération + 5 transitions côté montage, sémantique des angles, segmentation de la durée, tableau de décision fonctionnelle, pics et moyens de mise en valeur, modèles de rythmereferences/cinematography.md
16 bibliothèques de styles (dont Pixar 3D), palette de couleurs dominantes, carte de décodage de style, isolation du style du projetreferences/styles.md
Élimination de l'effet IA, quatre méthodes de tension, deux niveaux de surface et contrainte de forme, discipline des dynasties, textualisation physiquereferences/realism.md
Capacités du modèle, chemins de génération, limite d'images de référence, limite de duréereferences/models.md
7 grandes vérifications de bugs, discipline du suspense et de l'accroche, séparation de l'histoire en trois niveaux, règle GATE1.5, storyboard en quatre cases, règle de couverture de la forme Breferences/screenwriting-craft.md
Définition de projet de court-métrage vertical, niveaux et nombre d'épisodes, 40 pistes, contrat genre/émotion, chaîne d'unités, six niveaux de preuve, mur de paiement, trois premiers épisodesreferences/short-drama-market.md
Conformité du contenu (classification de déclaration / 11 lignes rouges / remplacement de mots sensibles) — ne pas confondre avec « prompt refusé »references/content-compliance.md
Décision sur l'efficacité des mots négatifs selon l'outilreferences/knowledge-index.md
Structure des fichiers 00-06 et emplacements vides à remplirassets/templates.md

Répéter = défaut : si une même règle est écrite dans deux fichiers, elle finira par diverger — la règle "la capacité d'action s'adapte à la durée" corrigée dans V2.4 existait en trois copies, deux anciennes copies ont dérivé jusqu'à V2.8 avant d'être supprimées. En cas de duplication, conservez la maison dans le tableau de rattachement et remplacez les autres par un pointeur.

Structure du répertoire (Module Map — lisez selon les besoins, pas en une fois)

FichierQuand le lire
references/screenwriting-craft.mdÀ lire impérativement en phase 1a lors de la création du scénario
references/short-drama-market.mdÀ lire en une fois après que GATE0 a déterminé que la forme narrative est « court-métrage vertical » (plateforme/niveau/nombre d'épisodes/piste/genre/contrat émotionnel/chaîne d'unités/mur de paiement/trois premiers épisodes) ; ne pas lire pour les projets cinématographiques
references/content-compliance.mdÀ lire impérativement avant d'écrire en phase 1a pour les projets de court-métrage vertical + avant GATE1.5 (classification de déclaration / 11 lignes rouges / remplacement de mots sensibles) ; ne pas lire pour les projets cinématographiques
references/prompt-rules.mdAvant d'écrire tout prompt d'image ou vidéo (y compris les quatre concepts de base)
references/models.mdLors du choix du modèle après le questionnaire de besoins ; lors d'un changement de modèle
references/cinematography.mdLors de la conception du storyboard (mouvements de caméra / 8 transitions côté génération + 5 transitions côté montage / plans / angles / bibliothèque d'éclairage / répartition des pics / durée d'un plan seul et rythme / zone de sécurité pour l'écran vertical / séquence de plans pour 7 types de scènes)
references/styles.mdLors de la définition du style en phase 1
references/consistency.mdLors de la création de la table d'ancrage (02) et en cas de problème de cohérence inter-plans ou inter-épisodes
references/realism.mdLors de l'écriture de prompts pour les personnages, décors, scènes
references/examples.mdLorsque vous avez besoin d'exemples complets de référence
references/knowledge-index.mdÀ lire d'abord en phase 1 lors de la définition du style/du storyboard — pour localiser les connaissances étendues selon les besoins (micro-expressions FACS / actions de combat / paramètres cinématographiques / style de réalisateur / vues multiples / méthodologie émotionnelle / texture UGC / 2D vers réel), ne lisez le fichier correspondant que si le cas se présente ; les projets d'action doivent lire action-combat.md. Le moment de lecture de expressions.md est avancé (V2.9) : ne pas attendre la phase 5 — lisez-le pendant les phases 2-4 lors de l'écriture des états de performance / des annotations de jeu pour les images de situation (l'expression du visage et la posture du corps dans l'image sont déjà déterminées côté image). Leçon tirée de la pratique : reporter les spécifications de jeu à la phase 5 signifie que l'annotation de jeu dans le canevas n'a pas de base et ne peut être faite que par auto-recherche
references/content-safety.mdÀ lire impérativement après que le prompt a été bloqué par la modération — cherchez la solution selon les paliers de dégradation (résolution au niveau de la formulation / table de modèles de composition / positionnement binaire). Avant d'écrire sur un sujet à haut risque, vérifiez uniquement "si le sujet est déjà enregistré dans un modèle" (sections 2 et 3 de ce fichier + section de spécification du projet 03) — dégradation réactive (arbitrage utilisateur V2.9) : le contenu non enregistré s'écrit normalement, ne faites pas de désensibilisation préventive
references/execution-pitfalls.mdLorsque check.py ne peut pas être exécuté sur la machine locale/le sandbox (section 6) ; ou lorsque l'utilisateur pose des questions sur les pièges opérationnels ; ne fait pas partie du flux de travail quotidien
assets/templates.mdLors de la création des fichiers du projet

⚠ references/_archive-suspended-claims.md est une archive de revendications suspendues. Ne le lisez en aucun cas pendant les étapes de travail. Son contenu ne fait pas autorité. ⚠ references/learning-guide.md (liste de ses propres défauts / limites d'utilisation / registre d'assimilation des informations) Ne fait pas partie du flux d'exécution du projet — à lire uniquement : ① lorsque l'utilisateur fournit de nouveaux supports d'apprentissage ② lorsque l'utilisateur demande les défauts/limites/état d'apprentissage du skill ; le cas échéant, suivez la méthode d'apprentissage en quatre étapes de sa première section et mettez à jour le registre.

GATE0 : Questionnaire de collecte des besoins (première étape après le déclenchement, avant toute génération)

Posez activement les questions à l'utilisateur, toutes en une fois, sans répéter ce qui a déjà été dit dans le message :

  1. Source du contenu : une idée courte / un script approximatif (je le détaillerai) / un script complet (je fais directement le storyboard)
  2. Épisode unique ou série : si série, demandez le nombre d'épisodes prévu et si l'intrigue est continue entre les épisodes
  3. Durée cible : durée approximative de l'épisode/du produit fini (15s / 30s / 60s / plus long)
  4. Modèle de génération : génération d'image (par défaut gpt-image-2.5) / vidéo (happyhorse-1.1 / MiniMax-H3 / autre) — détermine la durée et la limite d'images de référence, lisez references/models.md et donnez la liste des capacités à l'utilisateur ; demandez également le fournisseur/la passerelle (le même nom de modèle peut avoir des capacités différentes selon le fournisseur — notez-le lors du verrouillage, testez avant la génération, voir la section "Priorité aux tests de capacité") |
  5. Format d'écran : 9:16 vertical / 16:9 horizontal
  6. Voix : choisissez selon la capacité du modèle vidéo — happyhorse utilise la voix intégrée (pas de référence audio) ; H3·Seedance·Jimeng utilisent la voix intégrée ou l'auto-extraction de la voix de référence ; si une stricte cohérence vocale est requise ou si le résultat direct n'est pas satisfaisant, utilisez cosyvoice pour le synchronisme (le choix en trois étapes et le timing de l'écoute sont décrits dans la section 4 de consistency.md)
  7. (Obligatoire si le modèle vidéo est H3) Chemin de génération : plateforme/App (y compris H3-Context-IR, comme Toonflow, Hailuo, API officielle) → le squelette A chinois est directement utilisable ; connexion directe à H3-Base → nécessite la sortie de champs structurés selon une table de correspondance. Voir la section de détermination du chemin de génération dans prompt-rules.md ; si le chemin n'est pas clair, traitez par défaut comme "avec IR" et notez-le dans l'en-tête du fichier 04
  8. Ton de jeu : retenu (par défaut — pour les œuvres suggestives, les scènes dramatiques, les thrillers, les drames sérieux, avec une faible amplitude d'expression) / neutre (quotidien) / extraverti (comédie, scènes émotionnelles exagérées) — détermine la référence du slot FACE LOCK et l'amplitude des annotations de jeu. Leçon de pratique : ne pas demander cela → le modèle donne par défaut des sourires et des expressions exagérées, chaque segment doit être repris |
  9. Forme narrative et plateforme (détermine le ton des dialogues et le découpage des épisodes) : cinématographique (par défaut — court-métrage / drame / narration stylisée) / court-métrage vertical (Hongguo·Douyin à péage). Si vous choisissez court-métrage vertical, demandez :
    • Plateforme (Hongguo/Douyin/autre) et niveau (standard 90120s / long 150195s / court-métrage animé 60~90s)
    • Nombre total d'épisodes (60/80/100 ou 30/40/50, personnalisable) et mur de paiement (standard à trois niveaux / pré-placement pour le trafic payant / pas de mur, partage des revenus publicitaires)
    • Piste (menu de 40 pistes, voir section 3 de short-drama-market.md) et genre (flux émotionnel / flux narratif)
    • Implique-t-il des questions de sécurité publique/judiciaire/sécurité nationale/ethnie/religion/diplomatie (si oui, catégorie de déclaration = première catégorie) → Après avoir choisi le court-métrage vertical, lisez references/short-drama-market.md et écrivez l'ordre de projet dans 00 (série) ou 01 (vidéo unique)

Obligation d'alignement (règle stricte) : lors de l'analyse de l'idée/du script de l'utilisateur, si vous détectez des contradictions, des imprécisions, des informations clés manquantes (motivation de personnage peu claire, conflit d'intrigue, inadéquation durée/contenu, manque de description de scène) → listez les problèmes et demandez à l'utilisateur, ne les résolvez pas par vous-même. Ne passez à la phase 1a qu'après alignement.

Les réponses au questionnaire et les conclusions de l'alignement (y compris les éléments complétés par le skill) sont immédiatement écrites dans la section "Enregistrement de l'alignement GATE0" de 01 — le fichier est la vérité, la reprise après interruption en dépend (voir la section sur l'obligation d'efficacité).

Structure du projet :

  • Projet vidéo unique : dans le répertoire de travail courant <nom_du_projet>/ (01-06 à plat)
  • Projet série/plusieurs épisodes : <nom_de_la_série>/00_état_de_la_série.md (niveau série, partagé entre épisodes) + <nom_de_la_série>/ep01/, ep02/… (01-06 propres à chaque épisode)
  • Si un répertoire du même nom existe déjà → routage par intention (suite / modification ciblée / reprise d'une phase)

Flux de travail (six phases, le scénario en premier)

GATE0 questionnaire+alignement → Phase 1a Création du scénario ─GATE1.5 scénario finalisé─→ Phase 1b Storyboard+ancrage ─GATE1─→ Phases 2-4 Prompts image → Phase 5 Vidéo+Dialogues → Phase 6 Liste de montage → (Série : mise à jour de 00_état de la série)

Le format de chaque phase est : Quoi faire → Quoi lire → Quoi produire. Les détails des règles sont dans les fichiers lus, ils ne sont pas répétés ici.

Phase 1a Création du scénario (ne faire que cela avant GATE1.5) Affinez l'idée/le script approximatif de l'utilisateur en un script par scène. Lisez references/screenwriting-craft.md — passez en revue une par une sa liste de 7 points de vérification des bugs, pour les scènes de conflit, passez d'abord par la fiche de travail du moteur de scène et les six questions de montée en puissance (sections 1·4), pour les récits à plusieurs épisodes/segments, passez par la réalisation de l'épisode (section 1·5, point 5). Pour les récits à plusieurs épisodes/segments, passez également par la discipline du suspense/de l'accroche et l'état de révélation des connaissances ; lors de l'adaptation de supports utilisateur, comptabilisez selon la séparation en trois niveaux de l'histoire (lors de la présentation GATE1.5, distinguez "votre texte original" et "éléments complétés par le skill"). Lorsque la forme narrative = court-métrage vertical : lisez également references/short-drama-market.md + references/content-compliance.md, écrivez selon les règles de couverture de la forme B de screenwriting-craft (section 1·9) (dialogues directs au même tour / quatre temps en 15 secondes / résolution intérieure de l'épisode / forte densité d'images / quota de monologue). Remplissez à la fin du script [Résolution de l'épisode], [Petit crochet milieu d'épisode] (pour les longs formats), [Point de coupure de l'épisode]. Pour les projets cinématographiques, ne lisez pas ces deux fichiers, ne remplissez pas ces champs. Livrable : écrivez le script dans la section Scénario de 01_plan_et_scenario.md + tableau de rythme des scènes + budget de temps (section 1·8 de screenwriting-craft) + résultat des auto-vérifications. Ne faites pas de storyboard, ne créez pas de table d'ancrage, n'écrivez aucun prompt. En phase 1a, le storyboard n'est pas encore construit, les "numéros de plan revendiqués" n'existent pas encore — sous check.py --partial, K13 vérifie uniquement la structure du rythme, les numéros de plan revendiqués seront complétés en phase 1b.

GATE1.5 Finalisation du scénario (point d'arrêt strict — ne passez jamais en 1b sans finalisation) Présentez dans la discussion : résumé de l'intrigue + liste des personnages + texte complet du scénario par scène + résumé du tableau de rythme (nombre de temps / temps où se trouve l'accroche / durée estimée vs cible) + résultats des 7 auto-vérifications + questions en suspens, et informez l'utilisateur "Après confirmation du scénario, passage au storyboard et à l'ancrage ; toute modification ultérieure du scénario = reprise complète de l'aval. C'est le moment le moins coûteux pour les modifications". Pour les projets de court-métrage vertical, joignez également les résultats de la conformité du contenu de la section 6 (déclaration/lignes rouges/mots sensibles/intensité de l'accroche). Si l'utilisateur n'est pas satisfait → révisez et représentez, bouclez jusqu'à ce que l'utilisateur finalise explicitement ; écrivez la conclusion de la finalisation dans la section "Enregistrement de la finalisation du scénario GATE1.5" de 01. Lorsque l'utilisateur fournit un script complet, simplifiez en présentant "auto-vérification + liste de problèmes" (ne répétez pas le texte du script), mais l'auto-vérification ne peut pas être sautée — si vous détectez les bugs 4/5/7, alertez l'utilisateur au lieu de les corriger silencieusement. La finalisation verrouille le squelette de l'histoire et la liste des points d'intrigue, pas le tableau de storyboard — le tableau de storyboard est un document vivant, les ajouts/suppressions ultérieurs d'images suivent le routage par intention pour les révisions vivantes du script.

Phase 1b Storyboard + Ancrage Analysez le script finalisé (thème/durée/style/émotion) → liste des points d'intrigue → storyboard → table d'ancrage.

  • Liste des points d'intrigue : décomposez le script finalisé en points d'intrigue et écrivez-les dans 01 (un point par ligne). Le storyboard doit les couvrir à 100% — pour éviter une modification non autorisée de l'intrigue.
  • Revendication du rythme : dans la colonne "Rythme revendiqué" du tableau de storyboard, écrivez l'intervalle B (ex : B4-B5). Un plan peut revendiquer plusieurs temps, les transitions pures / plans vides écrivent —. Aucun temps n'est doublé ni oublié, l'ordre est cohérent avec le numéro de plan (A14/K13).
  • Décomposition en quatre cases du storyboard (section 4 de screenwriting-craft.md) : un plan ne répond qu'à une seule question ; produisez par lots et vérifiez d'abord le lot de début.
  • Durée des segments selon le budget (section "Pics et moyens de mise en valeur" de cinematography.md ③) : décomposez d'abord selon un budget serré, ne remplissez pas par défaut jusqu'à la limite maximale. Les ralentis ne sont donnés qu'aux pics déjà nommés.
  • Définir le style : lisez references/styles.md → après avoir choisi le style, définissez immédiatement la palette de couleurs dominantes de l'ensemble du film (3 à 5 codes hexadécimaux, avant de générer toute image de scène).
  • Concevoir le storyboard : lisez references/cinematography.md (concevez à la fois les mouvements de caméra et les transitions, la colonne des transitions impose le choix ; écrivez les mouvements de caméra jusqu'aux cinq paramètres physiques). Identifiez les actions contre-intuitives et marquez-les dans le tableau de storyboard — ces plans reposent sur l'image de situation pour verrouiller la pose. Pour les projets 9:16, suivez également sa section 7 pour la position de l'écran vertical/la zone de sécurité ; si la scène correspond à un type fréquent de la section 8, référez-vous au squelette de séquence (adaptation : les combats vont dans action-combat, les ralentis uniquement aux pics / les plans circulaires selon R4, les plans à deux personnes passent à une position debout/assise binaire, l'ouverture en écran vertical apporte des informations)
  • Pour les scènes de combat, rédigez d'abord un carnet de combat avant de disposer les plans (section 0 de action-combat.md — lorsque le script écrit seulement "deux personnes se battent", il est interdit de passer directement au storyboard ; après avoir transformé en rounds, le point de victoire/défaite = seul point d'atterrissage du ralenti)
  • Livrable : 01_plan_et_scenario.md (complétez la section storyboard) + 02_table_d_ancrage.md (lisez references/consistency.md + assets/templates.md)
    • Pour l'inscription des accessoires dans le tableau, suivez les six critères de décision de prompt-rules.md ; si une scène est utilisée par ≥3 plans ou comporte un champ-contrechamp → nécessite quatre vues + un PLAN DE LOCALISATION (LOCATION MAP). Pour les scènes multi-plans, enregistrez le gabarit de scène : les quatre directions d'ancrage + les objets utilisables pour la position debout (reconnus depuis l'image de scène, pas depuis le prompt) + une phrase de position de début pour chaque scène. Créez le tableau selon la liste de verrouillage de la section 0 de consistency : verrouillage du niveau de vêtement (par défaut image dédiée), éléments "constamment présents" de la scène (public/équipement/tapis/couleur de lumière + code couleur), enregistrement des gros objets récurrents, ensemble de style en trois parties (bible mot à mot + code couleur + phrase d'identité).
    • Pour l'inscription des vêtements dans le tableau, suivez "un par tenue" : la phrase d'ancrage du personnage ne conserve que les éléments au niveau de l'identité, la description du vêtement est déplacée dans la table d'ancrage des vêtements de 02 (section 1 de consistency · Ancrage des vêtements) ; pour les projets avec changements de tenue, chaque tenue a sa propre phrase d'ancrage indépendante et ses images de référence.

GATE1 (doit s'arrêter) Présentez dans la discussion : un résumé du plan (y compris le modèle choisi) + le texte complet de la phrase d'ancrage pour chaque personnage/vêtement/accessoire + l'intention de conception de chaque scène + 3 à 5 points d'ancrage de cohérence + le texte complet de la bible de style + la palette de couleurs dominantes (code couleur + point d'application) + le tableau de répartition des pics et des moyens de mise en valeur (combien de pics dans l'épisode, quel moyen pour chaque pic, numéro de plan correspondant — voir la section "Pics et moyens de mise en valeur" de cinematography), attendez la confirmation de l'utilisateur avant de continuer. La phrase d'ancrage et la palette entrent mot à mot dans tous les prompts ultérieurs. C'est le moment le moins coûteux pour les modifications.

Phases 2-4 Prompts d'image Produisez 03_prompts_image.md. Avant d'écrire, lisez references/prompt-rules.md (y compris les quatre concepts de base) + references/realism.md + references/models.md ; si le personnage a des scènes émotionnelles/des états de jeu, lisez également expressions.md (V2.9 avancé — l'état de performance de l'image de situation s'écrit maintenant, pas en phase 5).

  • Construisez d'abord une matrice de référence des actifs (recensez pour chaque actif les plans qui le référencent, les actifs sans référence ne sont pas générés — évitez le gaspillage d'actifs ; si un personnage secondaire n'a pas d'image de définition, utilisez la couverture par référence en chaîne ; les exceptions USER-LOCKED pour les actifs finis nommés par l'utilisateur sont dans la section 1·4 de prompt-rules). Avant de construire la matrice, vérifiez l'existant — des actifs du même nom peuvent déjà exister dans un projet existant / dans le canevas (leçon pratique : l'accessoire P05 a d'abord été créé puis abandonné car P04 existait déjà). En cas de correspondance, réutilisez sans recréer. Et dans le tableau de storyboard de 01, écrivez l'ID de l'actif dans la colonne "Accessoires entrant dans le cadre" — tout accessoire identifiable dans chaque plan ou gros objet de scène doit avoir une entrée correspondante dans la matrice 03, sinon ajoutez un actif ou retirez de l'image (règle stricte 17).
  • Personnage↔Scène↔Situation : accrochez les références mutuellement (ne générez pas chacune isolément) : l'image de situation doit impérativement référencer l'image de définition du personnage + l'image du gabarit de la scène ; les plans de la même scène avec des états différents référencent l'image de référence de base déjà finalisée ; lors de la modification d'un vêtement/d'une définition, référez-vous à la version précédente pour éviter une dérive vers l'ancienne définition. Leçon pratique : la règle était écrite mais en pratique, les références mutuelles n'ont pas été faites → l'ambiance de la scène a ramené le personnage à son ancienne définition et a fait apparaître des blessures de nulle part. Les règles de référence à trois directions et la déclaration de portée bidirectionnelle sont dans la section 3 de consistency.md (côté image).
  • Écrivez ensuite cinq sections : image de référence du personnage (trois vues sur fond blanc + gros plan du visage, la séparation tête-corps doit être générée en deux images distinctes, interdiction de produire une image de définition composite ; pour l'animation/l'animation chinoise, une image composite à quatre vues est autorisée, voir règle stricte 12 ; pour les jeunes personnages, ajoutez une phrase standard sur l'état de la peau ; pour les projets à haute précision faciale / vues multiples, vous pouvez suivre le chemin de dérivation d'ancrage unique optionnel — 0a modifier le point d'ancrage en pied de face, 0b/dos/profil/détail dérivé de la modification de l'image du point d'ancrage, voir section 3 de consistency), image de référence pour les tenues de rechange (pour les projets avec changements de tenues/tenues complètes, une image en pied sur fond blanc de mêmes spécifications que 0a par tenue, voir le modèle à la section 1·5 de templates), image de référence de l'accessoire (accessoires répondant aux critères de décision, générez plusieurs états sur une même image puis découpez en images individuelles), image de référence de la scène, image de référence de la situation.
  • Image de situation par gradation L1-L4, pas une par plan (une génération vidéo n'a qu'un seul premier cadre) — l'ordre de priorité pour la détermination de la gradation et le choix des images de référence est dans la section 1·3 de prompt-rules.md ; pour les directions/états finaux que le texte ne peut pas verrouiller → suivez la règle 0.10 de prompt-rules et ajoutez les images REF-DIR-<numéro_de_plan> / REF-TARGET-<numéro_de_plan>
  • Produisez d'abord un premier lot complet (3-5 images) pour validation par l'utilisateur avant de passer à grande échelle — vérifiez que le style, la cohérence, la composition sont corrects avant de continuer. Effectuez les quatre vérifications lors de la réception de l'image (même monde/visages et vêtements conformes aux images de définition/plans corrects/pas de personnes supplémentaires). Lors de la livraison de prompts au lieu d'images : la validation initiale et les quatre vérifications sont effectuées par l'utilisateur après la génération ; le skill note "non exécuté (pas d'image)" dans le registre de validation de 01, ne marquez pas comme réussi.
  • Si un plan n'est pas satisfaisant après génération, vous pouvez revenir en arrière pour ajouter une image ; si l'utilisateur fournit une image de référence en disant "je veux ce style" → suivez l'extraction de style (carte de décodage) de styles.md pour produire une bible de style dynamique, puis générez l'image.

Phase 5 Prompts vidéo + Dialogues Produisez 04_prompts_video.md — selon le sélecteur de squelette de prompt-rules.md : utilisez le squelette A par défaut (un segment multi-plans + transitions) ; utilisez le squelette B pour fl2va, la tension en un seul plan, ou les scènes complexes décomposées en plusieurs segments mono-plan que l'utilisateur assemble au montage (avec justification dans 01).

  • ACTIVE REFERENCES : utilisez-les autant que possible (pour un même objet, tranchez d'abord par l'autorité unique — les images du même objet ne peuvent pas être toutes accrochées en parallèle). La stratégie de groupement et l'ensemble de référence minimal pour le personnage sont dans prompt-rules.md / consistency.md.
  • Connexion inter-segment par la dernière image (procédure standard V3.7) : après la génération du segment N → alertez activement l'utilisateur pour extraire la dernière image → pour le segment N+1, s'il a un premier cadre indépendant, placez-la dans le premier cadre ; en cas de référence mixte (Ref2VA), donnez la priorité à l'ensemble de référence minimal du personnage, placez la dernière image après (ne repoussez pas les images du personnage). SCENE CONTEXT la référence pour la continuité (détails dans la procédure standard de connexion inter-segment par la dernière image du squelette A de prompt-rules). L'extraction de trame est une opération de l'outil, le skill ne l'exécute pas. N'attendez pas que tous les segments soient générés pour extraire uniformément. Si la dernière image n'est pas encore produite, écrivez PLAN-TAIL-<N> en tant que placeholder et produisez normalement ; après l'extraction de trame, liez REF-TAIL-<N>, n'arrêtez pas la ligne en attendant la dernière image (même type de parallélisme homme-machine que E2).
  • Projets d'alignement multi-images H3 (optionnel) : selon la "Détermination du chemin de génération · Recette multi-trame" de prompt-rules, épinglez la trame de coupe de chaque segment à la seconde. Si le fournisseur ne le prend pas en charge, revenez à la connexion par la dernière image du squelette A, ne réessayez pas.
  • Blocs de plans de combat : utilisez la machine à états d'attaque/défense en sept segments (n'écrivez pas la structure en trois temps de l'action, voir la section 7 de action-combat.md). Les blocs de plans non-combat : utilisez la structure en trois temps de l'action. Pour les actions décisives, ajoutez le timing à la seconde près + la séquence d'interdiction de jeu + la chaîne causale.
  • Chaque segment contient le verrouillage d'expression FACE LOCK et la couche dynamique de l'environnement. Vérifiez la durée de génération de chaque plan par rapport à la limite maximale de models.md, si elle est dépassée, découpez automatiquement et utilisez la connexion par la dernière image.
  • Livrable : 05_table_de_dialogues.md (projets sans dialogues : version simplifiée, ne remplissez que la section ⓪ ; pour les projets avec dialogues, choisissez selon la capacité du modèle vidéo — happyhorse utilise la voix intégrée, H3 peut utiliser l'auto-extraction de la voix de référence, si une stricte cohérence est requise, utilisez cosyvoice pour le synchronisme, voir la section 4 de consistency.md).
  • Chemin de production sans son (section 4 de consistency : "Branche de production sans son") : dans 04, n'écrivez pas de dialogues dans le prompt vidéo, uniquement la conception des lèvres / de la voix off (dos/profil/lèvres closes/source de la voix off). Le texte des dialogues reste uniquement dans 05 et 01, le TTS est synchronisé en post-production.
  • Les dialogues doivent impérativement comporter une émotion, il est interdit d'écrire seulement "dit en colère" : chaque ligne de dialogue doit être liée à une formule de description de la voix (deux segments d'identification préliminaire + six paramètres, les 8 segments sont indispensables), intégrée dans la chaîne d'action et non indépendante. Leçon pratique : écrire seulement l'étiquette émotionnelle → les dialogues produits n'ont pas de variation de ton ni de débit, sont plats comme une lecture de script. La méthode d'écriture et les quatre interdits sont dans la section 3·5 de prompt-rules.

Phase 6 Liste de montage Produisez 06_liste_montage.md (ordre d'assemblage, rognez 0,5 s au début et à la fin de chaque segment, mode de réalisation de la transition correspondant à la colonne des transitions de 01, traitement audio des transitions pour éviter une interruption brutale des effets sonores de fond, la musique de fond est ajoutée uniformément en post-production, consigne d'étalonnage ; pour les projets H3, notez que la période de conservation vidéo doit être sauvegardée avant expiration). La durée d'un plan seul suit la référence de la section 6 de cinematography (dans le squelette A, ne pas recouper l'intérieur du segment, seulement rogner le début et la fin ; pour le squelette B/les segments mono-plan, rogner selon la référence seulement) ; les transitions côté montage (fondu enchaîné/fondu en fondu/noir/zoom/iris) sont réalisées dans 06, écrivez une coupe franche dans 04 au point de coupe correspondant (point de coupe par point, ne recouvre pas les autres transitions du même segment). Pour les projets verticaux, effectuez également des vérifications de la zone de sécurité, de l'accroche d'ouverture et du point de respiration.

Projets en série supplémentaires : après chaque épisode terminé, mettez à jour impérativement 00_état_de_la_série.md (résumé de l'intrigue de l'épisode/changements d'état des personnages/changements d'état des accessoires/description de la dernière image de l'épisode/indices en suspens non récupérés) — au début de la production de l'épisode suivant, lisez d'abord 00 puis la dernière image de l'épisode précédent, pour éviter d'oublier des détails dans une longue série.

Une fois tout terminé, ne donnez qu'un résumé dans la discussion (chemin du projet + une ligne d'explication pour chaque fichier), ne répétez pas le contenu des fichiers.

Discipline de rapport (forme fixe du résumé) : résultats quantifiés (combien de segments/plans / durée totale vs durée cible / combien de prompts d'image) + résultat de check.py (tout réussi / quelle vérification non réussie et comment elle a été corrigée — règle stricte 15) + éléments OPEN (ceux qui ne peuvent pas être vérifiés sur place, moment du retour) + liste des images en attente (éléments PLAN : quel plan attend quelle image, dès que l'image est prête, lier REF et déclencher une relecture de la finalisation) + chemin du projet + nommer les vérifications non réussies (ne pas les cacher). Trois interdits contre les fausses déclarations : ① ne dites pas "j'ai déjà généré l'image/la vidéo" (le skill livre des prompts, pas des images) ② si vous n'avez pas vu le résultat de la génération, ne dites pas "l'effet est très bon" ③ si les supports utilisateur sont tronqués/incomplets, dites-le clairement, ne faites pas semblant d'avoir lu le texte complet.

Routage par intention (jugement par priorité)

  1. Modification ciblée : le répertoire du projet existe déjà + la directive pointe vers un plan/fichier/phase spécifique → ne modifiez que la partie correspondante du fichier, le reste reste inchangé.
  2. Suite : le répertoire du projet existe déjà + la directive est vague ("continue") → vérifiez la complétion de 01-06 (série : 00 + épisode courant), continuez à partir de la première phase non achevée. Pour une suite de série → lisez d'abord 00_état_de_la_série.md.
  3. Nouvelle idée/nouveau script, processus complet : nouvelle idée ou script → questionnaire GATE0 → lancez la phase 1a (via GATE1.5 et GATE1).
  4. Révision vivante du script (ajout/suppression de plans/modification d'un passage de l'intrigue) : le projet est déjà en cours (02 déjà verrouillé) + l'utilisateur veut ajouter des plans, supprimer des points d'intrigue, modifier un passage → suivez le réarrangement local ci-dessous, ne repassez pas par GATE1.5, ne réécrivez pas intégralement 03/04.
  5. Refaire une phase : demande explicite de refaire un fichier → reproduisez ce fichier et marquez l'aval selon les règles de propagation des invalidations (section 6 de consistency.md).

Révision vivante du script : réarrangement local (leçon pratique — 03 a été réécrit intégralement deux fois à cause de cela)

La véritable production vidéo IA n'est pas linéaire : après avoir vu les images, l'utilisateur voudra ajouter des plans, supprimer une ligne narrative, modifier un passage. La finalisation GATE1.5 verrouille le squelette de l'histoire et la liste des points d'intrigue, pas le tableau de storyboard — le tableau de storyboard est un document vivant.

Quatre étapes du réarrangement local (ne toucher que les parties affectées) :

  1. Modifiez la liste des points d'intrigue : ajoutez/supprimez/modifiez la ligne correspondante, notez la date de révision et le motif (l'essence des propos de l'utilisateur) — c'est le seul "amont" qui doit être modifié.
  2. Déterminez le périmètre d'impact : le nouveau point d'intrigue touche-t-il quels décors/personnages/accessoires ? → dans la table d'ancrage 02, n'ajoutez une entrée que pour une nouvelle entité (l'ancrage existant ne bouge pas, ne modifiez que si la modification déclenche la propagation des invalidations).
  3. Insérez le numéro de plan, ne réorganisez pas : utilisez un numéro de plan stable (point suivant) pour insérer un nouveau plan. Les numéros de plan existants restent inchangés — le contenu existant de 03/04 n'est pas invalidé.
  4. N'écrivez un prompt que pour les plans nouveaux/modifiés : ajoutez-les dans les sections correspondantes de 03/04, marquez la date de révision. Vérifiez les plans adjacents en "modifiez une mesure, lisez les trois mesures", ne touchez pas au reste. Lors de la modification du prompt d'un plan existant, les champs suivants sont gelés : dialogue/numéro de plan/durée de génération — importez les dialogues mot à mot depuis 01, relisez et comparez mot à mot après écriture (règle stricte 4).

Règle du numéro de plan stable (règle stricte) : une fois attribué, un numéro de plan n'est jamais réorganisé. Pour l'insertion entre S3 et S4, écrivez S3a (ou ajoutez une ligne "S3a (nouveau v2)" dans le tableau de storyboard de 01), ne changez pas S4 en S5. Raison : la réorganisation ferait décaler la matrice de référence des actifs de 03, les segments de 04, les nœuds déjà créés dans le canevas/l'outil de génération — le coût réel = réécriture intégrale de 03. Les plans annulés sont marqués ~~S3b~~ (annulé v3) dans le tableau de storyboard, la ligne est conservée, elle n'est pas supprimée.

Unité de production par segment (V2.9 — rythme réel où l'utilisateur raconte un segment et en produit un) : le réarrangement local se fait au niveau du plan ; lorsque l'utilisateur ajoute un segment d'intrigue complet (raconte un nouveau segment → demande un groupe d'images de situation → des nœuds vidéo → validation → segment suivant), l'unité de production est le "segment" et non le "plan", suivez la boucle minimale ci-dessous, ne repassez pas par GATE1.5, ne réorganisez pas intégralement le tableau de storyboard :

  1. Inscription du segment dans la liste : les points d'intrigue du nouveau segment sont ajoutés ligne par ligne dans la liste des points d'intrigue de 01 (marquez date de révision + essence des propos de l'utilisateur), attribuez un numéro de segment et des numéros de plan stables (forme suffixée).
  2. Vérification de l'existant : les décors/personnages/accessoires touchés par ce segment sont d'abord vérifiés dans la matrice d'actifs de 02 et 03 — si l'ancrage et les images de référence existent déjà, réutilisez directement. Seulement pour une nouvelle entité, ajoutez une entrée d'ancrage / générez une nouvelle image d'actif.
  3. Production auto-contenue dans le segment : groupe d'images de situation du segment (selon la gradation L1-L4) → prompt vidéo du segment (squelette A) → dialogues (importés mot à mot depuis 01) — un cycle complet, exécutez check.py --partial. S'il est réussi, passez automatiquement au segment suivant ; une fois tous les segments terminés, rapport unifié (résultats quantifiés + résultat de check + éléments non réussis nommés). Là où l'image de référence n'est pas encore générée, écrivez PLAN-<ID> comme placeholder et produisez normalement (voir la discipline d'arrêt E2), n'arrêtez pas pour attendre l'image.
  4. Synchronisation après validation du segment : validation réussie → ajoutez la ligne du segment dans le tableau de storyboard de 01, ajoutez la section du segment dans 03/04, modifiez 02 uniquement en cas de nouvelle entité. La description de la dernière image est écrite dans l'enregistrement de ce segment (point d'ancrage pour la connexion SCENE CONTEXT du segment suivant).

Relation avec les six phases : le découpage par segment ne saute pas de phase, il exécute les phases 2-6 par tranches de segment — l'ancrage (02) et le squelette du scénario (liste des points d'intrigue de 01) restent au niveau du projet entier ; à l'intérieur d'un segment, seules les images/la vidéo/les dialogues/les entrées de montage de ce segment sont produits. Le premier lot respecte toujours la règle "produisez d'abord un premier lot complet pour validation avant de passer à grande échelle".

Registre des révisions : à chaque tour de révision, ajoutez une entrée de modification dans 01 (quoi de changé / périmètre d'impact (numéros de plan · points d'intrigue · phases) / fichiers impactés / essence des propos de l'utilisateur), ne réécrivez pas la section historique — la trajectoire de révision de 01 est en elle-même une base pour la reprise après interruption. Point d'écriture unique (V2.9) : les enregistrements de modification ne sont écrits que dans 01 ; 00/02 ne réenregistrent pas l'historique des modifications — 02 ne modifie que le champ lui-même (mise à jour de l'entrée d'ancrage), 00 ne met à jour l'état de l'intrigue qu'à la fin de l'épisode. Écrire aux trois endroits = mauvaise récupérabilité et risque élevé d'oublier une modification.

Liste de rétro-écriture des modifications côté générateur (V3.7) : après avoir modifié le prompt dans le canevas/l'outil de génération, réécrivez à trois endroits et vérifiez mot à mot — ① le bloc de segment correspondant dans 04 ② les dialogues dans 05 (si concerné) ③ le tableau de storyboard dans 01 (durée/connexion/registre de modification). Les éléments OPEN sont fermés, les mises à jour PLAN/REF sont liées. La double écriture manuelle facilement oubliée, exécutez check.py --partial après la rétro-écriture.

Projets où le canevas/l'outil de génération est la source (l'utilisateur modifie directement dans l'outil)

Lors de l'utilisation d'un canevas de type Toonflow pour la génération, l'utilisateur modifie souvent directement le prompt dans le canevas, déplace des nœuds, en supprime — le canevas est alors le site d'exécution, 01-06 est la source de décision. Leur relation :

  • Ne cherchez pas la synchronisation en temps réel (leçon pratique : ce n'est qu'en criant "synchronisez" que l'on rattrape, et chaque synchronisation est une perte de temps) → remplacez par une synchronisation par lots en différé : synchronisez en une fois à la fin d'un tour de génération. Le contenu de la synchronisation est une "fiche de résumé" (ID du nœud + une ligne d'état + les points de divergence avec la documentation), ne remplissez pas le texte complet mot à mot.
  • Arbitrage de conflit : si le canevas et la documentation sont en désaccord et que l'utilisateur a déjà finalisé sur le canevas → le canevas fait foi, la documentation consigne la différence et met à jour la décision (ne ramenez pas le canevas à la documentation).
  • Marquage de finalisation : le nœud "Enregistrer l'image finalisée pour éviter la contamination" créé par l'utilisateur dans le canevas est une pratique efficace → la matrice d'actifs de la documentation enregistre l'ID du nœud de finalisation, ne l'écrasez pas lors de la régénération.
  • L'ID de nœud est consulté dans la table, pas supposé (V3.7) : la seule source de l'ID de nœud du canevas est la table de correspondance du projet (matrice d'actifs de 02/03, fiche de résumé du canevas) ; l'agent ne doit pas inventer d'ID sur la base de sa mémoire ou de la similarité perçue. Si l'ID n'est pas dans la table → arrêtez-vous et consultez la table ou demandez à l'utilisateur, ne connectez pas/n'opérez pas sur un ID non enregistré (leçon pratique : un ID supposé a connecté le mauvais nœud ou le lot entier n'a pas été exécuté en silence).
  • Le numéro de ref = ordre de création de la connexion (correction V3.15) : append n'ajoute généralement que de nouveaux numéros (ref7/ref8), ne réorganise pas les existants — le prompt doit simplement ajouter dans la table d'ordre d'images suspendues ; ce n'est que si "l'insertion en cours de route entraîne une réorganisation des ref existants" que l'on supprime toutes les connexions existantes et que l'on reconnecte dans l'ordre final. Quelle que soit la méthode, la table d'ordre d'images suspendues de 04 doit être modifiée en synchronisation, et vérifier une par une la correspondance entre {{ref N}} et la déclaration d'utilisation (leçon pratique de l'ancien canevas : insertion décalée dans v21/v22).
  • Registre des versions lors d'une renvoi intégral du générateur (testé V3.9 ; canevas actuel setPrompt) : le générateur n'a pas d'édition locale. Avant chaque renvoi, enregistrez d'abord le prompt courant comme un résumé de version (numéro de version + point de modification) et écrivez-le dans le registre de modification de 01. Après le renvoi, comparez avec la documentation 04, il est interdit de se fier à la mémoire contextuelle pour connaître la version courante (si la version est erronée, le segment entier doit être repris). Cette discipline est conservée après un changement de logiciel de canevas, les opérations spécifiques sont réécrites selon le nouvel outil.
  • Déclencheur de synchronisation : lorsque l'utilisateur dit "synchronisez", ou à la fin d'un tour de génération, ou avant d'entrer dans la phase 5/6 — trois points de déclenchement, pas de synchronisation entre les deux.

Priorité aux tests de capacité sur l'enregistrement de verrouillage (leçon pratique : le plan principal "sortie vidéo H3 directe des dialogues + auto-extraction du timbre vocal" verrouillé dans GATE0 a été directement invalidé car la version passerelle de H3 ne prend pas en charge l'audio) : la liste des capacités verrouillée dans GATE0 est un guide pour la planification, pas une garantie — avant la génération, la capacité réelle disponible côté outil prévaut ; lorsque le plan principal est invalidé, basculez sur le chemin alternatif (voix → synchronisme cosyvoice) et enregistrez la raison du basculement dans 01/02, ne réessayez pas une capacité déjà jugée non prise en charge. Transformation en points de vérification (V2.9) : lors du verrouillage du modèle dans GATE0, indiquez le fournisseur/la passerelle (le même nom de modèle peut avoir des capacités différentes selon le fournisseur — le generateAudio de H3 de moma et apiMart, l'un refuse, l'autre accepte) ; avant la génération, testez les capacités clés auprès du fournisseur actuel (sortie audio directe/nombre et volume des images de référence/limite de durée). Les différences de fournisseur déjà enregistrées sont dans la section "Mémento des différences entre fournisseurs" de models.md. En cas de conflit entre le résultat du test et le mémento, le test actuel prévaut et doit être rapporté.

Discipline de révision pour une modification unique (modifiez une mesure, lisez les trois mesures) : après toute modification d'un plan/d'un temps, vous devez relire le temps précédent et le suivant, et vérifier spécifiquement trois choses : la position du personnage (la phrase de position / le PLAN DE LOCALISATION sont-ils encore valides ?), l'état de possession de l'accessoire (il était dans la main gauche dans le plan précédent, il ne peut pas être dans la main droite dans ce plan), qui est présent (la règle par défaut pour les figurants "0" est-elle encore valide ?). Lors de l'écriture, l'état spatial est dans l'esprit ; lors de la modification, il n'y est plus — ne pas relire conduit à une téléportation.

  • Avant de modifier, auto-résumez (leçon pratique V2.9 + V3.0 abaissé à auto-attestation) : pour un micro-ajustement de plan (changement de caméra/plan/composition/direction de préhension), avant de modifier le prompt, résumez d'abord en une phrase votre compréhension de la composition ("Je comprends : plongée depuis le haut, elle est assise à côté de lui à sa droite épaule contre épaule, les deux ne se touchent pas") et écrivez-la dans le registre de modification de 01. Ne posez une question à l'utilisateur que si la formulation est ambiguë et que le contexte ne permet pas de lever l'ambiguïté. La levée d'ambiguïté suit la liste des ambiguïtés orales de cinematography. Le coût d'une phrase d'auto-résumé ≈ 0, le coût d'un re-travail = une génération + une attente — l'auto-résumé arrête 95% des biais de compréhension avant la mise à l'écrit. En cas de véritable ambiguïté, passez à une question.
  • Finalisation de l'image de situation déclenche une relecture (V2.9 — transforme la règle "modifiez une mesure, lisez les trois mesures" d'une correction a posteriori en action par défaut) : lors de la finalisation de toute image de situation/première image (y compris après une correction et une nouvelle finalisation), vous devez relire tous les blocs de plans vidéo qui la référencent, vérifier un par un si la description de l'image est cohérente avec la nouvelle image finalisée (posture/préhension/position/tenue vestimentaire) — les blocs de plans incohérents sont modifiés sur place, n'attendez pas une échec de génération pour les détecter.

De même : le paysage sonore est aussi une instruction d'action — si le paysage sonore écrit "le grelot explose au moment de l'impact", la vidéo va vraiment le jouer. Si vous modifiez l'image, vous devez synchroniser les trois endroits (description de l'image du bloc de plans / paysage sonore AUDIO / tableau de storyboard 01). Si vous modifiez la coupe, vous devez lire la coupe adjacente (la position est un état continu).

Paliers de repli en cas de résultat insatisfaisant (si un plan a échoué/sa qualité est médiocre, essayez dans l'ordre) : Avant d'entrer dans les paliers, vérifiez d'abord la générabilité (prompt-rules 0.7) : si la liste des signes d'échec est atteinte (mouvements de mains en trois étapes ou plus / mots déductifs / actions négatives / double sujet et objet exerçant une force précise) → appliquez d'abord les cinq méthodes de réécriture pour changer la réalisation, ne modifiez pas la scène.

…

[Version tronquée pour la traduction]

Skills associés