8533502-dev/deepseek-opus-motion-skill

Films de motion design avec parité Opus (Remotion)

Objectif : une même requête, donnée à Opus 5.5 et au modèle exécutant cette compétence, produit des films qui se ressemblent visuellement, dans le mouvement et le son, quel que soit le sujet ou le style.

L'écart n'est que rarement une question de goût. C'est une question de comportement. Opus :

• honore chaque valeur d'une longue requête ;
• transforme les mots vagues en décisions de conception concrètes ;
• conçoit chaque élément correctement au lieu de se contenter d'un placeholder ;
• planifie toute la timeline avant de coder ;
• construit un système partagé, assurant la cohérence ;
• examine sa propre production et la corrige.

Un modèle plus faible ignore ces étapes à moins qu'elles ne soient rendues explicites. Cette compétence les rend explicites, sur l'architecture Open Design :

Élément Open Design	Ici
Une compétence fonctionnelle qui possède le workflow	Ce fichier : priorités, étapes et playbooks des éléments
Un contrat DESIGN.md lu par chaque rendu	Le contrat de conception en haut de src/spec.ts ; design-systems/*.md en sont les graines
Templates	templates/remotion-starter/, testés (source complète dans REFERENCE.md)
Un portail de critique Design Jury	Étape 6 : cinq jurés, corriger jusqu'à ce que chaque note ≥ 8
Une liste de contrôle anti-slops	La liste d'interdits à l'étape 6
Rendu déterministe	Remotion : chaque image est une fonction pure du numéro d'image

Ordre de priorité

Lorsque les règles sont en concurrence, respectez cet ordre :

1. Les propres mots de la requête : chaque valeur, battement, ligne de copie et interdiction.
2. L'apparence et le savoir-faire au niveau du style : composition, palette, typographie, et chaque élément conçu correctement (voir les playbooks). La texture et la lumière entrent aussi ici. C'est ce qu'un spectateur juge en premier.
3. La continuité : transformations réelles, identité persistante, physique plausible.
4. Le rythme et le son.
5. La comptabilité : registres, tableaux et vérifications. Ils servent les points 1 à 4 et ne les remplacent jamais.

Les aides et exemples sont des mécanismes, pas un style. motion.tsx décide où sont les choses et comment elles bougent. Il ne décide jamais de leur apparence. Ne livrez jamais un défaut neutre d'une aide, comme une boîte simple ou des membres en bâton, en tant que conception. Ne copiez jamais le sujet, la palette ou la mise en page d'un exemple dans un film différent. Chaque film a sa propre apparence conçue, au moins aussi riche qu'elle le serait sans les aides.

Invocation

• Toute demande de pièce animée exécute le pipeline. Ne posez pas de questions : résolvez les lacunes à l'étape 1 et indiquez-les dans 解读.
• Chaque nouvelle requête est un nouveau film, construit à partir du starter, même dans une conversation qui en a déjà produit un. Ne réutilisez le code précédent que si l'utilisateur demande de le modifier (修改, 改一下, 在上一版基础上, fix this). Dans un hôte avec outils de fichiers, créez un nouveau dossier de projet pour le film.
• Modes. Le mode par défaut est de construire. 只要提示词 / 扩写 / “prompt only” s'arrête après l'étape 2 et produit le brief développé sous forme d'un bloc text délimité.
• Hôtes. Chat uniquement : sortie des fichiers sous forme de blocs de code (étape 7). Avec outils de fichiers et shell : écrivez les fichiers, exécutez npx tsc -p ., npm run render et npm run check, examinez les images fixes, corrigez, puis rapportez.
• Si le message ne contient aucune idée, répondez seulement : “请给我一句话的创意或一段完整的提示词。”

Étape 0 — Lire la requête comme Opus : trois registres

• Registre des spécifications S01… : une ligne par valeur ou instruction, citée exactement. Cela couvre les durées, tailles, couleurs, polices, poids, copies, quantités, angles, positions, timings, easing, interdictions, la boucle ou la fin, les personnages, et chaque battement du storyboard. FILM dans spec.ts (durée, fps, taille) provient de ces lignes ; les valeurs de placeholder du starter ne doivent jamais survivre. Une requête tronquée est complétée dans la voix et la densité de sa dernière section complète, avec ces lignes marquées S##*.

• Registre des transformations X01… : chaque verbe de devenir (devient, se transforme en, rassemble, se dissout, se déplie, grandit, 变成, 化成, 收拢, 汇聚, 展开) sous forme source → cible · mécanisme · début–fin s · ce qui est conservé.

• Registre des éléments E01… : chaque chose qui est dessinée, tapée avec son playbook (type, objet, personnage, environnement, données, UI, transition, texture-lumière, son) et listant :

  • trois caractéristiques structurelles ou plus ;
  • taille et coordonnées ;
  • comment il se déplace ;
  • pour les personnages, la fiche de conception et les poses nommées ;
  • pour les objets tenus, le porteur dans le temps.

  Chaque scène reçoit également sa liste de calques de l'arrière vers l'avant.

Chaque valeur est contraignante : n'arrondissez, ne renommez, ne recolorez, ne retimez ou ne supprimez jamais une valeur. Le dernier tiers d'une longue requête compte autant que le premier. Si deux lignes sont en conflit, conservez la plus spécifique et notez-le dans 解读. Dans le code :

• les constantes vivent dans spec.ts, étiquetées // S07 ;
• les constructeurs vivent dans film.tsx, étiquetés // E03 ;
• les battements vivent dans les fichiers de scène, étiquetés // S31 X02.

Étape 1 — Combler les lacunes comme le fait Opus

Uniquement pour ce que la requête laisse ouvert ; ne remplacez jamais une ligne du registre.

Lacune	Valeur par défaut façon Opus
Format	1920 × 1080 ; 60 ips pour un mouvement dense, 30 ips pour des pièces calmes ou avec personnages. Un format indiqué est contraignant ; pour un aperçu rapide, utilisez npm run preview, ne baissez jamais FILM
Durée et fin	15 s pour une idée, 30 s pour une showreel ou un film de marque. Une boucle parfaite pour les réels et les identifiants ; une image finale résolue ou une carte de fin pour les histoires et les promos
Rythme	Tempo basé sur l'ambiance : calme 60–90 BPM, marque 110–128, énergique 128–140. Les pièces denses ont un événement à chaque temps, les pièces calmes à chaque mesure. Les pauses ≤ 0.5 s quand c'est dense, aussi longues que nécessaire quand c'est calme
Récit	Un motif ou un porteur relie le film ; chaque scène découle de la précédente ; pas de cartes de titre non liées
Caméra	Fixe et de face sauf si la requête implique un mouvement. Les pièces narratives s'ouvrent largement sur tout le monde
Composition	Basée sur l'occupation du style et les espaces blancs. Rien au repos à moins de 150 px des bords ou 90 px du haut et du bas
Typographie	Une famille avec du caractère ; le mot ou chiffre clé dans le poids le plus lourd à la taille la plus grande. Latin : Inter, Geist, Space Grotesk, Fraunces ; Chinois : Noto Sans SC, Noto Serif SC
Palette	3–5 couleurs avec des rôles ; l'accent préfigure ce qui vient ensuite
Texture et lumière	Matériau par élément, adapté à sa taille. La lumière provient de sources motivées
Détail	Trois micro-détails récurrents qui donnent au film un aspect travaillé (étiquettes, graduations, légendes, timecodes, signalétique). Ils n'ajoutent aucune nouvelle information, nombre ou copie au-delà de la requête, et utilisent le libellé de la requête là où il en donne un
Sous-titres	Toutes les lignes de dialogue, paroles ou sous-titres à l'écran : ≥ 40 px en 1080p, contraste élevé, tiers inférieur, ligne entière maintenue pendant sa fenêtre de lecture (≈ 0.25 s par caractère chinois, ≈ 3 mots latins par seconde)
Son	Une musique générée qui correspond à l'ambiance, ou une ambiance pour une scène centrée sur l'environnement ; silencieux seulement si demandé

Étape 2 — Direction : dériver un contrat de conception à partir de la requête

D'où vient le style :

1. La requête indique le style (palette, matériaux, type, références). Le contrat vient uniquement du registre.
2. La requête nomme un sentiment, un médium ou une référence (“comme un journal”, “水墨”, “terminal”, “affiche suisse”, “façon Pixar”). Partez de la graine la plus proche dans design-systems/ et adaptez-la.
3. La requête est une idée brute. Synthétisez un nouveau contrat avec la méthode ci-dessous. Les graines sont des points de départ optionnels, pas des valeurs par défaut.

Méthode de synthèse de style (pour tout sujet) :

1. Sujet → monde. Dans quel monde matériel ce sujet vit-il ? Papier, encre, verre, métal, tissu, écrans, nature, une ville, un labo. Choisissez-en un, plus au maximum un monde contrasté pour y transformer.
2. Audience et humeur → énergie. Calme ou percutant, chaleureux ou précis, ludique ou sérieux. Cela définit le tempo, l'easing, le dépassement et la densité.
3. Rendez-le concret. Écrivez le contrat sous forme de valeurs, pas d'adjectifs :
   • Palette : valeurs hexadécimales avec rôles.
   • Type : famille, poids, tailles, crénage.
   • Marques : comment les lignes, les remplissages et les formes sont dessinés, en tant que techniques SVG.
   • Texture et lumière : par élément.
   • Composition : occupation, espaces blancs, règle des bords.
   • Caractère du mouvement : easing par type de mouvement.
   • Grammaire des transitions : quel mécanisme change quelle scène.
   • Détails signatures.
   • Palette sonore.
   • Interdictions.
4. Vérifiez contre le slop. Chaque choix doit être attribuable au sujet ou à la requête. Les dégradés génériques, lueurs et mises en page de template sont ce que le contrat existe pour remplacer.

Graines dans design-systems/ :

Graine	Convient à
drafting-table	Processus, outils, ingénierie
swiss-kinetic	Marques, lancements, déclarations
editorial-ink	Culture, artisanat, patrimoine, thèmes est-asiatiques
data-instrument	Explicateurs, finance, science
bold-poster	Musique, sport, jeunesse
riso-halftone	Indé, rétro, ludique
storybook-scene	Personnages, histoires, clips vidéo

Requêtes courtes : rédigez d'abord le brief complet, à la densité d'Opus. Il comporte un paragraphe de direction, le contrat, la structure (tempo, scènes nommées, changements de scène), les personnages s'il y en a, et un storyboard scène par scène avec horodatages et numéros. Ce brief devient les registres. En mode uniquement requête, produisez-le et arrêtez-vous.

Étape 3 — Timeline avant le code

1. Écrivez une ligne par scène : début–fin s · nom · ce que le spectateur apprend · élément porté entrée → sortie · transition sortie (X##).
2. Listez chaque événement comme t: élément (E##) · action · nombres · ids.
3. Nommez les instants clés dans un bloc T.
4. Dérivez la liste des indices sonores à partir des mêmes événements.

Vérifications avant de continuer :

• les battements tombent aux multiples de 60/BPM ;
• l'état de sortie de chaque scène est l'état d'entrée de la scène suivante ;
• aucune action ne pilote une propriété en même temps ;
• tout se termine avant la fin ;
• pour une boucle, l'image virtuelle t = D est égale à l'image 0, avec tout mouvement au repos.

Étape 4 — Conception avant le mouvement

1. Construisez la géométrie de chaque élément à partir de ses caractéristiques structurelles, au niveau du module.
2. Pour les personnages, faites d'abord une fiche personnage : une image fixe avec chaque personnage dans chaque pose nommée, tenant ses accessoires.
3. Corrigez les compositions clés en tant que mises en page exactes en px : image 0, la première image complète de chaque scène ou matériau, et l'image finale. Vérifiez chacune par rapport à l'occupation du contrat et aux espaces blancs.
4. Codez ces états statiques avant le mouvement entre eux. Une image faible n'est jamais sauvée par le mouvement. Dans un hôte avec outils de fichiers, faites un rendu et examinez-les d'abord.

Playbooks des éléments

Toute requête est composée de ces types d'éléments. Pour chaque élément, appliquez son playbook.

Élément	Construisez-le	Déplacez-le	Vérifiez (défaillance courante)
Type	Une famille ; hiérarchie par poids et taille ; crénage défini par taille ; grands mots sur une ligne, ajustés à leur largeur indiquée ; les mots et lettres séparés conservent leurs espaces ; le CJK peut s'écrire verticalement	Arriver avec EASE.out ; décalages 0.02–0.06 s ; clips de slot, glissières sur rails, révélations par échelle ; pause lisible avant la sortie	Mots collés, lignes orphelines, sous-titres trop petits ou faible contraste, le mot clé pas le type le plus lourd
Objet (icônes, accessoires, produits, symboles)	Trois caractéristiques structurelles ou plus de l'objet réel ; un côté ombré pour le volume ; politique de contour cohérente ; construit une fois comme une fonction	Mouvement issu de sa nature : le papier se plie à un pli, le liquide ondule, le métal tourne sur un axe, la lumière s'allume	Un symbole au lieu de l'objet, pièces flottantes, échelle incohérente entre les plans
Personnage	Une fiche Body : silhouette, proportions, couleurs, visage, marques, tout conçu via color, face et parts ; poses nommées	poseMix entre poses nommées avec settle ; walk() pour marcher ; petits battements d'acteur lisibles ; accessoires à grip() et dessinés dans held	Un regard flottant entre les plans, mains pas sur les accessoires tenus, membres à travers la tête, apparence par défaut en bâton, pieds décollés du sol
Environnement (pièces, villes, paysages, météo)	Couches de l'arrière vers l'avant : ciel ou mur, lointain, moyen, sol, avant-plan. Sources lumineuses motivées et leurs formes de lumière. Météo sur tout le cadre en deux profondeurs	Vie ambiante qui ne s'arrête jamais (météo, lumières, petites boucles) ; la caméra reste immobile sauf si demandé	Un fond plat, météo traversant des objets solides, logique de lumière manquante, encombrement bord à bord
Données (graphiques, compteurs, diagrammes, cartes)	Axes et unités d'abord, valeurs exactes du registre, étiquettes attachées aux marques, un graphique par scène	Axes, puis données, puis annotation ; les compteurs défilent avec leur marque ; les graphiques se transforment les uns dans les autres via des slots partagés	Mauvais nombres, axes non étiquetés, décoration sur les données, étiquettes qui ignorent le libellé de la requête
UI / produit	Vrais écrans ou reconstructions fidèles avec rectangles nets, proportions réelles et hiérarchie réelle	Changements pilotés par curseur ou par état ; zoom sur la région qui change	Captures d'écran étirées, bruit d'interface factice, petit texte illisible
Transition	Mécanismes physiques : morphing (chain), fusion (converge), masque ou balayage (Reveal), changement de matériau (MaterialLayer deux fois sous Reveal), dépliage, correspondance sur une forme partagée	Bords nets, planifiés sur un temps, avec la source qui disparaît quand la cible se forme	Fondus enchaînés, coupures que la requête n'a pas demandées, éléments qui apparaissent, identité perdue lors d'un changement de matériau
Texture et lumière	Papier et encre comme couches séparées (Paper, InkFilter mis à l'échelle avec roughFor) ; demi-teintes et hachures via motifs ; lumière comme formes (cônes, fenêtres éclairées, reflets)	Semée et stable, ou bouillonnante à un taux d'étapes fixe	Texture uniforme sur tout, lueur ou bloom décoratif, scintillement dû à un bruit non semé
Son	scripts/cues.json : un tapis mélodique et une figure pour la musique, ou un tapis ambience pour les scènes centrées sur l'environnement ; un événement sur chaque impact visuel	Synchronisé au bloc T ; la queue d'une boucle se replie dans son début	Silence par omission, bruit utilisé comme musique, impacts hors synchronisation

Règles universelles

1. Le devenir est réel. Chaque ligne X transforme le même objet point par point (nombre égal de points ; chain() pour plusieurs formes, converge() pour plusieurs-à-un). La source a disparu quand la cible se forme. La cible est entièrement atteinte : si la requête dit “devient un diagramme à barres”, cela se termine par des barres. Les parties naissent à leur source et voyagent. Les fusions et scissions conservent la quantité. Ne simulez jamais une transformation avec une superposition, un fondu enchaîné, ou une boîte de texte animée. Ne sautez jamais une scène intermédiaire.

2. Le temps n'est pas compressible. 1 s vaut 1 s, sauf si la requête dit le contraire. Ne comprimez pas lestransformations ou les transitions dans un battement.

3. Le son est une couche. Le son doit être généré et synchronisé, pas ajouté à la dernière minute. Les pistes musicales doivent être mélodiques et changer avec la scène. L'ambiance doit correspondre à l'environnement. Le silence est actif, pas un oubli.

4. Une critique est un test. L'auto-évaluation (étape 6) est exacte. Les jurés doivent être des experts : un chef de projet créatif, un directeur artistique, un animateur, un designer sonore et un rédacteur. Chaque juré évalue sur 10. Si un juré marque < 8, le film doit être corrigé. Les corrections ciblent les problèmes spécifiques. Le film n'est final que lorsque tous les jurés marquent ≥ 8.

5. Le code est le dernier mot. Une fois que le code tourne et que le rendu est bon, c'est fini. Les émotions et les opinions personnelles ne comptent pas. Seules la requête, le contrat, et les marques des jurés comptent.

6. La simplicité est une vertu. Ne compliquez pas le code. Utilisez les aides et les patterns. Ne réinventez pas la roue. Mais ne simplifiez pas la conception.

Étape 5 — Construire le projet

1. Copiez le starter depuis templates/remotion-starter/.
2. Éditez src/spec.ts : mettez à jour FILM (durée, fps, taille) depuis le registre des spécifications.
3. Éditez src/film.tsx : construisez chaque élément depuis son registre, en tant que fonction.
4. Éditez src/scenes/ : créez un fichier par scène, avec les positions, mouvements et transitions exacts.
5. Éditez scripts/cues.json : générez la liste des indices sonores.
6. Exécutez npm run render pour le rendu final.
7. Exécutez npm run check pour la validation.

Étape 6 — Design Jury : auto-évaluation

1. Lisez l'image finale. Si le prompt demandait une boucle, lisez l'image virtuelle t = D.
2. Si vous avez un outil de rendu, regardez les images clés.
3. Cinq jurés :
   • Directeur de création : la demande est-elle satisfaite ? Le contrat de conception est-il respecté ?
   • Directeur artistique : la palette, la typographie, la composition et la texture sont-elles au niveau ?
   • Animateur : le mouvement est-il fluide, précis et cohérent ? Les transformations sont-elles réelles ?
   • Designer sonore : le son correspond-il à l'ambiance ? Les indices sonores sont-ils synchronisés ?
   • Rédacteur : le texte est-il lisible, bien rythmé et conforme à la requête ?
4. Chaque juré marque sur 10. Si un juré marque < 8, listez 1 à 3 problèmes spécifiques.
5. Corrigez chaque problème : retournez à l'étape 4 ou 5 selon le problème. Refaites le rendu et la validation.
6. Répétez jusqu'à ce que tous les jurés marquent ≥ 8.

Liste d'interdits (anti-slops) :

• Aucun dégradé générique (linéaire ou radial sans motif) ;
• Aucune lueur ou ombre portée décorative ;
• Aucune boîte de texte animée servant de transition ;
• Aucun fondu enchaîné sauf si la requête le demande ;
• Aucune image clé avec des valeurs d'easing égales (easing linéaire par défaut) ;
• Aucun élément flottant ou sans ancrage ;
• Aucune police par défaut (Arial, Times, Courier) ;
• Aucun bruit blanc ou silence non motivé.

Étape 7 — Sortie

• Chat uniquement : sortez chaque fichier sous forme de bloc de code délimité, avec le chemin comme titre (ex. src/film.tsx).
• Avec outils de fichiers : écrivez les fichiers dans le dossier du projet. Exécutez npx tsc -p . pour vérifier les erreurs de type. Exécutez npm run render pour le rendu final. Exécutez npm run check pour la validation.
• Rapportez le résultat : "Film créé dans [dossier]. Rendu réussi. Tous les jurés ont marqué ≥ 8."

Références

• REFERENCE.md : source complète du starter, y compris les aides et les playbooks.
• DESIGN.md : contrat de conception pour ce film.
• design-systems/*.md : graines de style.
• src/spec.ts : constantes du film.
• src/film.tsx : constructeur principal.
• src/scenes/ : fichiers de scène.
• scripts/cues.json : génération sonore.

Licence

Cette compétence est open source. Utilisez-la, modifiez-la, partagez-la.