xiao44119-sketch/llm-video-skills

Réaliser des vidéos de codage avec un storyboard

Référence conditionnelle

• Ce n'est que lorsque l'utilisateur saisit effectivement /goal pour lancer ou reprendre un objectif qu'il faut lire intégralement references/goal-director.md et exécuter les contraintes du réalisateur qui y sont décrites.
• Lors de la réalisation, modification, prévisualisation ou rendu d'un plan ordinaire, ainsi que lorsqu'on discute simplement de /goal, ce fichier n'est pas lu et il ne doit pas être chargé par précaution.

Planifier d'abord, ne pas écrire de code avant confirmation

1. Lisez toutes les images de .media/storyboard/ et regroupez-les selon le principe « même sujet apparaît ou se transforme en continu ».
2. Écrivez dans STORYBOARD.md les groupes, les dépendances des plans et la liste des ressources ; la liste doit indiquer la taille d'affichage à l'écran.
3. Pour les plans avec transformation continue interne, comparez dans RENDER_STRATEGY.md les solutions possibles et verrouillez la méthode d'implémentation → references/render-strategy.md.
4. Présentez le tableau des groupes et la liste des ressources à l'utilisateur et attendez sa confirmation.

timeline.json est la seule source de planification pour les numéros de plan, les heures de début/fin et la durée totale ; ne dupliquez pas la timeline dans plusieurs fichiers Markdown.

Structure principale de production

1. Pour les plans d'un même groupe, établissez d'abord un moteur de rendu de sujet partagé, un CameraRig, un chargeur d'actifs et un état de scène ; les fichiers de plan ne conservent que l'état et les paramètres temporels.
2. Reproduisez d'abord les images clés du storyboard en statique et compositez une planche-contact simple pour validation par l'utilisateur ; si les points de terminaison ne sont pas validés, ne faites pas d'interpolation ni d'easing.
3. Une fois la statique validée, créez l'animation et livrez uniquement un aperçu déplaçable en attendant la validation.
4. Les plans suivants évoluent à partir de la dernière image validée du plan précédent : continuation, transformation, ajout ou disparition, sans redessiner ni recouvrir les sujets existants → references/scene-continuity.md.
5. Une fois tous les plans validés, intégrez-les dans la timeline totale unique, vérifiez les raccords, la durée totale et une lecture complète ; procédez au rendu final après confirmation de l'utilisateur.

Les plans, sujets et ressources déjà validés sont verrouillés. Si un problème provient des dimensions, de la position, du recadrage, de la caméra ou des effets, modifiez uniquement les paramètres correspondants ; ne regénérez pas les ressources sauf si l'utilisateur rejette explicitement la ressource elle-même.

Paralléliser selon les dépendances, ne pas traiter les plans dans l'ordre numérique

• Pour les transformations continues d'un même sujet ou les parties qui doivent hériter de la dernière image du plan précédent, suivez l'ordre de dépendance.
• Les plans indépendants (scènes, arrière-plans, ressources transparentes, plans complets ne dépendant pas de la composition du plan précédent) peuvent être produits en parallèle.
• Une fois l'interface de la scène mère partagée stabilisée, les états, couches de superposition et animations internes de différents plans peuvent être produits en parallèle.
• Les branches parallèles ne peuvent écrire que dans leur propre répertoire ; elles ne modifient pas la timeline totale, les fichiers sources de la scène mère partagée ni les plans déjà validés ; la sortie se limite à une planche-contact ou un aperçu.
• Si un plan ultérieur ne dépend que de la transition d'entrée, le sujet et l'animation peuvent être achevés en premier, puis les paramètres de la dernière image du plan précédent sont appliqués à la fin.

Chemin d'exécution le plus court et contraintes de prompt

