Communitygithub.com

patryk-penczek/ship-video

Crée une vidéo de lancement, bande-annonce, teaser, démo ou tutoriel de votre application web, en pur code. Recrée l'interface réelle de l'application en HTML, l'anime avec GSAP sur une piste musicale ou en silence, et génère une vidéo MP4 1080p60 16:9 image par image (plus un WebP pour les README). Idéal lorsque vous souhaitez un film promotionnel de votre app, site ou produit, synchronisé sur une musique, un prompt Suno ou un beat généré, ou pour modifier un film existant.

Qu'est-ce que ship-video ?

ship-video est un outil de création de films promotionnels pour applications web, entièrement basé sur du code. Il ne s'agit pas d'éditer des enregistrements d'écran, mais de reconstruire l'interface utilisateur réelle de l'application en HTML, puis de l'animer avec GSAP pour créer une vidéo 16:9 de 10 à 45 secondes. Le flux de travail suit un processus rigoureux en huit étapes : configuration, briefing, découverte du produit, choix de la musique, approbation d'un scénario, réplication des états de l'interface, construction des animations, puis rendu final. Les questions posées à l'utilisateur sont limitées à trois moments clés (début, approbation du scénario, après rendu), avec un maximum de 3 questions par tour, pour rester efficace. L'outil gère la génération de musique (via Suno ou un beat local), la vérification de la qualité (via des planches contact et audits) et le rendu en 1080p60 avec ou sans flou de mouvement. Il est compatible avec Claude Code, Cursor, Codex et autres agents IA, et impose des limites claires : format 16:9 uniquement, applications web, durée 10-45 secondes. Le résultat final est un MP4 accompagné d'un WebP animé pour les README.

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/patryk-penczek/ship-video/tree/HEAD/skills/ship-video

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait ship-video ?

Vous dirigez et construisez un film de 10 à 45 secondes du produit de l'utilisateur. Tout ce qui est à l'écran est du code : une page HTML, une timeline GSAP mise en pause en secondes absolues, les écrans réels de l'application capturés depuis son DOM et animés, rendus image par image en MP4.

Comment le travail est façonné. Un film se joue ou se perd sur des choix faits avant tout code : quel spectateur, quel changement unique le produit apporte, quelle histoire, quelle durée. Ces choix sont consignés dans un scénario d'une page que l'utilisateur approuve ; le modifier sur papier coûte quelques minutes, et une fois construit, des heures. Après cela, construisez bien, vérifiez votre propre travail rigoureusement, faites le rendu, et montrez le film : l'utilisateur le regarde et vous dit quoi modifier. Ne vous arrêtez pas pour des approbations au-delà du scénario.

Les scripts se trouvent dans scripts/ à côté de ce fichier. Dans Claude Code, ce dossier est ${CLAUDE_SKILL_DIR}/scripts ; ailleurs, résolvez-le par rapport au répertoire de ce fichier et appelez-le par chemin absolu. Ci-dessous, $S est ce dossier et <film> le dossier du film. Exécutez les scripts, ne lisez pas leur source ; chacun accepte --help.

Posez des questions. Ne posez que les décisions réelles (lieu, musique, durée, le propre wording de l'utilisateur) ; décidez le reste, dites-le en une ligne, laissez-les le modifier à la porte. Ne posez des questions qu'à trois moments : l'ouverture (étape 1), la porte du scénario, après le rendu ; ne vous arrêtez jamais en cours de route. Un format convient à tous les hôtes : au maximum 3 questions par tour, 2–3 options chacune, la recommandation en premier, un libellé de 1 à 5 mots, une phrase sur ce que cela signifie pour eux, pas de "Autre" (l'hôte ajoute du texte libre). Utilisez l'outil de question de l'hôte (Claude Code : AskUserQuestion ; Codex : request_user_input, mode Plan uniquement), sinon une liste numérotée avec options lettrées ("1a 2b") se terminant par "ou dites-moi autre chose". Plus de 3 options équivaut à deux questions, la décisive en premier ; lorsqu'une réponse antérieure règle une question, intégrez-la dans les options.

Limites

Dites-le d'emblée si la demande touche une limite : 16:9 uniquement (pas de 9:16) ; interface web (une application native ne peut être reconstruite qu'à partir de captures d'écran, moins précisément) ; 10–45 s ; macOS, Linux ou Windows ; sortie MP4 et WebP animé, pas de GIF. L'installation télécharge Chromium et des packages Python dans ~/.ship-video : un hôte en bac à sable (Codex) a besoin d'un accès réseau et d'un accès en écriture là-bas ; si une commande est bloquée, dites à l'utilisateur quelle permission est nécessaire au lieu de réessayer.

Démarrer ou reprendre

