motion-video · Faire des animations vérifiables avec du code

Ce skill résout un problème très concret : les petits modèles (Flash / mini / turbo) peuvent écrire du CSS et du Canvas, mais les animations qu'ils produisent ont souvent l'air « écrites, mais pas vraiment animées » — les états intermédiaires sont sautés, l'easing est faux, les éléments clés apparaissent à d'autres moments, la fin reste bloquée à mi-chemin. Le modèle ne le voit pas lui-même, car il n'a pas d'yeux.

L'approche ici n'est donc pas de « lui apprendre à mieux écrire », mais de transformer l'animation en un artefact d'ingénierie vérifiable par machine :

Spécifications d'abord, code ensuite — traduire les jugements esthétiques en valeurs numériques dans un tableau.
L'image doit être une fonction pure de t — forcer structurellement l'écriture des états intermédiaires.
Les calculs sont confiés aux scripts — Bézier, ressort, décalage, contraste : tout passe par l'outil, pas de calcul mental.
Utiliser un rendu déterministe image par image — le même code donne toujours la même image.
Validation automatique : d'abord au niveau des valeurs, puis au niveau des pixels.
Ce n'est qu'après que la machine dit « la structure est OK » que l'œil humain juge la composition.

L'écart ne se comble pas avec une formule magique. Il se comble avec ces six étapes qui transforment « ne pas pouvoir penser correctement » en « détectable et réparable ». D'où vient l'écart, ce qui peut être comblé et ce qui ne peut pas l'être, voir references/delta-vs-opus.md.

Priorité à la qualité : n'économiser que les surcoûts inutiles, pas la vérification

Cette règle prime sur les suivantes. L'objectif de ce skill est de produire des vidéos de qualité Opus, pas les moins chères possible. Donc le critère pour « faut-il faire ceci ? » n'est pas la rapidité, mais l'amélioration de la qualité.

Seul un type de surcoût peut être économisé : les répétitions inutiles, inefficaces, qui se font concurrence. La densité de vérification, la qualité du rendu, l'image par seconde, le flou de mouvement — tout cela ne doit jamais être sacrifié.

Ce qui est permis d'économiser (du gaspillage, économiser n'ajoute ni n'enlève rien)

Gaspillage	Comment économiser
Lancer 4 Chrome en concurrence pour le CPU	Séquentiel (plus rapide que concurrent en pratique), `render.mjs` a un verrou d'instance unique intégré.
Un document de spécification de 20 Ko par chapitre	Un seul `storyboard.md` complet.
Appeler `render --still` à chaque fois pour une seule image	Extraire 6 à 8 points temporels en une seule fois.
Analyser à plusieurs reprises le même métrage	Analyser une fois, écrire le résultat dans le storyboard.
Enregistrer chaque image PNG sur le disque puis la relire	A déjà `optimizeForSpeed` ; pour les très grands projets, utiliser image2pipe (cinema-grade.md §9).
Pour être « sûr », vérifier trois fois la même chose	Deux vérifications suffisent (numérique + pixel) ; une troisième n'ajoute aucune information.

Ce qui est interdit d'économiser (économiser = réduire la qualité)

Interdit d'économiser	Raison
Un `audit` complet, incluant le traitement de chaque jump / flat	C'est la dernière étape avant livraison ; la sauter = pas de validation.
`verify --idempotent`	Si l'idempotence est cassée, toutes les vérifications suivantes ne sont pas fiables.
`rigcheck` (à chaque modification d'un personnage ou d'une pose)	Un os mal positionné ne se voit qu'avec des chiffres, pas à l'œil nu.
Flou de mouvement dans la version livrée	L'impression visuelle avec ou sans obturateur est d'un cran inférieur, ce n'est pas une simple amélioration.
60 fps pour les mouvements rapides	À 30 fps, les membres en mouvement rapide saccadent, c'est un défaut, pas un compromis.
Vérification par échantillonnage d'images (multiples moments + zoom local)	1 image ne montre pas les problèmes intermédiaires ; au moins 6 images + un zoom 2-3× sur les parties critiques.
Relancer après correction (au lieu de « ça devrait être bon »)	Si vous n'avez pas relancé, vous n'avez pas corrigé.

