Communitygithub.com

motion-choreographer

Transforme un visuel figé + un plan de scène structuré en prompt de mouvement adapté aux fournisseurs vidéo (Veo, Kling, Sora, etc.). Chorégraphie caméra, mouvement primaire/secondaire, physique et synchronisation audio native.

Qu'est-ce que motion-choreographer ?

Le skill `motion-choreographer` agit comme un traducteur spécialisé pour l'étape de mouvement vidéo dans un pipeline de génération d'IA. Il prend un visuel (image sélectionnée) et un plan de scène (blueprint) déjà structuré et produit un prompt de mouvement optimisé pour un fournisseur vidéo spécifique comme Veo, Kling ou Sora. Il orchestre la caméra, les mouvements du sujet et de l'environnement, les contraintes physiques et, si le fournisseur et le blueprint le permettent, une piste audio synchronisée. Le skill ne fait aucun appel réseau et se base sur un contrat d'adaptateur (adapter-contract.md) pour connaître les capacités de chaque fournisseur. Il produit trois fichiers de sortie : un JSON pour l'adaptateur, un fichier texte pour la relecture humaine, et des notes pour l'opérateur.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/event4u-app/agent-config/tree/HEAD/dist/agent-src/skills/motion-choreographer

Demander à votre IA préférée

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

Documentation

Que fait motion-choreographer ?

Transformer un visuel approuvé + le plan de scène en 12 blocs en un prompt de mouvement adapté au fournisseur cible que l'adaptateur vidéo consomme. Chorégraphie de la caméra, mouvement principal du sujet, mouvement secondaire de l'environnement, contraintes physiques et — lorsque l'adaptateur déclare audio: native — un bloc de direction audio synchronisée. Lit les capacités de l'adaptateur depuis adapter-contract.md ; ne communique jamais avec une API réseau.

