motion-graphics

Installation du plugin : Avant les commandes de configuration ou de mise à jour, suivez les règles d'exécution du plugin lorsque ce skill se trouve à l'intérieur d'un plugin HyperFrames. Les installations autonomes conservent les instructions de mise à jour ci-dessous.

Avant tout, maintenez ce skill à jour — confirmez avec l'utilisateur avant d'exécuter : npx hyperframes skills update motion-graphics. Une opération rapide et sans effet si tout est à jour ; sinon, il rafraîchit ce skill ainsi que les compétences de domaine principales dont il dépend avant que vous ne les utilisiez.

source figma : Si le logo/asset/animation à construire provient d'une URL figma.com, exécutez d'abord /figma — exportation des actifs, jetons de marque, et traduction Motion→GSAP si le graphique est une importation Figma Motion — puis construisez à partir de sa sortie. N'utilisez pas directement les outils MCP bruts pour piloter Figma : cela contournerait le nettoyage SVG, la provenance .media/manifest.jsonl et la liaison var() des jetons de marque, de sorte qu'un changement ultérieur de marque ne pourrait pas se propager sans une réimportation complète.

motion-graphics — point d'entrée

La porte d'entrée est /hyperframes. Ce skill crée une animation graphique courte, conçue visuellement et sans narration (le mouvement est le message ; ~moins de 10 secondes, pas de voix off). Pour tout ce qui est plus long, narré ou multi-scène — ou en cas d'incertitude → lisez /hyperframes en premier : la couche d'intention décide de chaque orientation.

Ce workflow est autonome par conception — au maximum une question de clarification (agents/director.md), puis construction jusqu'à la vérification sans révision intermédiaire. La couche d'intention (/hyperframes → references/intent-interview.md) route directement ici sans questions sur la forme de l'exécution ; un storyboard et une session d'accompagnement apportent peu à un morceau aussi court. Le rendu reste contrôlé par l'utilisateur : après la réussite des vérifications et des captures de preuve, posez la question canonique « prévisualiser d'abord, ou rendre ? » de ../hyperframes/references/brief-contract.md. Lorsqu'un BRIEF.md existe, lisez-le avant la question du réalisateur.

Une animation graphique courte et conçue visuellement. Asset-first : décidez de la stratégie d'actifs et sources réelles du matériel avant de concevoir le plan, puis concevez le plan autour de ce que vous avez, puis composez en réutilisant les capacités du catalogue. Tous les artefacts vont dans PROJECT_DIR = videos/<nom-du-projet>/ (créé à l'étape 0) ; tous les chemins ci-dessous sont relatifs à ce répertoire.

Phase	Exécution	Artefact principal	Flux détaillé
init	Bash	hyperframes.json	Étape 0
plan	sous-agent — décider de la recherche ? + classer + stratégie d'actifs	shot-plan.json (brouillon : catégorie, requêtes asset_needs, brief)	agents/director.md (Partie 1)
source ◇	Bash — résolution des médias (ignorer si asset_needs est vide)	assets/ + assets/index.md	phases/source/guide.md
design	sous-agent — conception du plan autour des actifs résolus	shot-plan.json (final : bloc(s) + disposition + mouvement + positions)	agents/director.md (Partie 2)
build	sous-agent — composition axée sur la réutilisation	compositions/index.html	agents/builder.md
verify	Bash — lint, check, captures de preuve ; réparation en cas d'échec	snapshots/contact-sheet.jpg	Étape 5
approve	Demander la prévisualisation ou le rendu ; attendre la réponse	Approbation explicite du rendu	Étape 6
render	Bash — hyperframes render (MP4, ou --format webm/mov pour superposition)	renders/video.mp4 ou superposition transparente	Étape 6

◇ source s'exécute uniquement lorsque la catégorie choisie déclare des actifs. Les catégories purement code/texte (par ex. kinetic-type, la plupart des charts/stat) ont asset_needs: [] et passent directement du plan à la conception.

Catégories — divisées par la décision de recherche

