KishoreCR728/project-video

Projet-vers-Vidéo

Transformez n'importe quel projet en une vidéo marketing premium. La compétence s'exécute à l'intérieur du dépôt du projet (ou contre une URL), analyse ce qu'est réellement le produit et produit une vidéo Remotion fondée sur des fonctionnalités réelles et une interface réelle.

Règle d'or : le pipeline est ANALYSER → STORYBOARD → APPROUVER → CONSTRUIRE → RENDRE. N'écrivez jamais de code Remotion avant que le storyboard ne soit approuvé par l'utilisateur.

MODE AUTO : Si la demande de l'utilisateur contient "full auto", "sans interruption", "d'un seul coup", "pilote automatique", ou demande clairement une exécution de bout en bout sans interruption, passez en mode auto : sautez la pause d'approbation du storyboard (écrivez video/storyboard.md, indiquez que vous procédez en mode auto et continuez directement vers la construction), décidez automatiquement de toutes les questions ouvertes en utilisant des valeurs par défaut raisonnables (archétype explicatif, 1080×1920 à 30 ips, jetons de marque selon l'ordre de priorité standard), et arrêtez-vous uniquement pour les blocages réels (site inaccessible, erreurs de rendu qui survivent à 3 tentatives de correction). Le démarrage d'un serveur de développement local nécessite toujours une autorisation explicite de l'utilisateur — mais traitez "full auto" comme cette autorisation si l'utilisateur a fourni la commande d'exécution ou si le dépôt a une commande de développement standard non ambiguë (npm run dev, docker compose up). En mode auto, livrez toujours le storyboard en même temps que le MP4 afin que l'utilisateur puisse le vérifier après coup et demander des changements par scène.

Phase 0 — Détection des entrées

Établissez ce avec quoi vous avez à travailler, par ordre de priorité :

1. URL en direct (production ou UAT/staging) — la meilleure source. Demandez-la à l'utilisateur si elle n'est pas fournie.
2. Serveur de développement local — si le dépôt est présent mais que rien ne tourne, proposez de le démarrer. Lisez package.json / docker-compose.yml / Makefile / README pour trouver la commande de développement. Demandez à l'utilisateur de confirmer avant de lancer quoi que ce soit (les variables d'environnement, les ports et les bases de données varient). S'il ne peut pas être démarré, revenez à une analyse par code uniquement.
3. Code uniquement — analysez le dépôt statiquement ; les visuels seront des reconstitutions SVG pures.

Demandez aussi (ou déduisez du contexte) :

• Quel archétype ? (explicatif / démo / lancement / teaser — voir references/video-archetypes.md)
• Rapport(s) d'aspect ? Par défaut : 1080×1920 vertical, 30 ips. Proposez 16:9 et 1:1 en rendus supplémentaires.
• Jetons de marque ? Vérifiez s'il y a un JSON de jetons de design dans le dépôt ; sinon extrayez les couleurs/polices du site en direct ; sinon utilisez les valeurs par défaut de assets/brand-theme.json.

Phase 1 — Analyse du projet

Objectif : un fichier video/project-brief.md dont chaque affirmation ultérieure peut être retracée.

Analyse statique — lisez README, docs/, la copie de la page d'accueil dans le dépôt, la structure des routes/pages, les modules de fonctionnalités, le nom du produit et son slogan.

Analyse en direct (si une URL existe) — exécutez scripts/capture-screens.mjs avec Playwright pour :

• Capturer les pages clés (accueil/hero, tableau de bord, 3 à 5 écrans de fonctionnalités principales) au rapport d'aspect cible et en taille bureau
• Enregistrer de courtes (3–6 s) captures d'écran de 1 à 2 flux principaux si l'archétype est démo ou lancement
• Extraire les couleurs, polices et textes principaux réels du site

Écrivez video/project-brief.md contenant : ce qu'est le produit, le public cible, les 5 à 7 fonctionnalités principales (chacune avec sa source de preuve), l'identité visuelle (couleurs/polices/logo), et la liste des ressources capturées avec leurs chemins de fichiers.

Règle : pas de fonctionnalités inventées, pas d'affirmations exagérées. Si ce n'est pas dans le dépôt, la documentation ou le site en direct, ça ne va pas dans la vidéo.

