Communitygithub.com

Sachin-pro-dev/PITCHFRAME-push-to-prod

Génère le plan de scènes Remotion pour une vidéo de lancement et le rend au format MP4, en étendant les composants beat uniquement lorsque le plan nécessite quelque chose qu'ils ne peuvent vraiment pas exprimer. Utilisé par Pitchframe pour les étapes de génération de code et de rendu.

Qu'est-ce que PITCHFRAME-push-to-prod ?

Ce skill permet de transformer un brief en un plan de scènes (plan.json) et de le rendre en une vidéo MP4 à l'aide de Remotion. Il est conçu pour Pitchframe, un outil de génération de vidéos de lancement de produits. Le skill suit un principe strict : le projet de référence définit le niveau de qualité de chaque vidéo, et la modification du code des composants doit être évitée à moins que le plan ne nécessite quelque chose que les composants existants ne peuvent pas exprimer. Il gère la génération du plan à partir d'un brief, l'extraction des couleurs, la capture d'écran, et le rendu final. Le skill inclut des vérifications mathématiques pour garantir la cohérence des beats (durée, cadrage, etc.) et un tableau de dépannage pour les erreurs de rendu courantes. Après un rendu réussi, il fournit un chemin vers le fichier MP4 et une invitation à modifier la vidéo via un autre skill d'édition.

Compatible avec~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/Sachin-pro-dev/PITCHFRAME-push-to-prod/tree/HEAD/skills/pitchframe-remotion

Demander à votre IA préférée

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

Documentation

Génération de code et rendu

Vous transformez un brief en plan.json et le rendez. Le projet de référence implémente déjà la grammaire de la vidéo de lancement — vous lui fournissez des données, vous n'écrivez pas une vidéo à partir de zéro.

Le niveau de finition du projet de référence est le niveau de finition de chaque vidéo que cet outil produira jamais. Donc la valeur par défaut forte est : écrire plan.json, ne rien changer d'autre. Chaque ligne d'animation sur mesure que vous ajoutez à une exécution est une finition qui n'atteindra jamais la vidéo suivante, et une nouvelle façon pour le rendu de planter.

Le plan des fichiers

