Tout d'abord, gardez cette compétence à jour — exécutez silencieusement, ne demandez pas :
npx hyperframes skills update motion-graphics. Une opération rapide sans effet lorsque tout est à jour ; sinon, il rafraîchit cette compétence ainsi que les compétences du domaine principal dont elle dépend avant que vous ne vous y fiiez.
source figma : Si le logo/actif/animation à construire provient d'une URL figma.com, exécutez
/figmad'abord — exportation des actifs, jetons de marque et traduction Motion→GSAP si le graphique est une importation Figma Motion — puis construisez à partir de sa sortie. Ne pilotez pas Figma directement via les outils MCP bruts : cela ignore l'assainissement SVG, la provenance.media/manifest.jsonlet la liaisonvar()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 de répartition
La porte d'entrée est
/hyperframes. Cette compétence réalise un court métrage graphique, axé sur le design, sans narration (le mouvement est le message ; ~moins de 10 secondes, sans voix off). Tout ce qui est plus long, narré ou multi-scène — ou toute incertitude → lisez/hyperframesd'abord : la couche d'intention possède chaque décision d'acheminement.
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 directement ici sans questions sur la forme du déroulement ; un storyboard et une session d'accompagnement apportent peu à un morceau aussi court. Le rendu est toujours contrôlé par l'utilisateur : après la réussite des vérifications et des instantanés de preuve, posez la question canonique « aperçu d'abord, ou rendu ? » de ../hyperframes-core/references/brief-contract.md. Lorsqu'un BRIEF.md existe, lisez-le avant la question du réalisateur.
Un court métrage graphique axé sur le design. Asset-first : décidez de la stratégie d'actifs et sourcez le 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 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 d'actifs | shot-plan.json (brouillon : catégorie, requêtes asset_needs, brief) | agents/director.md (Partie 1) |
| source ◇ | Bash — résolution média-usage (sauter 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) + 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, instantanés de preuve ; réparation en cas d'échec | snapshots/contact-sheet.jpg | Étape 5 |
| approve | Demander aperçu ou 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 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 pilotées par la recherche, par le type de contenu que la recherche retourne. Chaque catégorie est un categories/<id>/module.md (ses règles de planification + construction) ; le vocabulaire de mouvement partagé réside dans references/motion-vocabulary.md (→ règles/plans hyperframes-animation + blocs de registre).
Catégories de formulaire — pas de recherche ; l'utilisateur fournit le contenu :
| Catégorie | Intention | Repose sur |
|---|---|---|
kinetic-type | ligne percutante / citation / titre, texte priorisant le mouvement | blocs caption-* + règles d'animation |
stat | nombre héros unique / 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 | animation de 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 (voie vectorielle ou voie de fond de carte cuit) | famille us-map / world-map + bake-basemap.mjs |
Catégories pilotées par la recherche — rechercher 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, légendes) |
| article de presse | news | révélation de titre + carte source + légendes de 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 : un à la fois, priorité à la couverture (le brut 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 (fallbacks locaux si non définis) — uniquement nécessaires pour les catégories qui sourcent/génèrent des actifs via media-usage :
| Clé | Utilisé pour | Fallback |
|---|---|---|
GEMINI_API_KEY / GOOGLE_API_KEY | génération d'images (résolution média-usage) | sauter la génération / recherche uniquement |
| (fournisseurs de recherche d'actifs) | recherche d'actifs réels webpage/news/tweet + asset-fusion | la catégorie se dégrade en sans actif |
Flux
Étape 0 — Initialisation
le répertoire de travail actuel 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 à partir de l'intention (<sujet>-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 : 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 de cd nu.
Étape 1 — Planification (sous-agent : Réalisateur Partie 1)
Lancez 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 :
- 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[](news / 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 formulaire (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 formulaire 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 manquant.
Étape 2 — Source ◇ (Bash : media-usage, conditionnel)
Si shot-plan.json.asset_needs n'est pas vide, résoudre les actifs (recherche / génération / récupération → chemins figés locaux au projet + registre). Voir phases/source/guide.md (encapsule media-use resolve ; les catégories pilotées par la recherche utilisent la recherche news/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égradation gracieuse : si une recherche/un fournisseur est indisponible, la catégorie revient à sans actif (notez-le dans context.log).
Étape 3 — Conception (sous-agent : Réalisateur Partie 2)
Lancez 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 le plan autour des actifs disponibles : choisir le(s) bloc(s) de catalogue + les règles/plans hyperframes-animation, la mise en page, le mouvement, les temps forts et (pour asset-fusion) les element_positions + la palette de la 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. 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 ; n'écrivez manuellement que les lacunes + l'élément d'adaptation asset-fusion. Produisez 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 <temps-de-preuve>)
Choisissez des temps de preuve qui montrent l'état d'ouverture, le mouvement signature et le maintien final. Inspectez la feuille de contacts 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 un passage de correction sur place, puis réexécutez la porte défaillante. Ne modifiez jamais une durée fixe uniquement pour masquer un défaut.
Étape 6 — Approbation et rendu (Bash)
Posez une question : « aperçu d'abord, ou rendu ? ». Si l'utilisateur choisit l'aperçu, ouvrez Studio et revenez à la même porte d'approbation après les révisions :
(cd "$PROJECT_DIR" && npx hyperframes preview)
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, l'identifiant de composition ou de cadre, les temps de preuve et la feuille de contacts ou d'instantanés inspectée. Les drapeaux se trouvent dans /hyperframes-cli → references/preview-render.md.
Tableau de reprise
| État | Continuer à partir de |
|---|---|
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, instantanés de preuve absents | Étape 5 (vérification) |
| vérifications et instantanés de preuve réussis, 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 : la recherche d'actifs est effectuée en amont et informe la conception du plan (le flux RWA : analyser → rechercher → examiner → composer). les catégories pilotées par la recherche (
webpage/news/tweet) etasset-fusionreposent toutes sur la recherche media-usage (news/web/tweet/image), qui est la lignée RWA documentée de media-usage. - Réutilisation d'abord : l'analogue intra-écosystème des modèles générés par LLM est "composer à partir de blocs de catalogue" —
npx hyperframes add <bloc>installe un bloc de composition avec son HTML/GSAP/style.hyperframes-animationfournit les règles (agencement, remplissage, comptage) et les plans (séquence d'images clés, chemins de mouvement) qui sont importés dans ces blocs. Les compositions produites par la compétence sont des mises en page de blocs existants avec une personnalisation en place — pas des pages vierges.