La première décision du plan est : cela nécessite-t-il une recherche ? Cette bifurcation divise les catégories en deux groupes ; ensuite, la catégorie spécifique est choisie — pour les recherches, en fonction du type de contenu que la recherche renvoie. Chaque catégorie est un categories/<id>/module.md (ses règles de planification + construction) ; le vocabulaire de mouvement partagé vit dans references/motion-vocabulary.md (→ règles/plans directeurs d'hyperframes-animation + blocs de registre).

Catégories de formulaire — pas de recherche ; l'utilisateur fournit le contenu :

Catégorie	Intention	S'appuie sur
kinetic-type	ligne/ citation/ titre percutant, texte animé en priorité	blocs caption-* + règles d'animation
stat	un seul chiffre héros / compteur + anneau	apple-money-count / rules/{counting-dynamic-scale, stat-bars-and-fills}
charts	barres / lignes / camemberts / courses / % à partir de données	bloc data-chart
logo-reveal	habillage logo / verrouillage de marque (logo utilisateur)	logo-outro / rules/svg-path-draw
lower-thirds	barres de nom / titre, légendes, superpositions sociales	caption-* + blocs de superposition du registre
maps	mouvement géographique — mettre en évidence des régions, connecter des lieux, zoomer sur un emplacement (couche vectorielle ou couche de fond de carte intégrée)	famille us-map / world-map + bake-basemap.mjs

Catégories pilotées par la recherche — chercher d'abord, puis animer selon le type de contenu (le chemin RWA) :

Contenu renvoyé	Catégorie	Animation
page web / lien	webpage	animation de page web / interface (défilement, révélation, curseur, légendes)
article d'actualité	news	révélation du titre + carte source + légendes des faits clés
tweet	tweet	carte tweet animée
image / entité	asset-fusion	la géométrie de l'actif devient le graphique (fusion diégétique RWA)

Ordre de construction : une à la fois, priorité à la couverture (l'approximation est acceptable). kinetic-type porté depuis le prototype ; le reste suit.

Prérequis

macOS Apple Silicon ou Linux x64. Outils système : brew install node ffmpeg. npx hyperframes doctor une fois. Rendu GPU macOS : export PRODUCER_BROWSER_GPU_MODE=hardware.

Clés optionnelles (substituts locaux si non définies) — uniquement nécessaires pour les catégories qui sourcent/génèrent des actifs via l'utilisation de médias :

Clé	Utilisée pour	Substitut
GEMINI_API_KEY / GOOGLE_API_KEY	génération d'images (résolution d'utilisation de médias)	ignorer générer / recherche uniquement
(fournisseurs de recherche asset_scout)	recherche d'actifs réels pour webpage/news/tweet + asset-fusion	la catégorie se dégrade en sans actif

Flux

Étape 0 — Initialisation

Le répertoire de travail est la racine de l'espace de travail de l'agent ; écrivez tous les artefacts sous PROJECT_DIR = videos/<nom-du-projet>/. <nom-du-projet> : utilisez le répertoire donné par l'utilisateur, sinon un nom court en kebab-case dérivé de l'intention (<sujet>-motion). Pas le nom de base de l'espace de travail ou un horodatage.

Uniquement lorsque $PROJECT_DIR/hyperframes.json est absent :

PROJECT_DIR="${MOTION_GRAPHICS_DIR:-videos/<nom-du-projet>}"
mkdir -p "$(dirname "$PROJECT_DIR")"
npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=motion-graphics

init vérifie les compétences installées par rapport aux dernières sur GitHub et met à jour l'ensemble global si certaines sont obsolètes.

Contraintes : ne jamais hyperframes init dans la racine de l'espace de travail ; ne jamais imbriquer un autre hyperframes/ dans PROJECT_DIR ; chaque commande Bash (maître + sous-agents) est un sous-shell (cd "$PROJECT_DIR" && ...) — jamais cd nu.

Étape 1 — Planifier (sous-agent : Directeur Partie 1)

Lancer un sous-agent. prompt = agents/director.md entier + ## Contexte d'envoi (SKILL_DIR / PROJECT_DIR / la demande de l'utilisateur / Schema: <SKILL_DIR>/references/shot-plan-ir.md). Il doit :

1. Décider : cela nécessite-t-il une recherche ? (la première bifurcation)
   • Non → choisir une catégorie de formulaire (kinetic-type / stat / charts / logo-reveal / lower-thirds) ; le contenu est fourni par l'utilisateur ; asset_needs: [].
   • Oui → émettre un plan de recherche dans asset_needs[] (actualités / web / tweet / image ; requêtes bipolaires). La catégorie pilotée par la recherche spécifique (webpage / news / tweet / asset-fusion) est confirmée par le type de contenu renvoyé à l'étape 2, et finalisée à l'étape 3.
2. Écrire un brouillon de shot-plan.json (enveloppe + catégorie de formulaire choisie ou intention de recherche + asset_needs + un bref résumé du plan en un paragraphe). Schéma : references/shot-plan-ir.md.

Validation : [ -s "$PROJECT_DIR/shot-plan.json" ] && echo ok || echo missing.

Étape 2 — Source ◇ (Bash : utilisation des médias, conditionnel)

Si shot-plan.json.asset_needs n'est pas vide, résoudre les actifs (recherche / génération / récupération → chemins locaux figés au projet + registre). Voir phases/source/guide.md (encapsule media-use resolve ; les catégories pilotées par la recherche utilisent la recherche d'actualités/web/tweet/image). Si asset_needs est vide, passer à l'étape 3.