Vérifiez le dossier du film (demandez lequel si ce n'est pas clair) et commencez à la première pièce manquante :

existe dans <film>commencez à
rien0 Configuration
index.html, pas de PRODUCT.md2 Découverte
PRODUCT.md, pas de MUSIC.md3 Musique
MUSIC.md, pas de SCENARIO.md approuvé (ligne Approved:)4 Scénario
SCENARIO.md approuvé, pas de screens.js (ou états pas encore comparés)5 Répliques
screens.js et review/compare/ avec chaque état correspondant, film.js de départ6 Construction
film.js avec chaque acte construit, pas de out/film-*.mp47 Révision
out/film-crisp.mp4 ou out/film-motionblur.mp4demandez quoi modifier (render.md, Modifications après le rendu)

L'utilisateur peut sauter des étapes ("J'ai un scénario", "pas de musique", "construisez-le juste") : sautez-les et dites-le en une ligne. Sauter la porte du scénario nécessite ses mots explicites.

Affichez cette liste de contrôle dans la première réponse et lors de la livraison :

- [ ] 0 Configuration   - [ ] 1 Briefing   - [ ] 2 Découverte   - [ ] 3 Musique
- [ ] 4 Scénario (approuvé)   - [ ] 5 Répliques   - [ ] 6 Construction
- [ ] 7 Révision   - [ ] 8 Rendu et livraison

0. Configuration

node $S/lib/check.mjs : instantané une fois la configuration exécutée. Uniquement si quelque chose manque : node $S/setup.mjs (installe dans ~/.ship-video, ignore ce qui est déjà présent).

1. Briefing

Regardez d'abord : README, package.json, routes, composants, le site, les captures d'écran et logos existants (les ressources réelles sont utilisées sans demander). Ensuite, demandez ce qui manque encore en deux tours consécutifs (la durée dépend de la musique) :

  1. Où ça joue : les trois endroits les plus probables pour ce produit (un fil social, le site web, un README ou de la documentation, un centre d'aide), celui vers lequel il pointe en premier. Cela définit ce que le spectateur sait, si le son est activé, l'ouverture (direction.md, Le test du spectateur) et la taille de texte minimale.
  2. Musique : oui ou non ; recommendez non là où cet endroit est muet, et sur oui dites que la musique n'atteint que le MP4 (le WebP d'un README est silencieux).
  3. Deuxième tour · Source de la musique (la question de l'étape 3, maintenant, pour qu'une piste Suno soit générée pendant que vous travaillez) et durée : la plus courte qui montre le changement unique du produit (10–15 s est souvent le mieux), une plus longue, et avec musique Ajusté à la musique (la piste la définit, coupée sur les mesures à ce que le matériau supporte ; recommandé alors).

Le type de film (lancement, teaser d'une fonctionnalité, tutoriel, page de destination) découle généralement de la demande et du lieu : énoncez-le. Tout ce qu'ils ont déjà dit répond à sa question.

Un film dont ils veulent le ressenti : décomposez-le en une planche contact (ffmpeg -i ref.mp4 -vf "fps=2,scale=480:-1,tile=6x5" <film>/review/reference.png), listez ses techniques, empruntez-les, jamais son contenu.

Créez le dossier : node $S/new-film.mjs <film> (en dehors du dépôt du produit sauf s'ils le souhaitent à l'intérieur ; --theme light|dark si connu ; --silent pour un film sans musique).

2. Découverte

Un film fait à partir du README montre des fonctionnalités ; un film fait à partir de l'ensemble du produit montre une valeur ajoutée. Connaissez d'abord le produit. Pour tout ce qui dépasse une petite application, divisez cela en trois sous-agents parallèles si possible (subagents.md).

  1. Inventaire de chaque route et vue depuis le routeur, avec les états qui comptent (dialogues, palettes, toasts, états vides, thèmes) et tout ce qui est en direct (graphiques, cartes, toiles).
  2. Voir chacune : avec l'application en cours d'exécution (réutilisez son serveur, render.md, Partager la machine) node $S/capture.mjs <url> <film> --discover écrit une capture d'écran par route dans <film>/review/discovery/ ; Lisez-les. Connexions, téléphones, pages de destination : replicas.md, Options. Pas en cours d'exécution : utilisez ses captures d'écran et sa documentation, et dites-le.
  3. Trouvez ce qui est nouveau et ce qui est spécial : le changelog, les notes de version, gh pr list --state merged --limit 30 si disponible ; les 3 à 5 moments qu'un utilisateur montrerait à un ami ; le changement unique qui est le produit.
  4. Écrivez <film>/PRODUCT.md : la promesse dans les mots du produit, le spectateur, les vues (cœur / à côté / ignorer, avec les chemins des captures d'écran), les moments époustouflants, le cas concret qui pourrait porter le film, ce qui ne peut pas être montré. Montrez-le en quelques lignes et continuez ; les corrections peuvent venir à tout moment, au plus tard à la porte.

3. Musique

Lisez music.md. Pas de musique : une grille BPM ; lisez direction.md, Films silencieux. La question de la source (posée dans l'ouverture) montre les trois options, une ligne chacune sur ce qu'elles coûtent (un nouveau fichier dans ~/Downloads va dans la ligne de son propre fichier) :

  • Beat généré : gratuit, libre de droits, prêt en quelques secondes, une partition fonctionnelle plutôt qu'une chanson. Écrivez beat.json à partir des actes prévus et exécutez music.mjs synth.
  • Suno : une vraie chanson adaptée aux mesures du film ; nécessite un compte Suno, environ 10 minutes de leur temps, un forfait payant pour quelque chose de public, donc pour un endroit public étiquetez Suno (forfait payant) (music.md, Droits). Guidez-les (suno-prompt.md, Guider l'utilisateur). Ne restez pas inactif : écrivez MUSIC.md à partir d'un GRID DRAFT et ébauchez le scénario pendant qu'ils génèrent.
  • Son propre fichier : copiez-le dans <film>/track.<ext>.

Analysez la piste, lisez le plot, confirmez le drop vous-même, et écrivez <film>/MUSIC.md avec le rôle narratif de chaque section.

4. Scénario

Lisez direction.md et écrivez <film>/SCENARIO.md à partir de scenario-template.md : le spectateur, l'histoire (problème → héros → action → valeur ajoutée sur le drop), chaque plan avec ses secondes, ce qui bouge et où la caméra atterrit, le texte final mot pour mot. Exécutez l'auto-vérification du modèle et corrigez d'abord les "non". Dites à l'utilisateur si la durée ne correspond pas au matériau et proposez la meilleure.

Ensuite, demandez, en un tour : des variantes uniquement là où le wording est le leur, et "Approuver le scénario ?" (Approuver / Modifier le timing / Modifier les scènes) avec l'histoire en trois lignes et le tableau des plans.

5. Répliques

Lisez replicas.md. Avec l'application en cours d'exécution, son propre DOM et CSS sont la réplique : écrivez <film>/states.json avec chaque état nécessaire au scénario (les deux côtés de chaque interaction), exécutez capture.mjs … --css, puis compare.mjs, et lisez les PNG de comparaison jusqu'à ce que chaque état corresponde. Sans application en cours d'exécution, construisez à partir des composants et dites-le dans le rapport.

6. Construction

Lisez film-api.md et shots.md. Définissez track, duration, hits (music.md) et fonts/images à partir de la sortie de capture, puis écrivez les scènes dans l'ordre du scénario aux secondes du scénario. Animez les éléments réels à l'intérieur des écrans capturés (direction.md). Là où vous vous écartez du scénario, ajoutez une ligne à Modifications par rapport au scénario.

Vérifiez au fur et à mesure : node $S/render.mjs <film>/index.html <film>/review/test.mp4 --preset draft --from 0 --to 1 détecte une page cassée en quelques secondes ; l'utilisateur peut ouvrir <film>/index.html pour prévisualiser (Espace joue, flèches font avancer, ?t=12.5).

7. Révision

Regardez le film en tant que réalisateur avant quiconque :

node $S/sheet.mjs <film>/index.html <from> <to> <step> <film>/review/sheet-<act>.png
node $S/shots.mjs <film>/index.html <film>/review/stills <t1> <t2> … --label

Une planche contact par acte (pas de 0,25 s pour le texte, 0,5 s pour l'interface), des images fixes en pleine résolution de chaque coupe + 0,01 s, la valeur ajoutée et le carton de fin. Lisez chaque image et exécutez l'auto-vérification de scenario-template.md sur les trames ; zoomez sur chaque interaction à des pas de 0,1 s, car la plupart des sensations "inachevées" vivent dans ces demi-secondes. Ensuite, obtenez l'avis d'un critique frais (subagents.md) et corrigez ce qui bloque. Terminez avec node $S/audit.mjs <film>/index.html jusqu'à ce que ce soit propre (render.md, Audit).

8. Rendu et livraison

Lisez render.md : effectuez le rendu net en arrière-plan, vérifiez-le (hits.mjs, motion.mjs), corrigez et refaites le rendu si nécessaire, puis livrez (Livraison : le dossier s'ouvre, une première coupe, une question).

Références

fichierlire à
references/direction.md4, et à nouveau en 6 et 7 : le test du spectateur, l'histoire, la structure, le rythme, le cadrage, les types de films
references/scenario-template.md4 (modèle et auto-vérification), 7 (auto-vérification sur les trames)
references/music.md3 : analyse, MUSIC.md, grille silencieuse, beat généré, droits
references/suno-prompt.md3, lorsque la musique vient de Suno
references/replicas.md2 (options de capture) et 5
references/film-api.md6, avant d'écrire film.js
references/shots.md6 : recettes avec code
references/subagents.md2 et 7, si votre hôte peut exécuter des sous-agents
references/render.md7 (audit) et 8 ; Partager la machine avant de démarrer des serveurs ou des rendus

Skills associés