Le skill qui fabrique mes vidéos : /nouveau-tip

Une commande, une vidéo

Sur ma chaîne, chaque short part d'une fiche : un fichier texte qui décrit le tip, le code montré et le résultat attendu. Pour transformer une fiche en vidéo, je tape une ligne dans Claude Code :

/nouveau-tip JS-TAB-02

Claude vérifie la fiche, exécute le code, construit l'animation, la contrôle, rend le MP4 et prépare les textes de publication. Moi, je regarde la planche d'images de contrôle avant le rendu final.

Au 29 septembre 2026, 267 shorts sont sortis de cette chaîne, mise en place le 18 septembre. JavaScript, PHP, Laravel, CSS, SQL, Git : tous passent par le même gabarit et les mêmes contrôles. La chaîne entière, du sujet à la publication, est le sujet de la formation Ma chaîne de vidéos pilotée par Claude Code.

Ce que contient le skill

Le fichier vit dans le projet, à .claude/skills/nouveau-tip/SKILL.md. Voici son en-tête, tel quel :

---
name: nouveau-tip
description: Produit un short "tip dev" de la chaîne linedev.fr à partir d'une fiche de la roadmap (D:\Stream\Dev\Roadmap) — vérifie la fiche, crée le dossier de production, construit la composition HyperFrames selon Habillage\DESIGN.md, rend le mp4 et prépare les métadonnées Publer. À utiliser pour "produis JS-TAB-02", "fais le prochain tip", "lance la série tableaux". Accepte un ID, plusieurs IDs, ou "suivant".
---

Deux champs seulement. Le name donne la commande /nouveau-tip. La description dit ce que fait le skill, puis cite trois phrases que je dis vraiment. C'est elle qui permet à Claude de le lancer quand j'écris « fais le prochain tip », sans taper la commande.

Le fichier entier fait 76 lignes. Le corps suit l'ordre du travail, une étape par intertitre :

1. Trouver et contrôler la fiche.
2. Créer le dossier de production.
3. Construire la composition.
4. Vérifier avant de rendre.
5. Livrer.

Ce qu'il déclenche

Remarque le premier embranchement. Le skill commence par une vérification qui peut dire non. Voici la section, telle qu'elle est écrite. Dans mes skills, « le client », c'est moi : le texte s'adresse à Claude.

## 1. Trouver et contrôler la fiche

- `<ID>` → `Roadmap\<techno>\<serie>\<ID>_*.md`. `suivant` → première fiche au statut `valide` dans l'ordre de `roadmap.md`, puis des `_serie.md`.
- **Refuser de produire** si `statut` n'est pas `valide`, et dire ce qui manque. Exception : le client demande explicitement de produire une fiche `redige` (il la valide de fait) — passer alors le statut à `valide` avant de continuer.
- Si `code_verifie` est `false` : exécuter réellement chaque extrait (node, php, tinker...), comparer à la section « Le résultat affiché », corriger la fiche si la sortie diffère, puis passer à `true`. Ne jamais afficher une sortie supposée.
- Contrôler les limites de lisibilité : ≤ 10 lignes de code à l'écran, ≤ 32 caractères par ligne. Si ça dépasse, simplifier l'exemple dans la fiche (et le ré-exécuter), pas réduire la police.

Un script, pas une improvisation

Dès le début du corps, le skill pose la « voie normale » : un short se décrit dans un fichier tip.json, puis un script Python, produire.py, fait le reste. Le script vérifie le code sous Node, génère la composition, extrait la musique, lance les contrôles et prend les images de la planche.

C'est le point clé. Le skill ne demande pas à Claude de refaire la vidéo à la main à chaque fois. Il lui dit quel outil lancer, et quoi regarder ensuite. Et le script refuse de continuer si la sortie réelle du code diffère de celle écrite dans la fiche.

Ce qu'il m'évite

Chaque ligne de ce skill vient d'un vrai problème. Voici ceux qu'il règle :

• Une sortie inventée. Sur une chaîne de développeurs, un résultat faux à l'écran se paie en commentaires. La règle « ne jamais afficher une sortie supposée » oblige Claude à exécuter le code.
• Une fiche pas prête. Sans le contrôle du statut, Claude produirait un brouillon. Il refuse, et dit ce qui manque.
• Un code illisible sur téléphone. Les limites de 10 lignes et 32 caractères sont vérifiées avant la production, pas découvertes au rendu.
• Une série incohérente. Le gabarit est le même pour tous les shorts : même habillage, même rythme.
• Un lot qui déraille. Sur plusieurs fiches, le skill s'arrête au premier échec au lieu d'empiler les erreurs.

Et surtout, il m'évite de réexpliquer. Sans lui, il faudrait redonner ces règles à chaque session. J'en oublierais forcément.

Deux skills qui se passent le relais

/nouveau-tip a un voisin : /rediger-fiches, qui écrit les fiches en lot. Sa description se termine par une phrase qui compte :

Ne produit aucune vidéo — voir /nouveau-tip pour ça.

Cette phrase dit à Claude quand ne pas choisir ce skill. Résultat : « rédige la série tableaux » lance l'un, « produis JS-TAB-02 » lance l'autre. On reverra cette technique dans la leçon sur la description.

Ce que tu vas construire ensuite

Tu as vu le résultat. Il y a pourtant des défauts dans ces fichiers, et je te les montrerai. En préparant la formation, j'ai découvert que trois de mes quatre skills de projet ont un en-tête que les lecteurs YAML standards refusent. La cause tient en un caractère, et elle touche surtout ceux qui écrivent en français.

La suite de la formation te donne la méthode pour écrire les tiens, sur tes propres tâches :

• chaque champ d'un SKILL.md, y compris ceux que mon skill n'utilise pas encore ;
• le choix entre un skill de projet, un skill personnel et un plugin ;
• une description qui déclenche au bon moment, et la façon de la tester ;
• un script comme produire.py branché sans payer son code en contexte ;
• le même skill lu par Claude Code et par Codex.