git2video — vidéo de release à partir de l'historique Git réel
Lit l'historique Git réel d'un dépôt et produit une vidéo de release précise et soignée :
collecter → storyboard → valider → rendre → QA → livrer. Fonctionne 100% localement
(Node ≥ 22, ffmpeg, Playwright Chromium — vérifier avec doctor d'abord).
Pas de réseau au moment du rendu ; les secrets sont nettoyés des fragments de diff ; les emails
n'apparaissent jamais dans la sortie.
skills/git2video/scripts/doctor.mjs # vérifier l'environnement, corriger les lignes MANQUANTES
scripts/collect.mjs # git -> story.json (commits groupés, ruptures, statistiques, fragments nettoyés)
scripts/validate.mjs # le storyboard sans audio doit passer avant le rendu
scripts/render.mjs # storyboard -> video.mp4 (+ webm/gif), layout-audit.json
scripts/qa.mjs # porte scriptée : report.json + report.md dans out/qa/
references/storyboard-guide.md # types de scènes, formes de données, règles d'écriture — lire avant d'écrire
references/faq.md # dépannage
Flux de travail
1. Collecter l'historique.
node skills/git2video/scripts/collect.mjs --repo <répertoire-du-dépôt> --out /tmp/g2v/story.json \
[--from <tag|sha|AAAA-MM-JJ>] [--to HEAD] [--max-commits 400] [--include-contributors] [--gh]
Valeurs par défaut : dernier tag → HEAD ; aucun tag : derniers 30 jours. Lire /tmp/g2v/story.json après.
2. Écrire storyboard.json (vous, l'agent — lire references/storyboard-guide.md d'abord). Règle générale pour une vidéo de release de 30–45 s :
titre (3–4 s) → points forts (5–8 s) → diff (5–8 s) → statistiques (4–5 s) →
avancement (optionnel 4–6 s) → ruptures (3–5 s, seulement si présentes) →
contributeurs (3–5 s, seulement avec --include-contributors) → conclusion (3–4 s)
Chaque scène contient : id, type, duration (0.8–15 s), narration
(≤ 2 phrases ; lisible dans le créneau à 0,35 mot/s), source (SHA des commits
qui appuient les affirmations), data (spécifique au type — formes dans le guide). Les affirmations doivent
remonter à story.json — n'inventez rien.
3. Valider.
node skills/git2video/scripts/validate.mjs --storyboard /tmp/g2v/storyboard.json \
--story /tmp/g2v/story.json
Corrigez chaque erreur avant de rendre. Élargissez la fenêtre de durée totale pour une démo avec
--min/--max uniquement si l'utilisateur a demandé un court clip de test.
4. Rendre.
node skills/git2video/scripts/render.mjs --storyboard /tmp/g2v/storyboard.json \
--out /tmp/g2v --preset 16:9 --fps 30 --theme dark [--formats mp4,webm,gif]
Préréglages : 16:9@1920, 9:16@1080, 1:1@1080. Thèmes : dark (par défaut), light, neon. Les rendus sont déterministes sur une machine ; ~2–4 min pour une vidéo 40 s à 30 ips. v0.1 est silencieux : la narration est incrustée automatiquement en sous-titres.
5. QA (scripté, pas subjectif).
node skills/git2video/scripts/qa.mjs --storyboard /tmp/g2v/storyboard.json --out /tmp/g2v
Lire out/qa/report.md. RÉUSSI → livrer. ÉCHEC → regarder les détails dans report.json, corriger le storyboard, re-rendre, relancer la QA. Maximum 3 boucles de correction. Après cela, rapporter honnêtement ce qui échoue encore et pourquoi.
6. Livrer. Informer l'utilisateur : le chemin absolu de video.mp4 (+webm/gif), le verdict
QA en une ligne, les éventuels reliquats de la 3e boucle, et proposer : un autre préréglage (vertical),
des variantes de thème (light/neon), ou un GIF pour intégration dans le README (--formats gif).
Règles strictes
- N'inventez jamais de commits, statistiques ou diffs : le
sourcede chaque scène nomme des SHA réels de story.json. Si l'historique ne prend pas en charge un type de scène, sautez la scène. - Ne mettez jamais les emails des contributeurs dans la sortie ; seulement les noms avec --include-contributors.
- Ne modifiez pas les fichiers sous skills/git2video/templates/ ou scripts/ en cours de rendu ; le moteur déterministe + la QA les présupposent. Les changements de scènes/thèmes/éléments visuels ne se font que dans le cadre d'un travail séparé et déclaré.
- Préférez des scènes moins nombreuses mais précises plutôt que du remplissage ; gardez la narration ≤ 2 phrases.