Critère en une phrase

Économiser du temps d'attente, c'est acceptable ; économiser une « chance de détecter une erreur », ce ne l'est pas.

Un rendu de 70 minutes est inacceptable, non pas parce que « 70 minutes c'est trop long », mais parce que 85 % de ces 70 minutes sont passées à ce que 4 processus se disputent le CPU — l'attente n'a apporté aucune qualité. Alors que passer 4 fois plus de temps de rendu pour un obturateur à 180 ° apporte une réelle amélioration visuelle — cette dépense est nécessaire.

Le bon ordre pour accélérer

D'abord éliminer le gaspillage : concurrence en série, fusionner les démarrages redondants, supprimer les documents superflus, extraire par lots.
Ensuite optimiser l'implémentation : paramètres de capture d'écran, plusieurs onglets dans un seul Chrome, codage direct sans écriture sur le disque.
Enfin seulement envisager de réduire la vérification — et cette étape ne devrait presque jamais arriver ; si elle arrive, c'est que les deux premières étapes n'ont pas été faites.

Règles absolues

Si l'une d'elles est violée, la production n'est pas vérifiable et doit être refaite.

Pas de code sans spécifications. Produire d'abord le tableau des plans et le tableau de la ligne de temps (ÉTAPE 1). Chaque élément du tableau doit avoir trois intervalles de temps enter / active / exit. S'il en manque un, c'est que vous n'avez pas encore clairement défini quand cet élément existe. Mais si l'utilisateur donne seulement une phrase (« Fais quelque chose de génial », « Montre tes capacités », « Donne tout »), ne lui demandez pas d'interview — remplissez vous-même les quatre emplacements (motif/méta-récit/forme/niveau) et écrivez-les dans storyboard.md, puis commencez directement. Voir references/wish-mode.md.
Tous les états visuels sont des fonctions pures de seek(t). Interdiction d'utiliser requestAnimationFrame, Date.now(), performance.now(), Math.random(), des compteurs auto-incrémentés, et des @keyframes/transition CSS autonomes. Le même code avec le même t doit toujours produire exactement le même pixel.
Tous les calculs numériques passent par des scripts, interdiction de calcul mental. Points de contrôle de courbe, paramètres de ressort, pas de décalage, conversion de coordonnées, rapport de contraste, chaîne linear() — tout doit être produit par ease.mjs. Avant qu'un tel nombre n'apparaisse dans votre réponse, vous devez avoir une sortie d'outil. Voir ci-dessous « Les chiffres aux outils, le jugement à vous ».
Après chaque modification, vous devez exécuter verify et render + audit. FAIL ne doit pas être livré. Chaque WARN doit être accompagné d'une explication : « corrigé » ou « c'est intentionnel, parce que… ». Ne passez pas directement au rendu complet sans exécuter verify — cela ne fera que gaspiller 8 secondes supplémentaires pour un résultat flou « l'image n'a pas bougé » sans en connaître la cause.
Livraison en trois parties : vidéo finale (mp4/webm/gif) + planche contact (-sheet.png) + conclusion de l'audit.
Si vous n'êtes pas sûr de l'esthétique, proposez des alternatives, ne devinez pas. Deux choix de couleurs, deux rythmes, laissez l'utilisateur choisir. C'est mieux que de livrer une version médiocre.
N'attendez pas les assets, créez-les vous-même. La livraison ne doit contenir aucune mention comme « suggérer d'insérer une image », « mettre une image ici », « attendre que les assets arrivent ». La pipeline de rendu se résume à HTML/CSS/SVG/Canvas — tous les éléments visuels ne peuvent être produits que par du code. Besoin d'effets lumineux, de textures, de formes, d'icônes ? Consultez d'abord references/asset-recipes.md (20 catégories d'extraits prêts à l'emploi : halos, balayages lumineux, grains, verre, néons, grilles, illustrations abstraites, particules, sphères filaires, graphiques, silhouettes urbaines, effets glitch, lignes de balayage, jeux d'icônes, faisceaux lumineux, profondeur de champ, textures de tissu, bokeh, pseudo 3D). Si rien ne correspond, écrivez vous-même un chemin SVG. Interdiction d'utiliser des emoji ou des symboles Unicode comme éléments graphiques. Chaque image doit comporter au moins trois couches (fond dégradé/grille → sujet → grains/bokeh d'ambiance), au moins 2 éléments visuels créés par vos soins, et 1 indice de profondeur (ombre/dégradé/superposition de couleurs/grains). Une image avec une seule couche, composée uniquement de texte et de blocs de couleur = insuffisante.
Priorité aux assets existants, interdiction de tout reconstruire. Si l'espace de travail contient déjà des squelettes/spécifications/composants/maquettes assemblés, ils doivent être réutilisés intégralement, sans recalculer aucune valeur. Utilisez rigcheck.mjs --ref pour prouver que vous utilisez les valeurs d'origine. Enregistrement d'incident : lors d'une reconstruction, head.pos est passé de [-6.8, -182.5] à [0, -248] (décalage de 65,9 px), torso.pv de [160, 160] à [160, 291] (décalage de 131 px). Le résultat était que la tête flottait à gauche du corps, et « l'inspection visuelle » ne l'a pas détecté — car l'œil humain interprète cela comme « un personnage ». Ce genre d'erreur doit être détecté numériquement.
Liste blanche des assets. N'utilisez que les assets explicitement listés dans storyboard.md. Les autres fichiers de l'espace de travail (produits de la version précédente, images de personnages non concernés, configurations d'autres projets) sont strictement interdits, même s'ils semblent utilisables. Si vous avez besoin d'un nouvel asset, ajoutez une ligne dans le storyboard avec une explication de son utilisation, puis cherchez-le.
Ne relâchez pas la vérification, et n'exécutez jamais de rendu concurrent. Un WARN dans audit ne signifie pas « on peut livrer » : les sauts brusques (jump) et les images unies (flat) doivent être réduits à zéro ou expliqués un par un, sinon, refaites. Tout FAIL dans verify/rigcheck interdit de continuer. Le rendu ne doit jamais exécuter plus d'un processus render.mjs à la fois — le script a un verrou d'instance unique ; la concurrence ne fait que se disputer le CPU. Pour paralléliser, ouvrez plusieurs onglets dans un seul Chrome (voir cinema-grade.md §9), ne lancez pas plusieurs processus.

Les chiffres aux outils, le jugement à vous

Ce type de modèle (Flash / mini / turbo) a une tendance commune : il préfère estimer plutôt que d'utiliser des outils. Il pense que le calcul mental a un coût nul et que les outils doivent être attendus. Ce calcul de coût est erroné ; clarifions-le avec des chiffres :

	Calcul mental	Appel à `ease.mjs`
Temps direct	0 seconde	Environ 0,3 à 0,5 seconde
Probabilité de calcul correct du premier coup	30 à 40 % (un mauvais point de contrôle Bézier change toute la nature de la courbe)	100 %
Coût d'une erreur	Rendu de 90 images ≈ 8 secondes + inspection visuelle, et on ne voit probablement pas l'erreur, juste « ce n'est pas assez fluide »	0
Coût attendu	0 + 0,5 × (8 + 30) ≈ 19 secondes, avec une baisse silencieuse de la qualité	0,5 seconde

Les 0,5 seconde économisées par le calcul mental sont la forme d'économie la plus coûteuse. C'est donc une exigence stricte, pas un conseil :

Les chiffres suivants doivent toujours provenir d'une sortie d'outil, jamais d'une estimation écrite dans la réponse :

Besoin	Commande à exécuter
Propriétés d'une courbe de Bézier quelconque (dépassement, palier, table d'échantillonnage)	`node scripts/ease.mjs cubic 0.22 1 0.36 1`
Paramètres d'un ressort (rebond, temps d'arrêt, arrêt prématuré)	`node scripts/ease.mjs spring 120 14 1 1.2`
Compresser une courbe en CSS `linear()`	`node scripts/ease.mjs css-linear --preset silkIn`
Pas de décalage d'un groupe d'éléments, risque de dépassement de la durée totale	`node scripts/ease.mjs stagger 7 2.4 0.5`
Vérifier si le contraste du texte est suffisant	`node scripts/ease.mjs contrast "#0b0e14" "#6d8bbd"`
Générer une échelle de gris lisible à partir d'une couleur de fond	`node scripts/ease.mjs ramp "#0b0e14" 5`