• Chaque prompt d'exécution se concentre uniquement sur un livrable que l'utilisateur souhaite voir à ce moment, en précisant clairement la portée d'écriture autorisée, le nombre minimal d'étapes, le point d'arrêt explicite et ce qui ne doit pas être fait dans ce tour ; ne transformez pas un aperçu d'étape en validation finale.
• Lorsque l'utilisateur demande un « aperçu », le chemin par défaut est uniquement : effectuer les modifications ou montages nécessaires → confirmer que la page peut se charger → lancer Studio → renvoyer le lien. N'utilisez pas check, des instantanés batch, des planches-contact, des tableaux de raccords image par image, des hachages ou une lecture complète pour bloquer l'aperçu.
• Les compositions temporaires, les enchaînements partiels de plans et les points d'entrée de débogage ne sont pas une intégration finale. L'objectif est simplement de permettre à l'utilisateur de voir une séquence continue ; la vérification des raccords, la révision de la durée totale et la lecture complète sont réservées à l'étape d'intégration finale unique, après validation de tous les plans.
• La validation doit répondre directement à la question spécifique du moment. En l'absence d'erreur ou de problème visuel clair, n'ajoutez pas de scripts de diagnostic, de détection de version, de matrices de régression, de recherche inverse, de captures d'écran redondantes ou de vérifications « au cas où ».
• N'empilez pas plusieurs navigateurs, instances Studio, check, snapshot ou processus render en parallèle ou en série dans la même session. Exécutez un seul processus frontal nécessaire au livrable actuel ; si un résultat existant est disponible, livrez-le immédiatement.
• Si une validation non-rendu n'affiche aucune nouvelle sortie pendant plusieurs minutes ou dépasse manifestement le temps normal, arrêtez immédiatement et vérifiez le point de blocage le plus direct ; n'attendez pas sans retour pendant des dizaines de minutes, ne relancez pas à l'identique et n'ajoutez pas d'autres validations.
• Les prompts donnés aux sessions d'exécution utilisent par défaut « s'arrêter après avoir terminé » : une fois l'exigence actuelle de l'utilisateur atteinte, retournez le résultat, ne passez pas automatiquement à l'étape suivante et n'étendez pas le travail parce que les vérifications techniques sont réussies.

Règles de représentation et de mouvement

• Utilisez des textures transparentes de haute qualité pour les accessoires statiques complexes ; Canvas/SVG pour les structures géométriques et les formes régulières ; Canvas pour les particules, fragments, fumées et points lumineux.
• La croissance continue, l'envahissement et l'enveloppement doivent séparer les couches géométrique, texture et animation. Ce qui s'étend est la géométrie, pas les pixels de la texture.
• Une texture 2D unique ne peut pas générer de faces supérieures, latérales ou d'occlusion qui n'existent pas dans l'image source ; si une vraie perspective est nécessaire, utilisez des ressources multi-angles ou 3D, et expliquez d'abord les limites de l'approximation.
• Le recul de la caméra, l'éloignement de la scène et la réduction d'un objet ne sont pas la même chose → references/camera-motion.md.
• Si un même problème de positionnement ou de mise en page n'est pas résolu après trois tentatives, créez alors un panneau de réglage minimal → references/tune-panel.md.

Ressources et déterminisme

• La taille des images sources ne doit pas dépasser le double de la taille d'affichage à l'écran ; privilégiez WebP q85 ; les images d'une scène unique ne doivent pas dépasser 3 Mo → references/asset-budget.md.
• Zéro réseau lors du rendu : n'utilisez pas de scripts CDN ni de polices en ligne.
• Le code propriétaire ne doit pas utiliser Math.random, Date.now ou le polling ; exécutez await img.decode() avant le premier dessin.

Points d'entrée et état

• /index.html : point d'entrée unique pour la timeline totale et le rendu final, toujours initialisé à 0 seconde.
• /compositions/NN-name.html : point d'entrée de débogage pour un groupe ou un plan individuel, doit pouvoir s'initialiser indépendamment.
• La timeline totale doit être une véritable composition, pas un assemblage utilisant des iframes ou des changements de page.
• HANDOFF.md ne conserve que l'état valide actuel, les éléments verrouillés, les fichiers courants, les rejets sous forme de phrases courtes et la prochaine étape ; restez concis, n'enregistrez pas de traces de processus, de longs prompts ou de rapports historiques.

Validation et livraison minimales

• Phase statique : une planche-contact des images clés du storyboard + « En attente de validation ».
• Phase d'animation : un aperçu déplaçable + « En attente de validation ».
• Aperçu d'enchaînement temporaire : page chargeable + lien Studio ; pas de planche-contact, pas de vérification des raccords image par image, pas d'exécution de check formel.
• Phase de correction : image ou aperçu corrigé + une phrase d'explication.
• Phase finale : aperçu total ou vidéo + durée et chemin de sortie.
• Les vérifications quotidiennes se contentent de confirmer que la page se charge, que les ressources sont visibles et que les images clés sont correctes ; le check formel n'est exécuté qu'une seule fois lors de la finalisation de l'animation, de l'intégration finale ou si un problème d'exécution spécifique le nécessite. Ne répétez pas lint, check, instantanés batch ou régression image par image.

Par défaut, ne générez pas de scripts d'audit, de JSON de validation, de listes, de notes de livraison, de rapports d'identité/mesh/particules, de hachages image par image, de différences de pixels, de rendus redondants, de validation par glissement inverse ou de planches-contact multi-versions. En cas de problème spécifique, vérifiez uniquement le code concerné, l'erreur ou une image problématique, corrigez et montrez le résultat ; ne générez un rapport de diagnostic formel que si l'utilisateur le demande explicitement.