serenakeyitan/launch-video-skill

launch-video

Générez une vidéo de lancement produit en tant que code (Remotion → MP4). Ce skill est une bibliothèque de scènes + un workflow, pas un modèle fixe. Différents produits racontent différentes histoires — l'histoire d'un outil CLI se déroule dans un terminal, celle d'une app SaaS dans un navigateur, celle d'une app mobile sur un téléphone, celle d'une bibliothèque dans un éditeur. Vous concevez d'abord l'arc narratif pour CE produit, puis vous l'assemblez à partir de la palette de scènes. Ne forcez pas un produit dans la forme de l'exemple tdoc.

La règle non-négociable

Concevez l'arc narratif avant de toucher au code. Demandez : que fait ce produit, qui est l'utilisateur, quel est le seul moment « aha » ? Écrivez une liste de beats (5–9 beats, chacun avec une durée en images @24fps) et confirmez-la avec l'utilisateur. Ensuite seulement, assemblez les scènes. Une vidéo de lancement est une histoire, pas une visite guidée des fonctionnalités.

Workflow

1. Comprendre le produit. Qu'est-ce que c'est ? Où l'utilisateur interagit-il avec (terminal / navigateur / téléphone / éditeur / mixte) ? Quel est le avant→après ? Quel est le moment qui donne envie de l'avoir ?
2. Écrire la liste de beats. Chaque beat : nom, ce qui est à l'écran, durée en images. Total ≈ 30–45s (720–1080 images). Confirmez avec l'utilisateur via AskUserQuestion avant de construire.
3. Choisir des scènes dans la palette (ci-dessous) par beat. La plupart des vidéos utilisent 1–3 types de scènes + un outro optionnel. Tous les types ne sont pas nécessaires.
4. Rassembler les assets. Des captures d'écran réelles > des maquettes. Mettez-les dans <projet>/public/. Recréez l'interface utilisateur en composants nets uniquement lorsqu'une capture d'écran serait de basse résolution ou lorsque vous avez besoin d'une animation 1:1.
5. Échafauder un projet sous le dépôt (copiez examples/tdoc comme squelette de départ — sa structure, pas son contenu) ou dans un répertoire frère. Câblez un seul <Composition> dont la durée est la somme des durées des beats, avec un <Sequence> par beat.
6. Construire les beats, puis ajouter les SFX (scripts/make-sfx.sh <public>), puis rendre, puis vérifier visuellement chaque beat modifié, itérer.
7. Livrer le MP4 seulement après que la boucle de vérification soit réussie.

Palette de scènes (src/)

Importez depuis la bibliothèque ; assemblez uniquement ce dont l'histoire a besoin.