Quand l'utiliser

  • Une image est verrouillée (l'opérateur a choisi un candidat via operator-pick.sh) et l'étape suivante est la direction mouvement + audio pour l'adaptateur vidéo.
  • Le plan de scène existe dans scenes/<id>/blueprint.json mais le prompt de mouvement n'a pas encore été émis.
  • Un changement de fournisseur (Veo → Kling, Sora → Higgsfield) nécessite le retournement de la même scène pour le profil de capacité du nouvel adaptateur.

Ne PAS utiliser quand :

  • Le plan de scène est encore uniquement en prose — exécutez d'abord scene-expander → parse-blueprint.sh.
  • Aucun visuel n'est verrouillé — le point de contrôle de sélection de l'opérateur doit d'abord être terminé.
  • Le résultat est un graphique fixe — canvas-design.

Procédure

Étape 0 : Inspection

  1. Lire scenes/<id>/blueprint.json — échouer bruyamment si absent.
  2. Lire scenes/<id>/selection.json — échouer bruyamment si absent ; le chemin de l'image verrouillée est requis comme ancrage du mouvement.
  3. Lire la capacité de l'adaptateur cible via scripts/ai-video/adapters/<id>.sh capability. Mettre en cache audio=* pour l'étape 3.
  4. Si un verrou character.json existe, le charger textuellement — les jetons d'identité sont immuables.
  5. Prise continue ou connecteur demandé ? Lire d'abord les start_frame / end_frame du modèle — scripts/ai-video/adapters/<id>.sh capability --model <m>. null est inconnu, jamais true. Un modèle qui ne peut pas verrouiller l'image est refusé avec une phrase expliquant pourquoi, jamais substitué (adapter-contract.md#end_image).

Étape 1 : Chorégraphie de la caméra

Émettre un bloc MOUVEMENT DE CAMÉRA avec le type de mouvement, la distance, la vitesse en secondes, et le cadrage début-fin.

  • Types de mouvement : arrêt sur image, panoramique, inclinaison, zoom avant, zoom arrière, travelling latéral, pied élévateur, poussée, traction, caméra à main, glissade stabilisateur, grue, coup de fouet.
  • Vitesse en secondes par temps (0,4s poussée, tenir 1,6s, 0,4s traction).
  • Cadrage début et fin nommé (PM → GP, PL → PM).

Décodage de la classe d'intention du plan de scène — le bloc CAMÉRA du plan de scène nomme l'une des six classes d'intention indépendantes du fournisseur ; la mapper aux types de mouvement ci-dessus avant l'encodage :

Classe d'intentionCorrespondance des types de mouvement
maintien statiquearrêt sur image
poussée vers l'avantpoussée / zoom avant
recultraction / zoom arrière
suivi latéraltravelling / panoramique
dérive caméra à maincaméra à main / glissade stabilisateur
orbitegrue / arc via travelling+panoramique

Particularités de l'adaptateur (encodage par fournisseur du mouvement mappé). Ceux-ci ne sont pas datés et non vérifiés par rapport à la documentation du fournisseur — vérifiez l'entrée des capacités du modèle (verified, recheck_by) avant de s'y fier :

  • Veo — accepte les mouvements nommés ; préfère les clips ≤ 8s.
  • Kling — jeton d'intensité de mouvement 0–1 ; mapper notre vitesse sur cela.
  • Sora — mouvement en langage naturel + durée ; pas de jeton.
  • Higgsfield — basé sur des préréglages ; choisir le préréglage qui correspond au mouvement ; enregistrer l'identifiant du préréglage dans le prompt de mouvement.
  • Gestion LENTILLE — la distance focale mm + ouverture du plan de scène se traduisent par l'idiome de lentille / champ de vision le plus proche du fournisseur ; ne jamais transmettre la distance focale brute à un fournisseur qui n'a pas de grammaire de lentille.
  • Gestion DURÉE — la valeur du plan de scène est libre ; la limiter au plafond du fournisseur ici et enregistrer le plafonnement dans review.md (un plafonnement silencieux est un bug de dérive).

Étape 2 : Mouvement primaire + secondaire

Deux blocs :

  1. MOUVEMENT PRIMAIRE — ce que fait le sujet, compté en temps, avec des ancres physiques (masse, points de contact, momentum). Réutiliser ACTION du plan de scène ; l'affiner pour la densité de verbes préférée de l'adaptateur.
  2. MOUVEMENT SECONDAIRE — ce que fait le monde environnant (cheveux, tissus, feuillage, eau, poussière, particules, souffle). Une couche par ligne.
  3. SEGMENTS TEMPORELS (optionnel, lorsque le clip a plus d'un temps) — 0–3 s : …, 3–7 s : …, couvrant toute la durée sans lacunes ; chaque segment nomme ce qui change, jamais une ambiance.

Étape 3 : Direction audio (conditionnelle)

Si la capacité de l'adaptateur est audio: native ET que audio.enable_native_audio du plan de scène est true :

Émettre un bloc DIRECTION AUDIO avec :

  • TIMING DES DIALOGUES — intervenant @ 0,4s : "réplique" par entrée de dialogue. Le prompt lui-même est en anglais ; chaque ligne parlée reste textuellement dans sa propre langue et son écriture, étiquetée ([de] "…"). Ne jamais traduire une ligne écrite par l'utilisateur.
  • COUCHES AMBIANTES — copier depuis le plan de scène ; une couche par ligne.
  • REPÈRES DE SYNCHRONISATION — quel temps d'action correspond à quel repère audio (pas @ 1,2s, porte fermée @ 2,1s).

Si la capacité de l'adaptateur est audio: none :

  • Émettre un commentaire # AUDIO : secours ffmpeg-mux avec les chemins audio du plan de scène mis en file d'attente pour le multiplexage au moment de l'assemblage.
  • Définir enable_native_audio: false dans le JSON du prompt de mouvement.
  • Le plan de scène contient DIALOGUE → le secours mux ne peut pas prononcer les lignes de texte. Émettre un bloc d'avertissement RÉTROGRADATION AUDIO obligatoire dans motion-prompt.txt ET adapter-notes.md listant chaque ligne de dialogue qui ne sera pas rendue. La décision de savoir si cela est acceptable appartient à la porte d'orchestration (adapter-contract § Propriété audio) — cette compétence traduit, elle ne valide jamais, et elle NE supprime JAMAIS silencieusement le dialogue.

Étape 4 : Contraintes physiques

Émettre PHYSIQUE — une courte liste de ce que le modèle doit respecter : direction de la gravité, friction de contact, comportement des fluides, inertie des cheveux / tissus, parallaxe de lentille. Une seule contrainte par ligne.

Puis VERROUS NÉGATIFS — ce qui ne doit pas arriver, une ligne chacun : dérive d'identité, texte lisible que le plan de scène n'a pas demandé, membres ou doigts supplémentaires, un plan que la liste des plans ne contient pas, un logo qui n'est pas celui de l'utilisateur. Uniquement les verrous que le plan de scène justifie.

Étape 5 : Émettre le JSON du prompt de mouvement

Écrire scenes/<id>/motion-prompt.json avec la forme d'entrée standard du contrat d'adaptateur. L'orchestrateur envoie cela dans la sous-commande submit de l'adaptateur vidéo.

Étape 6 : Valider

  1. Le JSON s'analyse (jq .).
  2. requires.audio_native est cohérent avec la capacité de l'adaptateur choisi.
  3. La durée dans le prompt de mouvement correspond à la durée du plan de scène ±0.
  4. Les jetons d'identité (si character.json existe) sont textuels.

Format de sortie

  1. scenes/<id>/motion-prompt.json — entrée standard du contrat d'adaptateur.
  2. scenes/<id>/motion-prompt.txt — blocs de prose étiquetés (MOUVEMENT DE CAMÉRA · MOUVEMENT PRIMAIRE · MOUVEMENT SECONDAIRE · DIRECTION AUDIO · PHYSIQUE) pour la relecture par l'opérateur.
  3. scenes/<id>/adapter-notes.md — quel adaptateur, quelle capacité, quel préréglage / modèle, avec justification.

Piège

  • Le modèle veut "améliorer" le bloc SUJET du plan de scène — les jetons d'identité sont immuables ; refusez la tentation.
  • Choisir audio: native sur un adaptateur qui retourne audio: none produit une vidéo silencieuse — lisez toujours la capacité en premier, ne devinez jamais à partir du nom de l'adaptateur.
  • L'identifiant du préréglage Higgsfield doit être enregistré ; sinon, la réexécution dérive vers le préréglage que le modèle choisit à l'appel suivant.
  • Les durées Sora > 8s se dégradent souvent — plafonner à la limite de la table de l'adaptateur ; signaler le plafonnement à l'opérateur.

Ne PAS faire

  • Ne PAS émettre de prompts de mouvement pour un adaptateur dont vous n'avez pas interrogé la capacité lors de ce tour.
  • Ne PAS sauter la vérification de l'image verrouillée — la direction de mouvement sans image ancrée diverge à chaque appel.
  • Ne PAS paraphraser les jetons d'identité de character.json.
  • Ne PAS appeler d'API réseau — cette compétence n'est que de la prose d'optimisation pour fournisseur.

Politiques

Chemins, modèle d'application, et l'ensemble complet : le préambule de la politique média.

Les prompts de mouvement héritent de chaque contrainte que le plan de scène amont porte. Avant d'émettre de la prose optimisée pour le fournisseur :

  • divulgation — chaque clip distribué porte la divulgation non amovible de génération IA ; refusez les drapeaux d'adaptateur qui la supprimeraient.
  • transparence — la provenance du fournisseur (C2PA / SynthID) est préservée ; refusez les drapeaux de ré-encodage dont l'effet est de supprimer la provenance.
  • clonage vocal — lorsque le prompt de mouvement demande une narration audio: native dans une voix nommée.
  • usurpation de marque — lorsque le prompt de mouvement copie un générique / mascotte / transition signature d'une marque reconnue.

Refuser-et-signaler ; le prompt de mouvement ne peut pas blanchir un écart de politique que les compétences amont auraient dû attraper.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Skills associés