berhjoan/motion-graphics

Installations de plugins : Avant les commandes de configuration ou de mise à jour, suivez les règles d'exécution des plugins lorsque cette compétence se trouve à l'intérieur d'un plugin HyperFrames. Les installations autonomes conservent les instructions de mise à jour ci-dessous.

Premièrement, gardez cette compétence à jour — confirmez avec l'utilisateur avant d'exécuter : npx hyperframes skills update motion-graphics. C'est une opération rapide sans effet si tout est à jour ; sinon, cela actualise cette compétence ainsi que les compétences de base du domaine dont elle dépend avant que vous ne les utilisiez.

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

motion-graphics — point d'entrée

La porte d'entrée est /hyperframes. Cette compétence crée une ** courte animation graphique dirigée par le design, sans narration** (le mouvement est le message ; ~moins de 10s, pas de voix off). Tout ce qui est plus long, narré ou multi-scène — ou toute incertitude → lisez /hyperframes d'abord : la couche d'intention possède chaque décision d'itinéraire.

Ce flux de travail est autonome par conception — au plus une question de clarification (agents/director.md), puis construisez jusqu'à la vérification sans révision intermédiaire. La couche d'intention (/hyperframes → references/intent-interview.md) achemine ici directement sans questions sur la forme de l'exécution ; un storyboard et une session d'accompagnement ajoutent peu à un morceau aussi court. Le rendu est toujours contrôlé par l'utilisateur : après la réussite des vérifications et des captures d'écran de preuve, ouvrez l'aperçu Studio et posez la question canonique « rendre maintenant, ou quels changements ? » de ../hyperframes/references/brief-contract.md. Lorsqu'un BRIEF.md existe, lisez-le avant la question du directeur.

Une courte animation graphique dirigée par le design. Priorité aux ressources : décidez de la stratégie de ressources et obtenez du matériel réel avant de concevoir la séquence, puis concevez la séquence autour de ce que vous avez, puis composez en réutilisant les capacités du catalogue. Tous les artefacts vont dans PROJECT_DIR = videos/<project-name>/ (créé à l'étape 0) ; tous les chemins ci-dessous sont relatifs à celui-ci.

Phase	Exécution	Artefact principal	Flux détaillé
init	Bash	hyperframes.json	Étape 0
plan	sous-agent — décider de la recherche ? + classifier + stratégie de ressources	shot-plan.json (brouillon : catégorie, requêtes asset_needs, brief)	agents/director.md (Partie 1)
source ◇	Bash — résolution des médias (sauter si asset_needs est vide)	assets/ + assets/index.md	phases/source/guide.md
design	sous-agent — conception de la séquence autour des ressources résolues	shot-plan.json (final : bloc(s) + mise en page + mouvement + positions)	agents/director.md (Partie 2)
build	sous-agent — composition priorisant la réutilisation	compositions/index.html	agents/builder.md
verify	Bash — lint, check, captures d'écran de preuve ; réparation en cas d'échec	snapshots/contact-sheet.jpg	Étape 5
approve	Ouvrir l'aperçu ; demander le rendu ou les modifications ; 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 ressources. Les catégories de code/texte pur (par exemple kinetic-type, la plupart des charts/stat) ont asset_needs: [] et passent directement de la planification à la conception.

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

La première décision de 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 catégories basées sur la recherche, par le 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 hyperframes-animation + blocs de registre).

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

Catégorie	Intention	S'appuie sur
kinetic-type	ligne/ citation / titre percutant, texte prioritaire au mouvement	blocs caption-* + règles d'animation
stat	numéro héroïque unique / compteur + anneau	apple-money-count / rules/{counting-dynamic-scale, stat-bars-and-fills}
charts	barres / lignes / camemberts / course / % à partir de données	bloc data-chart
logo-reveal	logo sting / 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 (voie vectorielle, ou voie de fond de carte intégrée)	famille us-map / world-map + bake-basemap.mjs

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