# illustratif — voir phases/source/guide.md
(cd "$PROJECT_DIR" && node <SKILL_DIR>/phases/source/resolve.mjs --plan ./shot-plan.json --out ./assets)

Dégrader gracieusement : si un fournisseur de recherche est indisponible, la catégorie revient à sans actif (le noter dans context.log).

Étape 3 — Conception (sous-agent : Directeur Partie 2)

Lancer un sous-agent (prompt = agents/director.md Partie 2 + contexte d'envoi incluant le assets/index.md résolu si l'étape 2 a été exécutée + catalog-map.md). Il conçoit le plan autour des actifs disponibles : choisir le(s) bloc(s) du catalogue + les règles/plans directeurs d'hyperframes-animation, la disposition, le mouvement, les temps forts, et (pour asset-fusion) les element_positions + la palette de pipette. Finalise shot-plan.json (content.block + content.customize + contenu par catégorie).

Étape 4 — Construire (sous-agent : Constructeur, réutilisation en priorité)

Lancer un sous-agent. prompt = agents/builder.md entier + contexte d'envoi (shot-plan.json, catalog-map.md, le module.md de la catégorie, references/motion-vocabulary.md, references/builder-contract.md). Réutilisation en priorité : npx hyperframes add <block> + personnalisation sur place ; n'écrire manuellement que les lacunes + la fonction de fusion d'actifs. Sortie compositions/index.html respectant le contrat HF (timeline GSAP en pause sur window.__timelines, class="clip" + identifiants stables, tl.seek(0), déterministe).

Étape 5 — Vérifier (Bash → sous-agent de réparation en cas d'échec)

(cd "$PROJECT_DIR" && npx hyperframes lint .)
(cd "$PROJECT_DIR" && npx hyperframes check .)
(cd "$PROJECT_DIR" && npx hyperframes snapshot --at <instants-de-preuve>)

Choisir des instants de preuve qui montrent l'état d'ouverture, le mouvement signature et la tenue finale. Inspecter la feuille de contact ou les captures générées avant de continuer. En cas d'échec de lint, check ou de capture, lancer le sous-agent de réparation (agents/finalize.md) pour un passage de correction sur place, puis relancer la porte échouée. Ne jamais modifier une durée fixe uniquement pour masquer un défaut.

Étape 6 — Approuver et rendre (Bash)

Poser une question : « prévisualiser d'abord, ou rendre ? ». Si l'utilisateur choisit la prévisualisation, ouvrir Studio et revenir à la même porte d'approbation après les révisions :

(cd "$PROJECT_DIR" && npx hyperframes preview --background)

Ne rendre qu'après une réponse explicite de rendu :

(cd "$PROJECT_DIR" && npx hyperframes render . --skill=motion-graphics -q high -o ./renders/video.mp4)
# variante superposition transparente : --format webm (ou mov)

Vérifier que la sortie existe, n'est pas vide et a la durée prévue. La remise finale nomme l'artefact, la durée réelle, la composition ou l'identifiant de l'image, les instants de preuve et la feuille de contact ou les captures inspectées. Les indicateurs se trouvent dans /hyperframes-cli → references/preview-render.md.

Tableau de reprise

État	Continuer à partir de
pas de shot-plan.json	Étape 1 (planifier)
shot-plan.json a asset_needs, pas de assets/	Étape 2 (source)
shot-plan.json final, pas de compositions/index.html	Étape 3/4 (conception+construction)
compositions/index.html existe, captures de preuve absentes	Étape 5 (vérifier)
vérifications et captures de preuve réussies, pas de rendu approuvé	Étape 6 (approbation)
rendu approuvé existe	vérifier la sortie, puis rapporter

Notes de conception (mainteneurs — l'exécution ne lit pas ceci)

• Raisonnement Asset-first : le sourçage est fait en amont et informe la conception du plan (le flux RWA : analyser → rechercher → examiner → confirmer).
• Priorité au catalogue : le catalogue HyperFrames grandit ; préférer toujours npx hyperframes add à l'écriture manuelle. Le constructeur peut toujours personnaliser après avoir ajouté.
• Le mouvement dicte : pour les morceaux courts, la priorité absolue est le mouvement — pas la composition détaillée. Les blocs offrent le souffle ; l'agent doit prioriser les transitions et le timing.

---

Document généré à partir du SKILL.md original.