Communitygithub.com

pj1433139082-hue/video-design-skills

Génère des vidéos MP4 avec Remotion à partir d'un système de conception vidéo (DESIGN.md). Utilisation obligatoire lorsque l'utilisateur, après avoir effectué remotion-consult ou obtenu le DESIGN.md, demande de "générer une vidéo", "créer une vidéo", "rendre une vidéo", "réaliser la vidéo selon DESIGN.md" ou "produire un MP4". Piloté par les sous-titres : les timestamps .srt sont alignés précisément à la trame ; les animations sont sélectionnées dans la bibliothèque d'animations globale ; les assets sont routés via le système multi-harness. Par défaut, seulement rapporter, sans modifier unilatéralement la direction du design.

Qu'est-ce que video-design-skills ?

Ce skill est conçu pour générer automatiquement des vidéos MP4 à l'aide de Remotion, en se basant strictement sur un cahier des charges (DESIGN.md) issu de la phase de conseil (remotion-consult). Il est impératif de l'utiliser dès que l'utilisateur exprime le besoin de créer ou de rendre une vidéo. Le processus est entièrement piloté par les sous-titres : le fichier .srt constitue l'unique timeline de la vidéo. Chaque phrase des sous-titres est alignée trame par trame pour garantir une synchronisation parfaite, et les animations sont importées depuis une bibliothèque d'effets commune. Le skill prend en charge plusieurs modes de travail : l'utilisation de modèles par catégorie (voice-over, data-viz, démo produit, animation de marque), l'inspiration à partir de vidéos de référence, la conception libre avec des garde-fous anti-slop, ou le suivi exact d'un DESIGN.md existant sans redemander la direction créative. Il propose également deux backends de rendu au choix : Remotion (par défaut, pour des animations React complexes) et HyperFrames (basé sur HTML/GSAP, pour un rendu plus proche du développement web). L'une des particularités majeures est l'étape obligatoire de synthèse vocale (TTS) et de reconstruction du .srt en fonction des durées réelles des fichiers audio, avant même l'extraction des trames pour la validation. Un processus de validation rigoureux en plusieurs étapes (analyse de composition, contraste, alignement audio, respect des contraintes esthétiques via des audits spécialisés) est intégré pour garantir la qualité du rendu final. Les règles strictes incluent l'interdiction de modifier la direction créative définie dans le DESIGN.md et de générer des données fictives. Des dizaines de fichiers de référence audio, vidéo, et de design sont disponibles pour guider chaque étape, de la construction à la livraison.

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/pj1433139082-hue/video-design-skills/tree/HEAD/skills/remotion-build

Demander à votre IA préférée

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

Documentation

remotion-build — Générer une vidéo Remotion

Génère un MP4 à l'aide de code React basé sur DESIGN.md (résultat de remotion-consult). Les sous-titres sont l'unique timeline ; les animations sont importées depuis la bibliothèque d'animations globale ; les assets sont routés via le système multi-harness.

Workflow