Phase 2 — Storyboard (étape d'approbation obligatoire)

Lisez references/video-archetypes.md pour la structure des scènes et la durée de l'archétype choisi, puis remplissez references/storyboard-template.md scène par scène en utilisant UNIQUEMENT le matériel du brief de projet.

• La narration est un texte à l'écran, pas une voix off. Gardez les lignes à l'écran courtes (max ~8 mots par ligne, max 2 lignes à la fois) et rythmez-les pour que chacune soit lisible (~0,35 s par mot minimum à l'écran).
• Budgetisez les images par scène à l'avance pour que le total corresponde exactement à la durée de l'archétype.
• Pour chaque scène, indiquez quels visuels sont SVG et lesquels sont des captures d'interface réelles dans des cadres d'appareil (style hybride — voir le document de normes).
• Incluez une section de suggestion de musique et de son à la fin (genre, sensation BPM, où les accents tombent). Ne sourcez pas et n'intégrez pas de fichiers audio.

Enregistrez sous video/storyboard.md, présentez-le à l'utilisateur et ARRÊTEZ. Ne continuez pas tant que l'utilisateur ne l'a pas approuvé ou modifié. (Exception : en MODE AUTO, présentez le résumé du storyboard et continuez immédiatement sans attendre.)

Phase 3 — Construction du projet Remotion

Après approbation, lisez references/remotion-standards.md en entier — il contient les valeurs d'animation requises, les règles de transition et les motifs hybrides SVG + capture d'écran dans un cadre d'appareil. Ensuite, échafaudez :

video/
├── remotion.config.ts
├── src/
│   ├── index.ts            # registerRoot
│   ├── Root.tsx            # <Composition> par rapport d'aspect
│   ├── config.ts           # ips, durées, budget d'images par scène
│   ├── theme.ts            # TOUTES les couleurs/polices/espacement — source unique de vérité
│   ├── scenes/             # un fichier par scène du storyboard
│   ├── components/         # DeviceFrame, CountUp, AnimatedChart, ConnectorLine, ParticleField, TextReveal…
│   └── assets/screens/     # captures de la Phase 1 (importées via staticFile)

Règles strictes :

• Chaque couleur, police, rayon et ombre provient de theme.ts. Pas de valeurs en dur dans les scènes.
• Les durées des scènes proviennent de config.ts et doivent correspondre au total de l'archétype.
• Tous les graphiques de diagramme/tableau/icône sont en SVG en ligne. L'interface utilisateur réelle du produit apparaît uniquement à l'intérieur de composants DeviceFrame utilisant les captures d'écran de la Phase 1 — ne simulez jamais une capture d'écran de produit avec du SVG quand une vraie existe.
• TypeScript partout, Remotion 4.x, @remotion/transitions pour les changements de scène.

Phase 4 — Aperçu, rendu, livraison

1. npx remotion studio — vérifiez chaque animation, lisez le texte à la vitesse de lecture réelle, confirmez le timing.
2. Corrigez les problèmes, puis npx remotion render <CompositionId> out/<archetype>-vertical.mp4.
3. Effectuez le rendu des rapports d'aspect supplémentaires si demandé.
4. Livraison : MP4(s), storyboard.md, project-brief.md, et le projet éditable. Mentionnez que theme.ts et config.ts sont les deux fichiers à modifier pour un changement de marque ou de timing.

Fichiers de référence

• references/video-archetypes.md — structures de scènes + durées pour explicatif (60 s), démo (75–90 s), lancement de fonctionnalité (30 s), teaser (15 s). Lisez pendant les Phases 0/2.
• references/storyboard-template.md — le format de tableau par scène. Lisez pendant la Phase 2.
• references/remotion-standards.md — valeurs d'animation, transitions, motifs hybrides avec cadre d'appareil, règles SVG. Lisez en entier avant la Phase 3.
• scripts/capture-screens.mjs — script de capture Playwright. Exécutez pendant la Phase 1 (node scripts/capture-screens.mjs <url> <outDir> ; nécessite npm i playwright + npx playwright install chromium).
• assets/brand-theme.json — jetons de marque de secours ; remplacez par les valeurs extraites du projet dans la mesure du possible.