sanky369/vibe-building-skills

Script Writer pour Remotion

Transformer un objectif vidéo plus (optionnellement) une base de code en un JSON de Script Remotion — une spécification scène par scène suffisamment précise pour qu'un agent Remotion puisse l'implémenter sans poser de questions supplémentaires. Le principe directeur : le script est la source de vérité unique pour le rendu — chaque durée, élément, animation et ligne de voix off est énoncé en chiffres et en chaînes exactes, jamais « environ 5 secondes » ou « un texte d'introduction ». Deux agents recevant la même entrée doivent émettre des scripts structurellement identiques.

Quand l'utiliser / quand ne pas l'utiliser

• Utiliser lorsque la sortie sera rendue par programmation avec Remotion : démos de produits d'applications web, tutoriels de codage avec code animé, pièces de graphisme animé, vidéos de visualisation de données, animations sociales courtes.
• Le concept et les beats ne sont pas encore décidés pour une vidéo produit → exécuter d'abord skills/creative/product-video ; sa feuille de beats devient la liste des scènes de cette compétence.
• Vidéo avec personne à l'écran → skills/creative/talking-head (Remotion n'est pas l'outil adapté).
• Graphismes statiques → skills/creative/social-graphics.
• Cette compétence écrit uniquement le script — l'implémentation des composants React, l'aperçu dans Remotion Studio et le rendu sont effectués en aval par les compétences d'agent de Remotion elles-mêmes.

Fichiers de règles — lire avant d'écrire le script

• rules/prompt-structure.md — les champs d'entrée à partir desquels le script est construit (goal, targetAudience, code, videoType, duration, style, animations, transitions). Lire lors de la normalisation de l'entrée dans l'objet d'entrée.
• rules/script-generation.md — la structure JSON de sortie faisant autorité et les instructions de génération. Lire avant d'émettre le script ; le squelette ci-dessous est un résumé, ce fichier est le contrat.
• rules/animation-patterns.md — le vocabulaire approuvé d'animations/transitions avec des formes JSON exactes et des directives de timing. Lire lors de la spécification de toute valeur animation ou transitionToNextScene ; ne pas inventer de types d'animation en dehors de celui-ci.
• rules/scene-templates.md — des JSON de scènes prêts à l'emploi pour des cas courants (carte titre, vitrine de fonctionnalité, démonstration de code, visualisation de données, outro/CTA). Lire lorsqu'une scène correspond à un motif connu ; partir du modèle et éditer.
• examples/product-demo-example.json — un script de travail complet. Lire pour calibrer la granularité.

Prise en charge

Poser en un seul lot serré, uniquement ce qui manque (noms de champs selon rules/prompt-structure.md) :