Auto-vérification en trois questions (à se poser avant la livraison ; si vous ne pouvez pas répondre, c'est une infraction) :

Chaque paramètre de courbe dans ma réponse peut-il être lié à la sortie d'une commande précédente ?
Ai-je écrit quelque part une valeur estimée comme « environ 0,3 » ? Si oui → supprimez-la, exécutez la commande.
Quand je dis « cette courbe est très fluide », est-ce parce que j'ai vu le graphique ASCII et le pourcentage de dépassement de ease.mjs, ou bien parce que j'ai deviné ?

Il veut aussi vérifier par lui-même ? Utilisez le vérificateur pour le rassurer : verify.mjs lit les styles calculés réels, pas des suppositions. Quand il veut « confirmer », l'action correcte est d'exécuter verify, pas de simuler mentalement.

Environnement

Zéro dépendance npm. Nécessite Chrome ou Edge (déjà installé) + ffmpeg + ffprobe.

ffprobe est seulement utilisé par audit pour vérifier la résolution/la durée. S'il manque, le système ne passe pas en silence : si --width/--height/--duration est déclaré, c'est FAIL ; sinon, c'est WARN avec le message « résolution inconnue (non vérifiée) ».

node scripts/render.mjs --check      # Affiche les capacités chrome / ffmpeg / node / WebSocket

Si chrome est NOT FOUND dans la sortie, utilisez --chrome <chemin> pour spécifier, ou installez d'abord un navigateur.

Que faire lorsqu'il n'y a pas de compréhension de l'image

Certains modèles (par exemple les versions de raisonnement texte uniquement) ne peuvent pas read_image. Le jugement de cette chaîne est entièrement numérique, pas basé sur des images, donc le processus peut toujours être complété : ease (paramètres) → verify (trajectoire numérique + idempotence) → audit (statistiques de pixels, les conclusions sont des chiffres) → rigcheck (assertions géométriques).

Possible : structure, mouvement, géométrie, lisibilité.
Impossible : qualité de la composition, harmonie des couleurs, cohérence stylistique, combinaisons visuelles.

Ces dernières doivent être confiées à une personne capable de voir l'image ou à un modèle de vision. Mais on peut les reporter à la fin : d'abord, utilisez les chiffres pour capturer toutes les erreurs possibles, puis montrez 6 à 8 images (--still extraction par lots + --guides superposition des zones de sécurité) en une seule fois à un humain.

Index des documents (lisez selon les besoins, pas tout en une fois)

Fichier	Quand le lire
references/wish-mode.md	Lisez d'abord ceci quand l'utilisateur donne seulement une phrase : les quatre emplacements, déduction des chapitres, tableau des valeurs par défaut, pas d'interview en mode souhait.
references/spec-and-prompt.md	Lors de l'étape 1 pour écrire le tableau des spécifications ; quand vous avez besoin d'un modèle de prompt reproductible ; pour gérer les modèles qui « ne veulent pas utiliser d'outils ».
references/code-patterns.md	Lors de l'étape 2 pour écrire le code : paradigmes `seek(t)`, bibliothèque d'easing, table `keys()` des images clés, `spring(f, z)`, SVG/Canvas, 20 effets CSS modernes.
references/asset-recipes.md	Feuilletez immédiatement quand l'image manque de quelque chose : halos, balayages, grains, verre, néons, grilles, illustrations, particules, sphères filaires, graphiques, ensembles d'icônes, bokeh, pseudo 3D.
references/rig-characters.md	Quand l'image contient un personnage à animer : pièces, chaînes de transformation parent-enfant, tableau de poses, comment appliquer les 12 principes d'animation.
references/cinema-grade.md	Avant la finalisation : flou de mouvement, paramètres d'encodage (anti-banding), vignettage, système HUD, effets de recadrage, choix de l'image par seconde, organisation de longs métrages, accélération parallèle.
references/review-checklist.md	Étape 5, inspection visuelle humaine + passage en revue un par un avant la livraison.
references/failure-modes.md	Lorsque audit/verify renvoie une erreur, pour identifier la cause.
references/delta-vs-opus.md	Pour savoir jusqu'où cet ensemble peut aller, pour décider s'il faut changer de modèle.

Orientation préliminaire : Souhait ou Besoin précis

À quoi ressemble l'entrée	Quelle voie suivre
Donne la plupart des éléments : taille/durée/contenu/style ; ou répond à vos questions.	Mode Spécifications : ÉTAPE 0 : poser les questions claires → ÉTAPE 1 : tableau des spécifications → …
Une seule phrase avec un ton d'autorisation (« Fais quelque chose de génial », « Montre tes capacités », « Comme tel type de vidéo », « Donne tout »).	Mode Souhait : sautez l'ÉTAPE 0. Ne posez pas de questions. Scannez d'abord l'espace de travail pour trouver un motif, remplissez vous-même les quatre emplacements, puis commencez à l'ÉTAPE 1. Voir wish-mode.md.

Le critère est simple : Ce qu'il n'a pas dit clairement, est-ce « attendez que je demande » ou « vous décidez » ? Si le ton est « faites comme vous voulez / donnez tout / montrez-moi », c'est le deuxième cas. Le mode souhait nécessite également d'écrire storyboard.md — la différence est que ce tableau est rédigé par vous, pas obtenu par des questions.

Flux de travail

ÉTAPE 0 · Clarifier trois choses (uniquement en mode Spécifications ; sauter en mode Souhait)

Usage : générique de projection / courte vidéo sociale / animation hero de page web / extrait de présentation / animation de croissance de données / GIF
Taille et durée : voir les valeurs par défaut dans le tableau ci-dessous, sauf demande explicite de l'utilisateur.
Émotion : stable (entreprise/finance), rapide (technologie/lancement), doux (vie/marque), dur (jeu/sport)

Usage	Taille	Durée	Images/s	Format
Générique / Lancement	1920x1080	3–6 s	30	mp4
Social portrait	1080x1920	5–15 s	30	mp4
Hero / bannière web	1920x800 ou 1440x600	2–4 s, bouclable	30	webp / apng (transparence) ; webm nécessite vérification alpha préalable
Animation de données / Graphiques	1920x1080	3–8 s	30	mp4
GIF bouclé	800x800 / 1080x1080	1–3 s, boucle parfaite obligatoire	15–20	gif / webp
Extrait de présentation	1920x1080	2–5 s par plan, puis montage final	30	mp4

Durée > 10 secondes ou > 3 plans : diviser en plusieurs fichiers de scène, chacun rendu et vérifié séparément, puis assemblé avec ffmpeg. Ne laissez pas un seul seek() gérer 30 secondes — personne ne pourra s'auto-vérifier.

ÉTAPE 1 · Écrire les spécifications (la seule étape où la liberté est totale)

Produire storyboard.md, deux choses indispensable :

① Tableau des plans

#	Temps	Que fait l'image	Mouvement principal	État final
1	0,00–1,10 s	Titre flottant lettre par lettre	y: +96→0, 75 ms de décalage par lettre	Titre en place
2	1,10–2,40 s	Ligne de progression se remplit + trois points apparaissent	scaleX: 0→1 (ease-in-out)	Ligne au bord, points alignés

② Tableau de la ligne de temps des éléments (une ligne par élément, c'est la seule référence pour le code suivant)

Élément	enter	active	exit	Propriété	Courbe
#title span	0,15 + i*0,075	Jusqu'à la fin	—	translateY 96→0, opacity 0→1	easeOutCubic
#bar b	0,30	0,30–2,40	—	scaleX 0→1	easeInOutCubic
.dots i	1,50 + i*0,15	Jusqu'à la fin	—	scale 0→1	easeOutBack

Si vous ne pouvez pas écrire ce tableau, c'est que vous n'avez pas encore assez réfléchi. Ne le sautez pas pour écrire du code ; ce que vous écrirez sera « seulement la première et la dernière image ».

La colonne « Courbe » n'est pas là pour juste un nom. Après avoir choisi un nom, exécutez immédiatement l'outil une fois pour fixer ce que cette courbe fera dans votre durée spécifique, puis complétez cette ligne avec les valeurs numériques :

node scripts/ease.mjs cubic 0.33 1 0.68 1     # easeOutCubic → voir le palier/dépassement
node scripts/ease.mjs stagger 6 2.4 0.7       # 6 lettres de titre en 2,4 s, chacune 0,7 s → pas et débordement

Ainsi, les deux lignes du tableau deviennent :

Élément	enter	active	exit	Propriété	Courbe (confirmé par l'outil)
#title span	0,15 + i*0,075	Jusqu'à la fin	—	translateY 96→0, opacity 0→1	cubic-bezier(0.33,1,0.68,1), dépassement 0%, palier après 0,75 → durée réduite à 0,7 s max
.dots i	1,50 + i*0,15	Jusqu'à la fin	—	scale 0→1	spring(120,14) dépassement 7,1%, stable à 0,67 s → segment de 0,75 s

Critère pour une bonne courbe (l'outil vous le dira) : dépassement ≤ 15 %, pas de palier au milieu, temps de stabilisation du ressort ≤ durée du segment. Si une condition n'est pas remplie, changez de paramètres et réexécutez, ne faites pas « on écrit comme ça et on verra au rendu ».

Modèle et autres paradigmes : references/spec-and-prompt.md

ÉTAPE 2 · Implémentation

Commencez par le squelette, n'écrivez pas toute la scène d'un coup. Le squelette = fond + un élément qui bouge + contrat seek valide.

window.scene = {
  duration: 3.0, fps: 30, width: 1920, height: 1080, ready: true,
  seek(t) {
    // Chaque élément : traduire mot pour mot « la ligne du tableau de la ligne de temps » en 3 lignes de code
    // k = courbe(seg(t, enter, enter + durée)) → utiliser k pour interpoler la propriété
  },
};

Le CSS et JS doivent être inline. Pas de CDN externe (le rendu échouerait comme si vous étiez hors ligne). Utilisez les polices système ("Segoe UI", "Microsoft YaHei", Arial).

Paradigmes disponibles (DOM/CSS/SVG/Canvas/GSAP/Web Animations, bibliothèque d'easing, montage multi-segments, texte lettre par lettre, traçage de chemin, défilement numérique, transitions par masque, CSS linear(), utilisation de filter/blend-mode/mask) : references/code-patterns.md

Quand vous devez dessiner quelque chose (effets lumineux, textures, formes, icônes, graphiques, illustrations, pseudo 3D), consultez d'abord references/asset-recipes.md. Il contient 20 catégories d'extraits sans dépendance, tous prêts à être collés dans un fichier HTML unique et pilotés par seek(t). Ne créez pas à partir de zéro à l'instinct, n'attendez pas d'assets.

ÉTAPE 3 · Vérification numérique (vérifiez d'abord les chiffres, ne vous précipitez pas sur le rendu)

Cette étape est la première vérification « multiple » : en quelques secondes, sans encodage, et peut même pointer du doigt les éléments.

# Voir la trajectoire réelle de chaque élément : qui bouge, jusqu'où, où ça coince
node scripts/verify.mjs --html scene.html --select "#bar b,#title span" --props transform,opacity --steps 31

# Vérifier que « l'image n'est déterminée que par t » (deux appels pour le même t doivent donner exactement le même résultat)
node scripts/verify.mjs --html scene.html --select ".item" --idempotent

Il vous donnera directement la réponse à ce genre de questions :

⚠ #b[0] · sx — pause au milieu 0–2 s puis continue → l'interpolation est interrompue ou manquante.
ℹ #card[0] · (tout) — cet élément n'a aucun changement sur tout le segment → le sélecteur n'a pas trouvé l'élément / le style n'est pas dans le DOM.
✖ seek non idempotent : 13 différences entre deux appels pour le même t → l'état cumulé est utilisé dans seek.

Passez à l'étape suivante seulement après avoir vérifié les valeurs. Ne faites pas le rendu complet si les valeurs sont problématiques — cela ne donnera qu'un vague « l'image n'a pas l'air de bouger », et vous devrez ensuite remonter la cause à partir des pixels. Laissez d'abord les chiffres parler.

ÉTAPE 4 · Rendu + Vérification par pixels

Sortez d'abord uniquement les images clés, c'est rapide et suffisant pour juger de la composition :

node scripts/render.mjs --html scene.html --still 0.2,1.0,2.2 --out out/stills

Regardez ces images (utilisez read_image pour les voir vous-même, ne les sautez pas). Si la composition est OK, faites le rendu complet :

node scripts/render.mjs --html scene.html --out out/v.mp4 --fps 30 --sheet
node scripts/audit.mjs --video out/v.mp4 --fps 30 --duration 3 --width 1920 --height 1080

audit vous donne : courbe des pixels changeants, barre de rythme, et conclusions par niveau. Modifiez en fonction de ces conclusions, une seule chose à la fois, puis réexécutez immédiatement audit. Maximum 5 itérations ; si la 5ᵉ échoue encore, revenez à l'ÉTAPE 1 pour modifier les spécifications (cela signifie que les spécifications elles-mêmes sont erronées).

Pour les erreurs courantes, voir : references/failure-modes.md

ÉTAPE 5 · Inspection visuelle humaine

La machine garantit seulement que « la structure est correcte ». Ces points doivent être vérifiés par vous :

Le texte déborde-t-il de l'image / est-il coupé / entre-t-il en conflit avec le fond.
Le centre visuel est-il à la position attendue (règle des tiers / centrage / centre de gravité du groupe d'éléments).
Le contraste est-il suffisant (texte gris à 40 % de transparence sur fond sombre = invisible).
Les entrées/sorties sont-elles propres (pas d'élément qui commence à bouger en dehors de l'image ou disparaît soudainement).

Liste de contrôle : references/review-checklist.md

ÉTAPE 6 · Livraison

# Ajoutez un rendu pour le format souhaité
node scripts/render.mjs --html scene.html --out out/v.webm --format webm
node scripts/render.mjs --html scene.html --out out/v.gif --format gif --fps 15

Livrez : le chemin du fichier final, la planche contact, les lignes de verdict de l'audit, storyboard.md. Si l'audit contient des WARN que vous jugez intentionnels, expliquez clairement de quelle ligne il s'agit et pourquoi.

La version finale doit être rendue à nouveau avec le flou de mouvement activé.

node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 30 --motion-blur 180

C'est la frontière entre « semble fluide » et « semble être une capture d'écran ». Pendant la phase d'itération, vous pouvez temporairement le désactiver pour gagner du temps, mais la version livrée ne doit pas être sans obturateur — économiser cela, c'est réduire la qualité. Après activation, réexécutez un audit pour confirmer que la durée et l'image par seconde n'ont pas été modifiées. En cas de mouvement rapide (actions du personnage, recadrages, particules), utilisez également --fps 60.

Aide-mémoire des commandes

# Diagnostic
node scripts/render.mjs --check

# Calculs (courbe / ressort / décalage / contraste) — interdit de calcul mental
node scripts/ease.mjs cubic 0.22 1 0.36 1
node scripts/ease.mjs spring 120 14 1 1.2
node scripts/ease.mjs css-linear --preset silkIn
node scripts/ease.mjs stagger 7 2.4 0.5
node scripts/ease.mjs contrast "#0b0e14" "#6d8bbd"
node scripts/ease.mjs ramp "#0b0e14" 5
node scripts/ease.mjs presets

# Diagnostic géométrique du squelette (obligatoire si personnage ; doit utiliser --ref pour aligner un squelette existant)
node scripts/rigcheck.mjs --rig rig/ander.rig.json
node scripts/rigcheck.mjs --rig lib/rig.json --ref rig/ander.rig.json
node scripts/rigcheck.mjs --rig rig.json --pose '{"head":{"rot":0.2}}' --assert

# Diagnostic du frontmatter SKILL.md (exécutez après chaque modification du skill, pour éviter « l'ensemble du skill ne peut pas être chargé »)
node scripts/lint-skill.mjs

# Vérification numérique (en secondes, peut pointer les éléments)
node scripts/verify.mjs --html scene.html --select "#bar b" --props transform,opacity --steps 31
node scripts/verify.mjs --html scene.html --select ".item" --idempotent
node scripts/verify.mjs --html scene.html --all --json

# Images clés (pour inspection, le plus rapide)
node scripts/render.mjs --html scene.html --still 0,0.5,1.5,2.9 --out out/stills

# Images clés + lignes de guidage de composition (grille 100px / zone de sécurité 80px / lignes de tiers / croix centrale)
node scripts/render.mjs --html scene.html --still 1.6 --guides --out out/guides

# Vidéo complète + planche contact
node scripts/render.mjs --html scene.html --out out/v.mp4 --fps 30 --sheet

# Version finale avec flou de mouvement (obturateur 180° = standard cinéma ; rendu ×4, utiliser seulement à la finalisation)
node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 30 --motion-blur 180

# Mouvement rapide (actions personnage, recadrages, particules) seulement -> 60 fps
node scripts/render.mjs --html scene.html --out out/final.mp4 --fps 60 --motion-blur 180

# Sur-échantillonnage 2× (plus net, 3–4× plus lent)
node scripts/render.mjs --html scene.html --out out/v.mp4 --scale 2

# Fond transparent : webp / apng / png fiable
node scripts/render.mjs --html scene.html --out out/v.webp --format webp --alpha
node scripts/render.mjs --html scene.html --out out/v.apng --format apng --alpha

# Alpha du webm dépend de la compilation de ffmpeg. Test local : VP8/VP9 perdent souvent l'alpha.
# Le script vérifie la première image après encodage — s'il n'y a pas de pixels transparents, il génère une erreur et indique quel format utiliser.
node scripts/render.mjs --html scene.html --out out/v.webm --format webm --alpha

# GIF bouclé
node scripts/render.mjs --html scene.html --out out/v.gif --format gif --fps 15

# Vérification par pixels
node scripts/audit.mjs --video out/v.mp4 --fps 30 --duration 3 --width 1920 --height 1080
node scripts/audit.mjs --video out/v.gif --loop           # Vérification de la jointure de boucle
node scripts/audit.mjs --video out/v.mp4 --json out/audit.json

Paramètres de render.mjs : --html --out --fps --duration --width --height --scale --format(mp4|webm|gif|webp|apng|png) --still --sheet --alpha --file --keep-frames --chrome --check --quiet Paramètres de verify.mjs : --html --select --props --steps --idempotent --all --json Paramètres de audit.mjs : --video --fps --duration --width --height --loop --json --verbose Paramètres de ease.mjs : cubic|spring|css-linear|stagger|contrast|ramp|presets avec leurs propres arguments. Paramètres de rigcheck.mjs : --rig --ref --pose --assert Paramètres de lint-skill.mjs : (aucun paramètre requis, il analyse SKILL.md dans le répertoire courant).

IFIAnder/motion-video-skill

Qu'est-ce que motion-video-skill ?

Demander à votre IA préférée

Documentation