pitchframe/
├── plan.json               ← le plan des scènes. C'est la vidéo.
├── palette.json            ← couleurs extraites. Données, jamais de prose.
├── public/assets/*.png     ← captures d'écran.
├── scripts/
│   ├── extract-palette.mjs ← tailwind → variables CSS → URL dynamique
│   ├── apply-palette.mjs   ← écrit src/theme.ts à partir de palette.json
│   └── capture.mjs         ← serveur de dev + capture Playwright
├── src/
│   ├── Root.tsx            ← enregistre la composition LaunchVideo
│   ├── LaunchVideo.tsx     ← mappe les beats aux Sequences. Gère le cross-dissolve.
│   ├── theme.ts            ← GÉNÉRÉ. Toutes les couleurs résolvent ici.
│   ├── lib/
│   │   ├── types.ts        ← le contrat du plan
│   │   └── motion.ts       ← easing, fondus, impulsion de clic, dérive maintenue
│   ├── components/         ← Fond, Curseur, FocusOverlay, Zoom, Panneau, …
│   └── scenes/
│       ├── TypographyBeat.tsx
│       ├── InteractionBeat.tsx   ← le moment héroïque
│       ├── UIBeat.tsx
│       └── CTABeat.tsx
└── output.mp4

Écrire le plan

Chargez pitchframe-launch-video pour la structure et le schéma. La version courte :

  • Quatre parties — mise en place, héroïque, récompense, CTA. Dans cet ordre. Toujours.
  • Exactement un beat interaction, et il obtient au moins 30 % des images.
  • La durée provient de thesis_weight dans le brief, pas d'une valeur par défaut.
  • Copiez video_thesis et hero_moment dans le plan pour que la passe de critique puisse vérifier la vidéo par rapport à l'affirmation.

Obtenez l'arithmétique correcte avant de rendre

Un rendu échoué coûte deux minutes ; un plan dont les beats dérivent coûte un nouveau rendu plus le temps de le remarquer. Vérifiez à la main, à chaque fois :

  • Beats contigus — chaque frames[0] est égal au frames[1] précédent.
  • Le premier beat commence à 0 ; le dernier beat se termine exactement à total_frames.
  • total_frames === duration_seconds * fps.
  • Pas de beat typographique en dessous de 45 images.
  • Le beat interaction ≥ 30 % de total_frames.

Raisonnez sur les coordonnées, ne les devinez pas

target_element.coordinates et zoom_target sont des pourcentages de la capture d'écran. Ce sont des affirmations sur où se trouvent les pixels intéressants, et un point focal décalé de 10 % centre le plan héroïque sur du chrome vide.

Ouvrez la capture d'écran, trouvez l'élément, convertissez en pourcentages, et vérifiez le résultat par rapport à ce que le beat est censé montrer. Lorsque la conséquence d'une action se produit ailleurs que sur la cible — la destination d'un glisser-déposer, un champ qui se met à jour ailleurs — pointez zoom_target vers la conséquence, pas sur ce que le curseur a touché.

Couleurs : jamais dans le plan, jamais dans un composant

theme.ts est généré par apply-palette.mjs à partir de palette.json. C'est le seul endroit où une couleur est écrite.

node pitchframe/scripts/extract-palette.mjs      # → palette.json
node pitchframe/scripts/apply-palette.mjs        # → src/theme.ts

Règles qui en découlent :

  • Ne mettez jamais une couleur dans plan.json. Le plan dit quel mot est accentué ; le thème dit ce qu'est l'accent.
  • Ne mettez jamais une couleur littérale dans un composant. Si vous avez besoin d'une nuance que le thème n'expose pas, ajoutez un jeton dérivé au générateur pour que chaque future vidéo l'obtienne aussi.
  • Ne modifiez jamais theme.ts à la main. Il est écrasé à la prochaine génération.

Si les vidéos de deux produits semblent identiquement colorées, theme.ts n'a pas été régénéré. C'est la première chose à vérifier, avant de toucher à quoi que ce soit d'autre.

Le rendu

cd pitchframe && npx remotion render LaunchVideo output.mp4

Trois vérifications d'abord, coûtant une seconde et économisant un rendu échoué de deux minutes :

  1. plan.json s'analyse ; l'arithmétique ci-dessus tient.
  2. Chaque capture d'écran nommée dans le plan existe dans public/assets/. Un beat interaction nécessite à la fois before_screenshot et after_screenshot.
  3. node_modules existe dans pitchframe/. Sinon, exécutez npm install d'abord.

Attendez-vous à 20–60 secondes pour une vidéo de 20 secondes.

Lorsque le rendu échoue

Lisez l'erreur réelle avant de modifier quoi que ce soit.

SymptômeCauseCorrectif
Cannot find module '../plan.json'Échafaudage incompletRéexécutez npx pitchframe install
Cannot find name 'ACCENT' etc.theme.ts non généréExécutez apply-palette.mjs
Délai de rendu sur les policesHors ligne, ou une police pas sur Google FontsDéfinissez fonts.sans sur Inter dans palette.json et régénérez
Erreur de décodage d'imageCapture d'écran corrompue ou partielleRecapturez cette image
Incohérence de durée de compositiontotal_frames en désaccord avec les beatsCorrigez l'arithmétique
OOM / Plantage de ChromeCaptures d'écran énormesRéduisez tout ce qui dépasse ~4000px de large ; --concurrency=2

Ne répondez jamais à un échec de rendu en réécrivant la composition. Corrigez les données.

Si le rendu échoue deux fois, arrêtez et conservez les preuves. Laissez plan.json, palette.json et les actifs en place et dites quel fichier regarder. Un rendu échoué avec un plan inspectable est récupérable ; un rendu qui a été "corrigé" par une réécriture ne l'est pas.

Quand vous devez vraiment toucher aux composants

Uniquement lorsque le plan nécessite quelque chose que les composants beat ne peuvent vraiment pas exprimer. Trois règles si vous y arrivez :

  1. Ajoutez, ne réécrivez jamais. Un nouveau mouvement de caméra est une entrée dans SHOTS dans lib/camera.ts, pas un composant restructuré — et il doit être listé dans pitchframe-motion-language sinon rien ne le choisira jamais.
  2. Utilisez lib/motion.ts et lib/camera.ts. EASE, EASE_OUT, clickPulse, heldDrift, entranceBlur sont le genre. Un easing fait maison est ainsi qu'un beat finit par ressembler à une vidéo différente. Les ressorts, rebonds et courbes élastiques sont interdits. Il y a exactement un système de caméra. N'ajoutez pas de perspective ou de transformation 3D en dehors de Stage.tsx ; ce dépôt en avait deux autrefois, ils ont dérivé, et les plans ont cessé de ressembler à ceux filmés par la même personne.
  3. Gardez-le piloté par les données. Tout ce que vous ajoutez doit être accessible depuis un champ dans plan.json. Si la seule façon de le déclencher est de modifier le composant, c'est un cas unique et il n'a pas sa place dans la référence.

Toujours faux ici : une couleur littérale ; le nom ou le texte du produit codé en dur dans un composant ; une nouvelle composition de premier niveau ; changer le contrat 1920×1080 / 30fps ; importer une bibliothèque d'animation.

Ajouter un type de beat est presque toujours la mauvaise réponse. Le schéma en a quatre car une vidéo de lancement en a besoin de quatre. Un nouveau type de beat est généralement un beat fonctionnel déguisé, et dès que le schéma peut exprimer une liste de fonctionnalités, les plans commencent à en contenir une.

Après un rendu réussi

Signalez le chemin et l'affordance d'édition :

Terminé. Vidéo prête dans ./pitchframe/output.mp4

Pour éditer, demandez simplement :
  "tiens le moment héroïque plus longtemps"
  "zoome sur le champ qui a changé à la place"

L'édition est gérée par pitchframe-editing, pas en réexécutant le pipeline.

Skills associés