motion-graphics — point d'entrée dispatch
Confirmer la route avant l'Étape 0. Cette compétence crée un graphisme animé court, design-led, non narré (le mouvement est le message ; ~moins de 10s, pas de voix-off). Un traitement plus long, multi-scènes ou narré →
/general-video; une vidéo narrée d'un site web →/general-video; un expliqueur de sujet →/faceless-explainer; une promotion produit →/product-launch-video; des sous-titres sur des images existantes →/embedded-captions. Hors scope : données en direct / au moment du rendu, ou séquences qu'elle ne peut pas capturer. Vous n'êtes pas sûr entre du motion-first et du narré ? Lisez/hyperframesd'abord.
Un graphisme animé court axé sur le design. D'abord les assets : décidez la stratégie d'assets et sourcez le matériel réel avant de concevoir le plan, puis concevez le plan autour de ce que vous avez, enfin 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 y sont relatifs.
| Phase | Exécution | Artefact principal | Flux détaillé |
|---|---|---|---|
| init | Bash | hyperframes.json | Étape 0 |
| plan | sous-agent — décider si recherche ? + classifier + stratégie d'assets | shot-plan.json (brouillon : catégorie, asset_needs requêtes, 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 assets résolus | shot-plan.json (final : blocs + layout + motion + positions) | agents/director.md (Partie 2) |
| build | sous-agent — composition réutilisation en premier | compositions/index.html | agents/builder.md |
| render | Bash — hyperframes render (MP4, ou --format webm/mov pour overlay) | renders/video.mp4 | Étape 5 |
| verify | Bash — lint / inspect -> sous-agent de réparation en cas d'échec | (corrections sur place) | agents/finalize.md |
◇ source s'exécute uniquement si la catégorie choisie déclare des assets. Les catégories purement code/texte (ex. 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 : a-t-on besoin d'une recherche ? Cette bifurcation sépare les catégories en deux groupes ; puis la catégorie spécifique est choisie — pour les catégories basées sur la recherche, selon 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é se trouve 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 | S'appuie sur |
|---|---|---|
kinetic-type | Ligne / citation / titre percutant, texte animé en priorité | Blocs caption-* + règles d'animation |
stat | Un seul chiffre héroïque / compteur + cercle | apple-money-count / rules/{counting-dynamic-scale, stat-bars-and-fills} |
charts | Barres / lignes / camembert / course / % à partir de données | Bloc data-chart |
logo-reveal | Logo sting / bloc de marque (logo utilisateur) | logo-outro / rules/svg-path-draw |
lower-thirds | Barres de nom / titre, callouts, overlays sociaux | caption-* + blocs d'overlay du registre |
Catégories basées sur la recherche — recherche d'abord, puis animer selon le 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 d'actualité | 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'asset devient le graphique (fusion diégétique RWA) |
Ordre de construction : un à la fois, priorité à la couverture (le brut suffit). 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 (fallbacks locaux si non définis) — nécessaires uniquement par les catégories qui sourcent/génèrent des assets via media-usage :
| Clé | Utilisé pour | Fallback |
|---|---|---|
GEMINI_API_KEY / GOOGLE_API_KEY | Génération d'images (résolution media-usage) | sauter génération / recherche seulement |
| (asset_scout / fournisseurs de recherche) | Recherche d'assets réels pour webpage/news/tweet + asset-fusion | La catégorie se dégrade en sans asset |
Flux
Étape 0 — Initialisation
cwd 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 ni un timestamp.
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
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 faire 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 : Directeur Partie 1)
Dépêchez un sous-agent. prompt = l'intégralité de agents/director.md + ## Contexte de dispatch (SKILL_DIR / PROJECT_DIR / la demande de l'utilisateur / Schema: <SKILL_DIR>/references/shot-plan-ir.md). Il doit :
- Décider : a-t-on besoin d'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 à deux pôles). La catégorie basée sur 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 missing.
Étape 2 — Source ◇ (Bash : media-usage, conditionnel)
Si shot-plan.json.asset_needs n'est pas vide, résoudre les assets (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 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égrader élégamment : si un fournisseur de recherche est indisponible, la catégorie retombe en sans asset (noter dans context.log).
Étape 3 — Conception (sous-agent : Directeur Partie 2)
Dépêchez un sous-agent (prompt = agents/director.md Partie 2 + contexte de dispatch incluant le assets/index.md résolu si l'Étape 2 a eu lieu + catalog-map.md). Il conçoit le plan autour des assets disponibles : choisir les blocs de catalogue + les règles/plans hyperframes-animation, le layout, le mouvement, les beats, et (pour asset-fusion) les element_positions + palette de pipette. Finalise shot-plan.json (content.block + content.customize + contenu par catégorie).
Étape 4 — Construction (sous-agent : Builder, réutilisation en premier)
Dépêchez un sous-agent. prompt = l'intégralité de agents/builder.md + contexte de dispatch (shot-plan.json, catalog-map.md, le module.md de la catégorie, references/motion-vocabulary.md, references/builder-contract.md). Réutilisation en premier : npx hyperframes add <block> + personnalisation sur place ; n'écrire à la main que les lacunes + l'affordance de fusion d'assets. Sortie : compositions/index.html respectant le contrat HF (timeline GSAP en pause sur window.__timelines, class="clip" + ids stables, tl.seek(0), déterministe).
Étape 5 — Rendu (Bash)
(cd "$PROJECT_DIR" && npx hyperframes render . --skill=motion-graphics -q draft -o ./renders/video.mp4)
# variante overlay transparent : --format webm (ou mov)
Étape 6 — Vérification (Bash → sous-agent de réparation en cas d'échec)
(cd "$PROJECT_DIR" && npx hyperframes lint . && npx hyperframes inspect .)
exit 0 → terminé. Sur erreurs lint/inspect, dépêchez le sous-agent de réparation (agents/finalize.md : QA instantanée + un passage de correction sur place + re-rendu). Ne jamais changer une durée fixe dans la réparation.
Rapport + aperçu optionnel
Rapportez la sortie finale (renders/video.mp4, ou la variante overlay .webm / .mov) + durée. N'ouvrez pas d'aperçu pendant l'exécution. Proposez-en un uniquement sur demande, démarré après le rendu pour qu'il serve le fichier final :
(cd "$PROJECT_DIR" && npx hyperframes preview) # Interface Studio ; ou `npx hyperframes play` pour un lien partageable
Les drapeaux se trouvent dans la compétence 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, pas de renders/video.mp4 | Étape 5 (rendu) + Étape 6 |
renders/video.mp4 existe | Rapport + arrêt |
Notes de conception (mainteneurs — l'exécution ne lit pas ceci)
- Raison d'être des assets en premier : le sourcing est fait en amont et informe la conception du plan (le flux RWA : analyser → chercher → examiner → composer). Les catégories basées sur la recherche (
webpage/news/tweet) etasset-fusions'appuient toutes sur la recherche media-usage (news/web/tweet/image), qui est la lignée RWA documentée de media-usage. - Réutilisation en premier : l'équivalent dans l'écosystème des templates générés par LLM est "composer des blocs de catalogue + règles
hyperframes-animation". La timeline GSAP en pause de HF est l'équivalent duuseCurrentFramede Remotion. - Contrat de module de catégorie : un
categories/<id>/module.md(planification + construction), partageantreferences/motion-vocabulary.md(+ évaluation optionnelle). Ajouter une catégorie = déposer le dossier + enregistrer sa ligne de classification dansagents/director.md+ sa ligne danscatalog-map.md; le pipeline des phases est inchangé. - Forme du répertoire :
videos/<nom-du-projet>/ hyperframes.json context.log shot-plan.json # l'IR (sortie du Directeur) assets/ assets/index.md # sortie de media-usage (si sourcé) compositions/index.html # sortie du Builder renders/video.mp4 - Enregistrement : dans le routeur
hyperframes— ajouter l'intention "graphisme animé court design-led" + description du Workflow ; tailler les déclencheurs de motion-graphics hors de/general-video; ajouter les arêtes inverses de NE-PAS-utiliser. Voirmotion-graphics-genre.md§5-7.