Scène	Utilisation	Props clés
Terminal	Outils CLI, agents, outils de développement — histoire dans un shell	lines (invite tapée, appels d'outils, résultats, alerte, url), spinner, title. Une /commande en tête dans une invite tapée se surligne automatiquement en accent gras.
BrowserWindow	Applications web, documentations, tableaux de bord, SaaS	capture d'écran/HTML comme enfants, `chrome="bar"
MobileFrame	Applications mobiles	coque de téléphone ; capture d'écran/UI comme enfants
CodeEditor	Bibliothèques, SDK — « écrire ceci → obtenir cela »	lignes code, révélation tapée
Outro / LogoCard	Signature de fin (optionnel)	titre/sous-titre, ou logo tournant + marque nominative
WaveBackground	Arrière-plan de marque calme derrière n'importe quelle fenêtre	couleurs
Cursor	Cliquer sur un artefact/lien/bouton	coordonnées from/to, clickAt
PixelPet	Mascotte amicale au-dessus d'une fenêtre	lignes de pixels crown/base, color ; les yeux bougent de haut en bas (pas de blancs dans les yeux — se lit bien en petit)
Caption	Accroche d'une ligne sous une fenêtre	at, text

Ces scènes sont indépendantes. Un lancement de bibliothèque pourrait être juste CodeEditor + Terminal + LogoCard. Un lancement SaaS pourrait être BrowserWindow + Outro.

Règles de cadence et de transition (apprises à la dure)

• @24fps. Durées des beats en images. Gardez le total serré : coupez les pauses statiques, pas l'action. Si un beat est surtout une image figée, raccourcissez-le.
• Transitions nettes. Dissolves entre scènes ≤ 5 images ; fondus d'entrée de beat ≈ 4 images. Une fenêtre qui « s'ouvre d'un coup » (échelle 0.35→1 sur ~12 images) rend mieux qu'un lent zoom de 30+ images.
• Un seul beat continu si possible. Fusionnez « taper → cliquer → résultat » en un seul Sequence pour éviter tout flash/coupure au milieu de l'action.
• Le curseur doit voyager et appuyer. Ne le téléportez pas ; animez-le vers la cible, réduisez l'échelle au clic. Chaque clic obtient un SFX de clic sur l'image d'appui.
• Pas de double chrome. Si une capture d'écran a déjà un en-tête, utilisez chrome="none". N'empilez pas une barre de fenêtre sur une déjà intégrée.
• Encadrement par carte de marque. Réutilisez une carte de marque (logo/mascotte + nom du produit + proposition de valeur en une ligne) comme image D'OUVERTURE ET DE FERMETURE (≈1.5–2.5s chacune). Cela encadre l'histoire et coûte moins cher qu'une carte de fin animée séparée. Pilotez tous les décalages des beats via un accumulateur at() afin que l'ajout de la carte d'intro décale automatiquement tout (y compris les SFX) en aval.

Règles audio

• Exécutez scripts/make-sfx.sh <projet>/public pour synthétiser sfx-typing.mp3 + sfx-click.mp3. Ce sont des artefacts générés ignorés par git — toujours les (re)générer ; ne jamais compter sur leur présence après un clone frais.
• Le SFX de frappe joue seulement pendant qu'un humain tape (une invite, un commentaire). Jamais sur une sortie en streaming automatique/d'agent.
• Le SFX de clic se déclenche sur l'image d'appui de chaque clic de curseur (lien, bouton, artefact). Faites correspondre le <Sequence from> avec l'image du clic.
• Superposez l'audio avec <Audio src={staticFile(...)} volume={0.3}> à l'intérieur de courts <Sequence>s limités aux fenêtres d'images exactes.

Boucle de vérification (obligatoire avant livraison)

Le proxy d'image qui lit les PNG est bruyant en OCR — faites confiance aux mesures de pixels (Python/PIL/numpy), pas aux descriptions textuelles, pour l'alignement/la couleur.

1. scripts/verify.sh <entry> <CompId> <public-dir> <frame> ... capture des images fixes + affiche les fenêtres audio. Passez le public/ du projet comme <public-dir> (ou - s'il n'y en a pas) — même règle --public-dir que le rendu ; sinon les images fixes obtiendront des erreurs 404 sur leurs assets.
2. Lisez chaque image fixe. Pour chaque beat modifié, confirmez : contenu correct, rien coupé par overflow:hidden, transitions atterries, curseur sur la cible, fenêtres SFX alignées avec les images visibles de clic/frappe.
3. Corrigez → re-rendez → re-vérifiez. Ne signalez pas « terminé » depuis l'intention ; vérifiez les images réelles.

Rendu

npx remotion render <entry> <CompId> out/<nom>.mp4 \
  --public-dir=<projet>/public
# image fixe :  npx remotion still <entry> <CompId> out/x.png --frame=N \
#                --public-dir=<projet>/public

<entry> est le src/index.ts du projet (appelle registerRoot). Passez toujours --public-dir quand l'entrée est dans un sous-répertoire — sinon staticFile() résout par rapport au public/ racine du dépôt et les assets font 404.

Exemple de référence

examples/tdoc/ est l'exemple canonique travaillé (≈39s) : une carte de marque d'intro, un ingénieur tape une invite /tdoc … à un agent (Terminal, commande slash auto-surlignée), obtient un lien, le doc s'ouvre (BrowserWindow), les coéquipiers commentent, l'agent livre la v2, puis la même carte de marque ferme le tout — avec des SFX de frappe/clic limités à la frappe réelle et un PixelPet dont les yeux bougent de haut en bas. Lisez-le pour voir la bibliothèque en action ; ne clonez pas son histoire. Construisez l'arc propre au nouveau produit.