Installation du plugin : Avant les commandes de configuration ou de mise à jour, suivez les règles d'exécution du plugin lorsque cette compétence se trouve dans un plugin HyperFrames. Les installations autonomes conservent les instructions de mise à jour ci-dessous.
D'abord, gardez cette compétence à jour — confirmez avec l'utilisateur avant d'exécuter :
npx hyperframes skills update motion-graphics. Une opération rapide sans effet si tout est à jour ; sinon, elle rafraîchit cette compétence ainsi que les compétences du domaine central dont elle dépend avant que vous ne les utilisiez.
source figma: Si le logo/élément/animation à construire provient d'une URL figma.com, exécutez
/figmad'abord — export d'actifs, tokens 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 liaisonvar()des tokens de marque, de sorte qu'un changement ultérieur de marque ne peut pas se propager sans une réimportation complète.
motion-graphics — point d'entrée de répartition
La porte d'entrée est
/hyperframes. Cette compétence crée un motion graphic court, dirigé par le design, sans narration (le mouvement est le message ; ~moins de 10s, sans voix off). Tout ce qui est plus long, narré ou multi-scène — ou en cas d'incertitude → lisez/hyperframesd'abord : la couche d'intention possède toutes les décisions d'acheminement.
Ce flux de travail est autonome par conception — au plus une question de clarification (agents/director.md), puis construction via vérification sans révision intermédiaire. La couche d'intention (/hyperframes → references/intent-interview.md) achemine directement ici sans questions sur la forme du plan ; un storyboard et une session d'accompagnement apportent peu à un morceau aussi court. Le rendu est toujours contrôlé par l'utilisateur : une fois les vérifications et les preuves photographiques passées, posez la question canonique « prévisualisation ou rendu ? » de ../hyperframes/references/brief-contract.md. Lorsqu'un BRIEF.md existe, lisez-le avant la question du réalisateur.
Un court motion graphic dirigé par le design. Actif d'abord : décidez de la stratégie d'actifs et sourcez du matériel réel 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/<project-name>/ (créé à l'étape 0) ; tous les chemins ci-dessous lui sont relatifs.
| Phase | Exécution | Artefact principal | Flux détaillé |
|---|---|---|---|
| init | Bash | hyperframes.json | Étape 0 |
| plan | sous-agent — décider recherche ? + classifier + stratégie actifs | shot-plan.json (brouillon : catégorie, requêtes asset_needs, brief) | agents/director.md (Partie 1) |
| source ◇ | Bash — résolution media-use (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 priorisant la réutilisation | compositions/index.html | agents/builder.md |
| verify | Bash — lint, check, preuves photographiques ; réparation en cas d'échec | snapshots/contact-sheet.jpg | Étape 5 |
| approve | Demander prévisualisation ou rendu ; attendre la réponse | approbation explicite du rendu | Étape 6 |
| render | Bash — hyperframes render (MP4, ou --format webm/mov pour overlay) | renders/video.mp4 ou calque transparent | Étape 6 |
◇ source s'exécute uniquement lorsque la catégorie choisie déclare des actifs. Les catégories purement basées sur le code/texte (par exemple 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 de plan est : cela nécessite-t-il une recherche ? Cette fourche divise les catégories en deux groupes ; ensuite, la catégorie spécifique est choisie — pour les catégories pilotées par 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 du registre).
Catégories de forme — aucune recherche ; l'utilisateur fournit le contenu :
| Catégorie | Intention | S'appuie sur |
|---|---|---|
kinetic-type | ligne percutante / citation / titre, texte prioritaire au mouvement | blocs caption-* + règles d'animation |
stat | un seul nombre héroïque / compteur + anneau | apple-money-count / rules/{counting-dynamic-scale, stat-bars-and-fills} |
charts | barre / ligne / camembert / course / % à partir de données | bloc data-chart |
logo-reveal | logo sting / habillage de marque (logo utilisateur) | logo-outro / rules/svg-path-draw |
lower-thirds | barres de nom / titre, callouts, 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 par type de contenu (le chemin RWA) :
| Contenu retourné | Catégorie | Animation |
|---|---|---|
| page web / lien | webpage | animation de page web / UI (défilement, révélation, curseur, callouts) |
| article de presse | news | révélation de titre + carte source + callouts de faits clés |
| tweet | tweet | carte de 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 : un à la fois, priorité à la couverture (l'approximation est acceptable). kinetic-type porté du 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 (repli local si non définies) — nécessaires uniquement pour les catégories qui sourcent/génèrent des actifs via media-use :
| Clé | Utilisé pour | Repli |
|---|---|---|
GEMINI_API_KEY / GOOGLE_API_KEY | génération d'images (résolution media-use) | ignorer la génération / recherche seule |
| (fournisseurs asset_scout / recherche) | recherche d'actifs réels webpage/news/tweet + asset-fusion | la catégorie dégrade vers 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/<project-name>/. <project-name> : utilisez le répertoire donné par l'utilisateur, sinon un court nom en kebab-case dérivé de l'intention (<subject>-motion). Pas le nom de base de l'espace de travail ou un timestamp.
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 : jamais hyperframes init dans la racine de l'espace de travail ; 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 cd nu.
Étape 1 — Planification (sous-agent : Directeur Partie 1)
Lancez un sous-agent. prompt = 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 :
- Décider : cela nécessite-t-il une recherche ? (la première fourche)
- Non → choisir une catégorie de forme (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 retourné à l'étape 2, et finalisée à l'étape 3.
- Non → choisir une catégorie de forme (kinetic-type / stat / charts / logo-reveal / lower-thirds) ; le contenu est fourni par l'utilisateur ;
- Écrire un brouillon de
shot-plan.json(enveloppe + catégorie de forme choisie ou intention de recherche +asset_needs+ un brief de plan 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 : media-use, conditionnel)
Si shot-plan.json.asset_needs n'est pas vide, résoudre les actifs (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 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 une recherche/un fournisseur est indisponible, la catégorie retombe sur un mode sans actif (le noter dans context.log).
Étape 3 — Conception (sous-agent : Directeur Partie 2)
Lancez un sous-agent (prompt = 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 le plan autour des actifs disponibles : choisir le(s) bloc(s) de catalogue + les règles/plans 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 — Construction (sous-agent : Constructeur, priorité à la réutilisation)
Lancez un sous-agent. prompt = 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 ; rédiger manuellement uniquement les lacunes + l'interface 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érification (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 <proof-times>)
Choisissez des temps de preuve qui montrent l'état d'ouverture, le mouvement signature et la tenue finale. Inspectez la feuille de contact ou d'instantanés générée avant de continuer. En cas d'échec de lint, check ou d'instantané, lancez le sous-agent de réparation (agents/finalize.md) pour une passe de correction sur place, puis réexécutez la passerelle défaillante. Ne modifiez jamais une durée fixe simplement pour masquer un défaut.
Étape 6 — Approbation et rendu (Bash)
Posez une question : « prévisualisation ou rendu ? » Si l'utilisateur choisit la prévisualisation, ouvrez Studio et revenez à la même passerelle d'approbation après les révisions :
(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 de calque transparent : --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, l'identifiant de composition ou de trame, les temps de preuve et la feuille de contact ou d'instantanés 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, preuves photographiques absentes | Étape 5 (vérification) |
| vérifications et preuves photographiques passent, pas de rendu approuvé | Étape 6 (approbation) |
| rendu approuvé existe | vérifier la sortie, puis faire rapport |
Notes de conception (mainteneurs — l'exécution ne lit pas ceci)
- Raison d'être de l'approche actif d'abord : la recherche de sources est chargée en amont et informe la conception du plan (le flux RWA : analyser → rechercher → examiner → c...