Contenu renvoyé	Catégorie	Animation
page Web / lien	webpage	animation de page Web / UI (défilement, révélation, curseur, légendes)
article de presse	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 la ressource devient le graphique (fusion diégétique RWA)

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

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 (fallbacks locaux si non définies) — uniquement nécessaires pour les catégories qui sourcent/génèrent des ressources via l'utilisation de médias :

Clé	Utilisé pour	Fallback
GEMINI_API_KEY / GOOGLE_API_KEY	génération d'images (résolution d'utilisation de médias)	ignorer la génération / recherche uniquement
(fournisseurs de recherche asset_scout)	recherche de ressources réelles webpage/news/tweet + asset-fusion	la catégorie se dégrade en absence de ressources

Flux

Étape 0 — Initialisation

cwd est la racine de l'espace de travail de l'agent ; écrivez tous les artefacts sous PROJECT_DIR = videos/<project-name>/. <project-name> : 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/<project-name>}"
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/ à l'intérieur de PROJECT_DIR ; chaque commande Bash (maître + sous-agents) est un sous-shell (cd "$PROJECT_DIR" && ...) — jamais de cd nu.

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

Envoyez un sous-agent. invite = agents/director.md complet + ## Contexte de répartition (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 forme (kinetic-type / stat / charts / logo-reveal / lower-thirds / maps) ; 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 basée sur 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 shot-plan.json (enveloppe + catégorie de forme choisie ou intention de recherche + asset_needs + un brief de séquence d'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, conditionnelle)

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

Dégradation gracieuse : si un fournisseur de recherche est indisponible, la catégorie revient à l'absence de ressources (le noter dans context.log).

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

Envoyez un sous-agent (invite = agents/director.md Partie 2 + contexte de répartition incluant le assets/index.md résolu si l'étape 2 a été exécutée + catalog-map.md). Il conçoit la séquence autour des ressources disponibles : choisir le(s) bloc(s) du catalogue + les règles/plans hyperframes-animation, la mise en page, le mouvement, les temps, 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 — Construction (sous-agent : Constructeur, priorité à la réutilisation)

Incluez les principes de mouvement partagés dans le contexte de répartition du Constructeur. Pour charts et stat, incluez également les données en mouvement. Le Constructeur lit ces guides avant d'écrire la timeline.

Envoyez un sous-agent. invite = agents/builder.md complet + contexte de répartition (shot-plan.json, catalog-map.md, le module.md de la catégorie, references/motion-vocabulary.md, references/builder-contract.md). Priorité à la réutilisation : npx hyperframes add <block> + personnalisation sur place ; écrire à la main uniquement les lacunes + l'affordance de fusion de ressources. 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érification (Bash → sous-agent de réparation en cas d'échec)

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

Choisissez des temps de preuve qui montrent l'état d'ouverture, le mouvement signature et la tenue finale. Inspectez la feuille de contact ou de capture générée avant de continuer. En cas d'échec de lint, check ou de capture, envoyez le sous-agent de réparation (agents/finalize.md) pour un passage de correction sur place, puis réexécutez la barrière défaillante. Ne modifiez jamais une durée fixe uniquement pour masquer un défaut.

Étape 6 — Approbation et rendu (Bash)

Ouvrez Studio, puis posez une question : « rendre maintenant, ou quels changements ? » Après les révisions, revenez à la même barrière :

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

Rendu uniquement 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érifiez 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 temps de preuve et la feuille de contact ou de capture inspectée. Les indicateurs se trouvent dans /hyperframes-cli → references/preview-render.md.

Tableau de reprise

État	Continuer depuis
pas de shot-plan.json	Étape 1 (planification)
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érification)
vérifications et captures de preuve réussies, pas de rendu approuvé	Étape 6 (approbation)
rendu approuvé existe	vérifier la sortie, puis signaler

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

• Rationnement prioritaire aux ressources

…

[tronqué pour la traduction]