1. goal et targetAudience — quel objectif la vidéo doit-elle atteindre, pour qui ?
2. videoType — product-demo | coding-tutorial | animation | data-visualization | social-media ?
3. duration (secondes) et plateforme de destination (décide largeur/hauteur/fps).
4. code — chemin vers la base de code, URL du dépôt ou extraits de code, si la vidéo présente une application ou du code.
5. style — contraintes visuelles/de marque (couleurs, polices, logo ; un guide de style skills/creative/creative-strategist s'il en existe un).

Inférer au lieu de demander : language à partir de la base de code ; dimensions à partir de la plateforme (1920×1080 paysage par défaut, 1080×1920 pour le social vertical, fps 30) ; préférences d'animation/transition à partir de style si non fourni. Ne pas bloquer : avec goal + videoType + duration connus, énoncer les hypothèses et procéder.

Workflow

1. Analyser le matériau source

Si code est fourni, l'explorer : identifier les fonctionnalités clés, les flux utilisateur, les structures de données et les surfaces UI qui valent la peine d'être montrées. Classer les fonctionnalités par pertinence par rapport à goal — la vidéo montre les 3 à 5 principales, pas tout. Si pas de code, extraire la liste équivalente de la description de l'utilisateur.

2. Structurer les scènes

Règles de décision par videoType :

• product-demo → carte titre → problème/contexte → une scène par fonctionnalité (3 à 5 principales) → outro/CTA.
• coding-tutorial → titre → mise en place du concept → une scène par étape de code (montrer le code, puis expliquer) → récapitulatif.
• data-visualization → titre → contexte → une scène par graphique/aperçu → conclusion.
• social-media → scène d'accroche (≤3s) → 1–2 scènes de révélation → CTA ; total ≤60s.
• animation → dériver les beats du concept créatif (ou de la feuille de beats skills/creative/product-video).

Le calcul du timing est obligatoire : les durées des scènes plus les chevauchements de transition doivent correspondre exactement à duration. TransitionSeries superpose les scènes adjacentes — prendre en compte le chevauchement, ne pas simplement additionner les durées. Garder un total sous environ 5 minutes (heuristique de performance de rendu).

3. Spécifier chaque scène complètement

Pour chaque scène, remplir tous les champs : sceneNumber, title, durationInSeconds, visuals.background, visuals.elements[] (type, chaîne de contenu exacte, police, taille, couleur, position, animation de rules/animation-patterns.md), audio.voiceover (la ou les phrases exactes prononcées — vérifier qu'elles tiennent dans la durée de la scène à environ 2,5 mots/seconde) et transitionToNextScene. Utiliser les modèles rules/scene-templates.md là où ils correspondent.

4. Compiler les actifs et les exigences techniques

Lister chaque image, clip vidéo, piste audio, police et logo référencé par une scène dans requiredAssets — aucun élément référencé ne peut manquer dans la liste. La génération d'actifs est hors de portée : marquer chacun comme fourni par l'utilisateur ou le décrire précisément ; les images fixes peuvent être produites via skills/creative/image-generation (pipeline du dépôt : docs/creative_cli.py, modèle fal-ai/nano-banana-pro). Lister remotionPackages (par exemple @remotion/transitions à chaque fois que des transitions sont utilisées) et les bibliothèques tierces.

5. Valider par rapport à la barre de qualité, puis délivrer le JSON

Délivrer le script plus la note de passation (ci-dessous). L'agent Remotion en aval génère les composants, configure la composition, prévisualise dans Studio et effectue le rendu.

Format de sortie requis

Émettre un objet JSON correspondant exactement à la structure dans rules/script-generation.md :

{
  "videoMetadata": {
    "title": "...", "durationInSeconds": 60,
    "width": 1920, "height": 1080, "fps": 30,
    "videoType": "product-demo"
  },
  "scenes": [
    {
      "sceneNumber": 1, "title": "...", "durationInSeconds": 5,
      "visuals": {
        "background": "#RRGGBB ou référence d'actif",
        "elements": [
          { "type": "text|image|code|chart", "content": "contenu exact",
            "animation": { "type": "<depuis rules/animation-patterns.md>", "durationInSeconds": 1 } }
        ]
      },
      "audio": { "voiceover": "Phrase(s) exacte(s) prononcée(s)." },
      "transitionToNextScene": { "type": "<depuis rules/animation-patterns.md>", "durationInSeconds": 1 }
    }
  ],
  "requiredAssets": { "images": [], "videos": [], "audio": [], "fonts": [], "logos": [] },
  "technicalRequirements": { "remotionPackages": [], "thirdPartyLibraries": [] }
}

Suivre le JSON avec une courte note de passation en markdown : vérification de la durée totale (calcul des scènes montré), les 1 à 3 hypothèses formulées, et les actifs que l'utilisateur doit fournir avant le rendu.

Barre de qualité (vérifier avant de délivrer)

• Les durées des scènes + les chevauchements de transition correspondent exactement à videoMetadata.durationInSeconds ; montrer l'arithmétique dans la note de passation.
• Chaque animation et type de transition type existe dans rules/animation-patterns.md — pas de types inventés.
• Chaque ligne de voix off tient dans sa scène à environ 2,5 mots/seconde ; aucune scène n'a de visuels sans but énoncé par la voix off ou le titre.
• Chaque actif référencé dans une scène apparaît dans requiredAssets ; les polices utilisées par les éléments de texte sont listées.
• La conformité Remotion est intégrée dans la spécification : timing basé sur les trames via useCurrentFrame(), ressorts avec damping: 200 pour les révélations, machine à écrire via le découpage de chaîne (pas d'opacité par caractère), aléatoire déterministe uniquement (random() de remotion, jamais Math.random()), premountFor sur les séquences lourdes, <Sequence>/<Series>/<TransitionSeries> pour l'ordonnancement.
• Les champs content sont des textes finaux, pas des espaces réservés comme « description de fonctionnalité ici ».
• La voix off est rédigée automatiquement — signaler dans la note de passation que l'utilisateur peut souhaiter la peaufiner.

Intégration

• skills/creative/product-video → fournit en entrée : concept + feuille de beats + images clés pour les vidéos produit ; chaque beat devient une scène.
• skills/creative/creative-strategist → fournit en entrée : guide de style (couleurs, polices, ambiance) appliqué à visuals et style.
• skills/creative/original-design → fournit en entrée : un brief de langage de design ; le vocabulaire visuel de chaque scène doit provenir de ce monde.
• skills/creative/image-generation → produit : les actifs fixes listés dans requiredAssets.images.
• skills/creative/social-graphics → consomme : les images fixes/thumbnails rendues pour les actifs de publication.
• En aval : les compétences d'agent Remotion (en dehors de ce dépôt) consomment le JSON pour construire les composants, prévisualiser et effectuer le rendu.