Étape 0 — Sélection du mode (choisir parmi quatre, décider avant d'agir)

  1. Modèle par catégorie : L'utilisateur souhaite un style prédéfini, ou choisit parmi les quatre catégories de remotion-shared/categories/ (voice-over avec sous-titres / data visualisation / démo produit / animation de marque) → Lire le DESIGN.template.md + motion-list.md de cette catégorie, hériter du système de design en ne changeant que le contenu et les sous-titres.
  2. Inspiration à partir d'une référence : L'utilisateur fournit une vidéo de référence (priorité la plus élevée) ou choisit parmi remotion-shared/video-real-library.md → Décomposer son style de sous-titres, ses transitions, son rythme, et le reproduire avec les composants de la bibliothèque d'animations globale.
  3. Conception libre : Ni référence, ni modèle → Se contenter d'éviter les instructions négatives de video-anti-slop.md.
  4. Suivre un DESIGN existant (résultat de remotion-consult) : Le DESIGN et les échantillons de style sont déjà validés → Suivre strictement les tokens/§8 du DESIGN, ne plus redemander la direction stylistique (l'étape 0.5 se limite à aligner les critères d'acceptation, sans répéter la phase 1 de clarification).

En cas d'incertitude, lister les options à l'utilisateur.

Choix du backend de rendu (cinquième dimension, annoté dans le DESIGN) : En plus des quatre modes ci-dessus, déterminer le backend de rendu (par défaut, ce skill utilise le backend Remotion ; utiliser le backend HyperFrames uniquement si le DESIGN le spécifie ou si l'utilisateur le demande explicitement) :

  • Backend Remotion (par défaut) : Animations React complexes / plans caméra type shotcraft / src/ structuré en couches + Sequence + useCurrentFrame. À utiliser lorsque la plus grande liberté d'animation est requise.
  • Backend HyperFrames (optionnel, basé sur le HTML→MP4 open source de HeyGen) : Attributs de données index.html + timeline GSAP (npx hyperframes init/render, gratuit en local) → Plus proche du développement web, avec npm run check intégré (lint + contraste + mouvement). Les assets, BGM, sous-titres et la validation sont entièrement réutilisés ; seule la méthode de rendu change. Règles dans references/hyperframes-guide.md.
  • Critère de choix : Plans caméra complexes (retournement, particules, 3D) ou projet Remotion existant → Remotion ; anims HTML/GSAP pures, sensation de développement web, lint intégré souhaité → HyperFrames. Ne pas mélanger les deux backends dans un même projet.

Étape 0.5 — Alignement des besoins + Critères d'acceptation (grill-me, obligatoire, ≤ 10 tours)

Exécuter le skill grill-me pour aligner : besoin en une phrase, format/durée/plateforme, source des sous-titres (.srt/.vtt/script de voice-over/à partir de zéro), mode, direction stylistique. Doit produire les quatre catégories de critères d'acceptation :

  • Structure : Catégorie/format/durée/fps
  • Visuel : Police des sous-titres/palette/composition cohérente avec DESIGN.md ou la référence (en mode libre, "pas de look IA")
  • Contenu : Toutes les phrases des sous-titres présentes, sans fautes, timestamps couvrant toute la vidéo, texte authentique
  • Technique : Alignement trame des sous-titres (trames de début et fin de phrase existantes), extraction still réussie, rendu MP4 réussi

Si non aligné après 10 tours → Enregistrer les points en suspens et passer à la construction malgré tout.

Étape 1 — Workflow piloté par les sous-titres (cœur)

Selon references/captions-guide.md :

  1. Routage de la source : .srt/.vtt existant → utilisation directe ; script de voice-over .md existant → rédiger un brouillon .srt ; à partir de zéro → d'abord un brouillon de script de voice-over, puis .srt.
  2. parseSrt({input}) → Caption[], valider les segments vides/chevauchlements temporels/dépassement.
  3. Alignement trame : startFrame = Math.round((startMs/1000)*fps) , endFrame = Math.round((endMs/1000)*fps) , chaque phrase <Sequence from={startFrame} durationInFrames={endFrame-startFrame}>.
  4. Surlignage mot/phrase : createTikTokStyleCaptions → composant CaptionLayer ; pour le chinois, phrase entière en un seul token → dégradation au niveau phrase (décision par DESIGN.md highlightMode).
  5. Le rythme visuel est lié au startMs de la première phrase du sous-titre ; durée totale de la vidéo durationInFrames = round(max(endMs)/1000*fps) + trailing.
  6. Après modification des mots, serializeSrt pour réécrire.

Étape 1.5 — Reconstruction du srt pilotée par le voice-over (hypothèse temporelle vraie, implémenter d'abord le voice-over, puis extraire les trames)

Le voice-over est un flux obligatoire pour les vidéos de type "parlé" (ne pas demander à l'utilisateur) : Génération TTS → Mesure réelle avec ffprobe → Reconstruction du srt pour définir la timeline, la chronologie est basée sur les mesures TTS réelles (l'hypothèse temporelle §4 du DESIGN est vraie). Voice-over d'abord, extraction des trames ensuite – pour éviter que l'alignement srt de l'étape 1 soit invalidé par la reconstruction du voice-over, rendant les premières étapes inutiles.

  1. python scripts/media/tts_gen.py --provider edge-tts --lines lines.txt --save-dir public/audio/ --voice <voice> (par défaut, fonctionne sans clé API ; lorsque MiniMax est disponible, changer explicitement en --provider minimax ; pour le TTS cloud en Chine, voir mmx-media-pipeline.md §2).
  2. Mesure ffprobe de la durée de chaque phrase (ffprobe -show_entries format=duration), intervalle de 0,8s de respiration entre les phrases.
  3. Reconstruction du srt (rebuild_srt.py) : chaque début/fin de phrase = cumul des durées réelles + respiration ; écrire dans public/captions.srt.
  4. Les intervalles de trames SHOTS racines sont mis à jour en fonction du nouveau srt (round(ms/1000*fps)), chaque Sequence est associée à <Audio src={staticFile("audio/s{n}.mp3")}>.
  5. BGM : Si aucune musique générée par IA n'est nécessaire, utiliser un asset de la bibliothèque d'assets sous licence ; si une génération par IA est nécessaire, utiliser par défaut la génération locale ACE-Step, avec le backend musical cloud comme alternative. Après acquisition, couper à la durée totale (ffmpeg -t en secondes vidéo), volume bas pour ne pas couvrir le voice-over (0,22-0,3).
  6. Budget trame par scène + pré-vérification du timing de scène (pour éviter "l'animation clé n'apparaît pas", expérience personnelle : 3 occurrences) : Le to-from de chaque phrase sortie par rebuild_srt est le budget trame de cette scène. Avant d'écrire un plan caméra ou une animation de données, vérifier : la dernière image clé à l'intérieur du plan ≤ budget de la scène, sinon compresser le timing du plan (ne pas attendre la validation pour s'en rendre compte) :
    • Phrases courtes (2-3s ≈ 60-90 trames) : les animations de queue (tampon, cercle, cycle de points lumineux) sont les plus susceptibles de dépasser le budget (le tampon rouge S2 était initialement de 70-88 trames, dépassait les 68 trames de la phrase → compressé à 55-65 ; le cycle de points S6 était initialement de 46-70, dépassait les 70 trames → compressé à 46-64 ; le balayage en 5 cercles S9 était initialement de 136 trames, dépassait les 128 trames de la phrase → compressé à 108).
    • Règle : Dernière image clé du plan = Début + Durée totale en cascade + Fin figée , doit être ≤ budget de la phrase ; si dépassement, compresser proportionnellement le décalage (stagger)/la durée individuelle, conserver une fin figée ≥ 4 trames.

Étape 2 — Trouver une référence

Priorité la plus élevée si l'utilisateur fournit une référence → video-real-library.md → Conception libre. Si une référence existe, utiliser la "méthode de décomposition des animations" (référence → combinaison de composants de la bibliothèque d'animations globale, voir motion-patterns-video.md).

Étape 3 — Instructions négatives (version condensée vidéo, unique contrainte dure)

  • Ne pas utiliser le même rythme de sous-titres tout au long (chaque phrase de même longueur, surlignage mot uniforme sans variation)
  • Ne pas centrer chaque scène avec la même composition, n'utiliser que des fondus ou que des coupes franches
  • Ne pas couper uniformément toutes les N secondes (pas de sensation de respiration)
  • Ne pas utiliser un arrière-plan par défaut avec un dégradé violet-indigo, ne pas utiliser des polices IA génériques
  • Ne pas utiliser de sous-titres creux de type "Bienvenue" ou "Commençons"
  • Les animations sont obligatoires : Chaque scène doit avoir au moins une animation d'entrée + une transition entre les scènes
  • Point final.

Étape 4 — Construction (base technique)

Selon references/remotion-build-guide.md :

  • Initialisation du projet : Copier le squelette depuis _dev/remotion-tutorial + npm i @remotion/captions@<version alignée> + conserver le chemin Chrome.
  • Importer les composants depuis la bibliothèque d'animations globale (工作台/视频/_动效库/) ou les copier dans src/components/.
  • Intégration optionnelle de plans caméra : Si le DESIGN §8.2 choisit des plans, suivre les "étapes d'intégration des plans caméra" de remotion-shared/video-shots-spec.md (incluant les marqueurs d'intention [copy]/[借思路]) ; pour les vidéos en chinois, par défaut, emprunter l'idée sans copier directement.
  • Structure src : Root.tsx / theme.ts / captions.ts / components/ .
  • Animations déterministes (useCurrentFrame/interpolate/spring, interdire Math.random et les minuteries navigateur).
  • Si DESIGN.md existe, suivre strictement les tokens.
  • Les assets sont routés via le système multi-harness selon references/video-image-spec.md (Codex image_gen / aller-retour des instructions GPT / image fournie par l'utilisateur).
  • Re-validation du plan après génération des assets (obligatoire) : Une fois les assets générés, vérifier phrase par phrase par rapport au plan §8 du DESIGN : ① L'image correspond-elle au sens/à la mise en page de la phrase (évaluation vision de la pertinence, <7 → régénérer ou ajuster le prompt) ② Les mots-clés en grand sont-ils coordonnés avec l'image de la scène, sans occlusion ③ L'ordre Z des couches respecte-t-il la conception du plan. Si non-conformité → Ajuster les mots-clés ou régénérer l'asset, ne pas "générer et utiliser directement" ; pour chaque élément visuel, sélectionner le meilleur parmi plusieurs candidats.

Étape 5 — Boucle de validation (Table des nœuds grill-me)

NœudDéclencheurLimite de toursCondition de sortie
DébutÉtape 0.510 toursCritères d'acceptation finalisés
ModificationDemande de changement de l'utilisateur5 tours/foisSavoir quoi changer, vérifier chaque tour par rapport aux critères d'acceptation
FinalAvant livraison4 toursVérifier chaque critère d'acceptation un par un

Actions de validation obligatoires (extraire les trames d'abord, rendre ensuite, pour éviter un long rendu inutile) : Quantification en couches (4 couches, effectuée sur les trames clés de preuve §8.2 du DESIGN = début/phrase/état final 0,82):

  • Couche 1 Image de fond (l'image de scène elle-même) : python scripts/media/layout_calc.py <image_scene> — composition/espaces vides/zone de texte recommandée (trouver les zones vides selon la structure des espaces vides de l'image, ne pas forcer un haut pur ; si le haut est envahi → déplacer le texte vers la zone suggérée text_zone, ou régénérer une image plus propre).
  • Couche 2 Image de fond + texte (still avec texte) : Point d'atterrissage du texte de layout_calc + frame_judge --subtitle-hex pour un vrai contraste WCAG (grand texte ≥3.0 / corps de texte ≥4.5).
  • Couche 3 + Animation (trames consécutives) : Différence de trame/vision des trames consécutives pour juger que l'animation se produit réellement + l'animation ne chevauche pas la scène (si le plan est une image complète, ne pas le superposer comme une image de fond de scène ; voir les modes visuels §8.2).
  • Couche 4 Ensemble (vidéo finale) : frame_judge entier + audio_sync_check.py synchronisation audio-vidéo + vérification d'occlusion + score des quatre compétences + preuve d'action.
  1. npx remotion compositions pour vérifier le véritable id.
  2. Extraction still de 3 à 5 trames (début de phrase/fin de phrase/trame de transition) — extraire les "trames d'état final" pas pendant l'animation (leçon apprise le 2026-08-17) : Choisir les trames après la fin de l'action (état final 0,82 / après la fin figée), ne pas extraire pendant l'animation en cours — les trames intermédiaires pourraient faire croire à tort à "une absence/statique/un cadre noir" par la vision humaine (S2 retournement sans tampon rouge, S6 compteur en roulement sans point cyclique, S7 ligne de temps sans portrait, c'était une erreur de moment d'extraction ; extraire les trames d'état final est correct). Les sous-titres sont présents et alignés, la composition n'est pas brisée.
  3. Vérification de l'alignement des sous-titres : Le sous-titre est déjà apparu à la trame de début de phrase, ne disparaît pas prématurément à la trame de fin.
  4. Évaluation automatisée des indicateurs stricts : Après extraction, exécuter python scripts/media/frame_judge.py preview/*.png --subtitle-hex <couleur_sous_titre_DESIGN, ex: E8833A> --subtitle-threshold 3.0 --text-bg-hex <couleur_fond_capsule_texte, ex: F2F0EB> ( --text-region si le texte est dans un coin, passer la position réelle tl/tr/bl/br/center, pour éviter les faux positifs en bas ; --text-bg-hex si le fond de la capsule est connu, calculer directement le vrai contraste sous-titre vs fond, en sautant le mode — le mode capture la couleur de la scène, n'est pas précis lorsque le texte se superpose à la scène ; seuil pour grand texte 3.0 / corps de texte 4.5 ; tout FAIL déclenche une révision) ; optionnellement pip install iqa-pytorch puis ajouter le score esthétique NIMA (>6,5 pour référence) ; seuils des indicateurs dans references/video-quality-metrics.md ; l'échec de la luminosité pour un design sombre ne bloque pas (voir la section design sombre des métriques, se fier au contraste).
  5. Pour chaque trame extraite, vérifier la checklist (note <3 déclenche une révision) :
    • Composition : ≥2 éléments visuels, pas centré à chaque scène, ordre Z correct (bg/mid/fg).
    • Sous-titres : Présents et alignés, lisibles (contraste ≥3:1), pas de texte brisé.
    • Transition : Transition/animation d'entrée entre les phrases, pas de coupure nue ou de statique.
    • Assets : Pas de caractères IA erronés, couches conformes à §8.1, superposition transparente propre.
    • Animation : Au moins 2 types d'animations présentes (entrée/sortie des assets + police + fond, choisir deux parmi trois), le fond doit avoir une animation.
    • Pas de look IA : Vérifier les instructions négatives de video-anti-slop.md.
  6. Vérification d'occlusion + vérification du mode visuel (s'inspirer de paper-collage-video spatial-contract, extension 2026-08-16) : Vérifier phrase par phrase sur les trames extraites — ① La capsule de grand texte est dans la zone réservée (espace vide en haut) ② Le sujet principal ne chevauche pas la zone de grand texte/sous-titres ③ Le premier plan ne cache pas le sujet de l'arrière-plan intermédiaire ④ L'animation du plan ne chevauche pas l'image de scène : Un plan d'image complète (compteur, cadran, colonne de particules, champ sombre focalisé) ne doit jamais être superposé comme une image de fond de scène (choisir un mode visuel parmi trois, voir §8.2 du DESIGN) ⑤ Le sens de l'animation résonne avec le sens de la phrase (la vision juge ce que la colonne de particules, le balayage lumineux, le défilement de chiffres expriment dans cette scène et si cela correspond au sens du voice-over ; si le sens est flou, déclencher une révision). Occlusion/sens flou → Modifier le mode visuel ou supprimer les plans superflus.
  7. Porte d'entrée stricte de l'examen des quatre compétences (si une porte n'est pas passée → révision, pas simple référence) : Exécuter avec des sous-agents indépendants (hallmark/taste exécutés par un agent indépendant, pas par le modèle principal qui s'auto-évalue) :
    • taste-skill Pre-Flight (40+ vérifications de goût).
    • hallmark audit (57 portes anti-AI slop).
    • ui-ux-pro-max (Règles UX : lisibilité/hiérarchie/cohérence).
    • open-design/anti-ai-slop (Les "sept péchés capitaux" pour enlever les templates). Vérifier les trames extraites/la vidéo finale, donner un score sur le nombre d'items réussis pour autoriser (évaluation complémentaire, pour éviter l'auto-évaluation) : hallmark 57 portes passées ≥90% (≥51 items) pour autoriser ; taste 40+ items passés ≥85% pour autoriser ; ui-ux-pro-max / open-design tous les items clés passés ; lister les items non passés qui déclenchent une révision, une fois toutes les portes passées, rendu et livraison.
  8. npx remotion render <id> out/final.mp4.
  9. Moment de preuve d'action (s'inspirer de paper-collage-video proof moments) : Selon §8.2 du DESIGN, pour chaque phrase, extraire les trames de preuve (début/milieu/état final 0,82) + vérifier que le type d'action s'est réellement produit (entrée déjà effectuée/en cours/en fin figée) ; ffmpeg -vf "fps=4" pour extraire des trames consécutives → la vision juge que l'action se produit selon le DESIGN — une trame statique d'une image n'est pas une preuve d'action (particules/focalisation/chiffres doivent être confirmés par des trames consécutives) ; transitions fluides/entrées-sorties sans à-coups (video-quality-metrics §4.6).
  10. Vérification de la synchronisation audio-vidéo (axe principal des vidéos de type "parlé", évaluation complémentaire) : Sur la vidéo finale, exécuter python scripts/media/audio_sync_check.py out/final.mp4 public/captions.srt — pour chaque début de phrase du srt ±0,15s, il doit y avoir un son de voice-over (RMS≥0,01) ; silence au début de la phrase = décalage/donnée manquante/coupure de fin de phrase → révision.
  11. Vérifier chaque critère d'acceptation un par un → STATUS PASS/FAIL/BLOCKED, NEXT_OWNER.

Lignes rouges

  • Le pilotage par les sous-titres est une contrainte dure : captions.srt, s'il existe, est l'unique source de la timeline ; la durée en est dérivée.
  • Extraire les trames d'abord, rendre ensuite : Si les stills ne sont pas valides, ne pas rendre la vidéo entière.
  • L'emprunt d'idées pour les plans caméra n'est pas obligatoire : Si le DESIGN §8 choisit des plans, les intégrer (copier shotcraft/demos/{classe}/{plan} et adapter) ; si aucun plan n'est choisi ou pour les vidéos en chinois, emprunter l'idée n'est pas considéré comme une omission ; ne pas avoir intégré de plan n'est pas BLOCKED.
  • Les assets passent par une génération d'image réelle, pas de génération SVG : Les assets principaux sont prioritairement générés par Codex ou via un backend d'image configuré ; la transparence utilise --transparent/remove_white_bg.py.
  • Pour les plans de données programmatiques, copier d'abord la version complète de shotcraft, ne pas écrire de SVG simplifié à la main (leçon apprise le 2026-08-17) : Créer ses propres plans de données (cadrans, cercles, compteurs, graphiques) avec un SVG simplifié fait à la main (cercle/ligne/path nu, sans détails d'échelle, de zone rouge, de moyeu, de halo) est grossier (le ring S9 fait à la main a obtenu un score vision mmx de 3,5/10, contre 8,5/10 après une vraie copie de la version complète NeedleSweepSelftest de shotcraft). Pour les plans de données, toujours copier la version complète depuis shotcraft demos/data, typography (tous les détails d'échelle, primaire/secondaire, halo, moyeu de cadran, aiguille sont inclus), puis les repeindre ; seuls les éléments de décoration simple (taches de lumière de fond, rail de base) peuvent être dessinés par programme.
  • La reconstruction du srt pilotée par le voice-over est obligatoire (Étape 1.5, voice-over d'abord, extraction des trames ensuite) : Pour les vidéos de type "parlé", l'étape 1.5 doit impérativement suivre TTS→ffprobe→reconstruction du srt pour définir la timeline (la chronologie est basée sur les mesures TTS réelles, DESIGN §4), et l'extraction des trames pour la validation se fait après la reconstruction du srt. Ne pas demander à l'utilisateur.
  • Ne pas modifier la direction créative : Si DESIGN.md est défini, le suivre ; pour changer de direction, retourner à remotion-consult.
  • Interdiction de fabriquer : Ne pas inventer de sous-titres ou de données.

Fichiers de référence

FichierQuand le lire
references/captions-guide.mdÉtape 1 Alignement des timestamps des sous-titres (cœur)
references/remotion-build-guide.mdÉtape 4 Normes d'ingénierie
references/motion-patterns-video.mdÉtapes 2/5 Réalisation des animations
references/video-image-spec.mdÉtape 4 Routage des assets
references/codex-imagegen.mdÉtape 4 Lorsque les assets passent par Codex
references/mmx-media-pipeline.mdÉtape 4 Backend média (MiniMax optionnel + chaîne de repli TTS/BGM + pièges connus)
references/video-quality-metrics.mdÉtape 5 Indicateurs d'évaluation automatisée (frame_judge.py + seuils VMAF/NIMA/ASL)
references/hyperframes-guide.mdÉtape 0 Lorsque le backend de rendu = HyperFrames : attributs de données HTML/GSAP/règles check + CLI
references/hyperframes-blocks.mdÉtape 0 Lorsque le backend de rendu = HyperFrames, sélectionner les blocs d'animations : registry 154 blocs consultables par catégorie (équivalent de shotcraft)
.claude/skills/remotion-shared/video-anti-slop.mdÉtape 3 Instructions négatives de base
.claude/skills/remotion-shared/video-tokens-spec.mdLors de l'écriture de theme.ts
.claude/skills/remotion-shared/categories/{catégorie}/motion-list.mdSélectionner une combinaison d'animations
.claude/skills/remotion-shared/video-shots-spec.mdSystème de fiche-recette de plans caméra + techniques faisant autorité (construction, sélection des plans caméra : copier demos/{classe}/{plan} dans le projet)
.claude/skills/remotion-shared/aesthetic-judgment/Étape 5 Validation : Photographie/montage/typographie front-end sur six axes (note <3 déclenche une révision)
.claude/skills/ui-ux-pro-max/SKILL.mdMoteur de règles de design : Étape 4 Consulter les règles UX + priorité lors de la construction
.claude/skills/taste-skill/SKILL.mdÉtape 5 Vérification finale : Pre-Flight 40+ éléments (auto-vérification avant livraison)
.claude/skills/hallmark/SKILL.mdÉtape 5 Audit de design : 57 portes / hallmark audit (avant validation)
资料库/AI工具/design-skills/open-design/craft/anti-ai-slop.mdÉtape 3 Règles anti-template ("sept péchés capitaux") + 151 alternatives de système de design
.claude/skills/design-shared/review-panel.mdPanneau de revue : Perspective agency-agents + base de données des systèmes de design/critères de la bibliothèque de référence esthétique (Étape 5 Notation de validation)

Sortie et clôture

STATUS: PASS | FAIL | BLOCKED
Livrables: chemin out/final.mp4 + chemin preview/ des trames extraites
Critères d'acceptation: Atteint / Non atteint / En suspens pour chaque item
NEXT_OWNER: user (pour voir le rendu) | remotion-consult (pour changer de direction)
En attente de confirmation: Points en suspens

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Skills associés