master-class

Master class

Transforme du matériel d'étude en un cours vidéo que l'apprenant voudra vraiment regarder. Cette compétence gère la pédagogie (lecture, plan de cours, scripts). Le rendu (diagrammes, voix, MP4, notes Obsidian) est effectué par la compétence complémentaire master-class-render.

Routage du modèle (instruction explicite de l'utilisateur)

PEDAGOGY_MODEL: claude-sonnet-5.5    # lecture, plan de cours, scripts (étapes 1–4). Modèle le moins cher qui maintient la qualité ; changez ici si nécessaire.

La qualité dépend presque entièrement des étapes 1 à 4, elles doivent donc impérativement être exécutées sur PEDAGOGY_MODEL. Les étapes 0, 5 et 6 sont mécaniques et s'exécutent sur le modèle qui pilote cette session.

• Si vous êtes déjà PEDAGOGY_MODEL (ou si l'utilisateur demande de sauter la délégation), effectuez vous-même les étapes 1 à 4.
• Sinon, déléguez. Lancez un sous-agent general-purpose avec model: PEDAGOGY_MODEL. Définir le modèle ici est une instruction explicite de l'utilisateur. Son invite doit inclure : le chemin source, la langue de sortie, le chemin du dossier source, tout focus/contexte donné par l'utilisateur, et "Lisez ~/.copilot/skills/master-class/SKILL.md et suivez exactement les étapes 1–2 ; écrivez course-map.md, puis arrêtez-vous et renvoyez le plan."
  • Montrez le plan renvoyé à l'utilisateur et attendez son approbation (sauf si l'utilisateur a demandé à exécuter sans approbation).
  • Ensuite, envoyez l'approbation/les modifications au même agent (write_agent) : "Approuvé [+ modifications]. Effectuez maintenant les étapes 3–4 exactement : écrivez chaque script, effectuez le lint jusqu'à ce qu'il n'y ait plus d'erreurs, écrivez scripts/README.md, puis renvoyez le résumé du lint."
  • Puis continuez vous-même avec l'étape 5 (rendu), qui ne nécessite pas un gros modèle.
• Si l'utilisateur nomme un modèle différent pour la pédagogie dans la requête, utilisez celui-ci à la place.

Liste de lecture (avant d'écrire quoi que ce soit)

1. references/cheatsheet.md : une page avec les règles qui comptent.
2. references/learner-profile.md : qui est l'apprenant, comment il pense, quelles analogies fonctionnent.
3. references/lesson-template.md : le squelette à remplir pour chaque leçon.
4. Exemples approuvés, tous issus d'un même cours (Lab 02, Utilisation d'outils et MCP) : examples/course-map.md, 01 (une phrase fausse → mécanisme), 05 (une histoire → une règle), 08 (peser les options → pourquoi une norme existe). Imitez leur profondeur et leur ton, pas leur formulation.
5. Optionnel : references/teaching-research.md, les preuves et sources derrière les règles.

Règles pédagogiques non négociables

1. Problème avant solution. Chaque leçon commence par une situation concrète où quelque chose échoue ou fait mal. La technologie n'est nommée qu'après le problème et les alternatives évidentes rejetées.
2. Enseigner l'intention, pas l'implémentation. Si le matériel enseigne X, l'apprenant doit comprendre ce qu'est X, pourquoi il existe, quand l'utiliser et quand ne pas l'utiliser. Le code est une preuve pour un concept déjà expliqué (≤ 6 lignes), jamais une explication pas à pas.
3. Démonter une idée fausse par leçon, à voix haute.
4. Du concret à l'abstrait, avec un exemple fil rouge qui traverse tout le cours.
5. La manière de penser de l'apprenant : contexte → contrainte réelle → options envisagées et pourquoi chacune a été rejetée → décision → coût/compromis → quand ne pas l'utiliser. Demandez explicitement "y a-t-il quelque chose de mieux ?".
6. Pause de récupération dans chaque leçon : question → … (le rendu insère une pause de 4 s) → réponse avec sa raison.
7. Pont : chaque leçon se termine par le problème que résout la suivante.
8. Pas de limite de longueur, mais un seul objectif d'apprentissage par leçon (généralement 4–6 min).
9. Variez les ouvertures, les fils conducteurs et les conclusions ; jamais un moule fixe.
10. Ne jamais inventer de faits ou de chiffres. Les affirmations techniques proviennent des sources lues ou des docs officiels vérifiés ; les scénarios hypothétiques doivent être clairement identifiés comme tels.

Workflow

0 · Demander d'abord

• Langue de sortie : toujours demander sauf si l'utilisateur l'a déjà précisée.
• Chemin source, s'il manque. Valeurs par défaut (confirmer uniquement si la structure du coffre diffère) :
  • notes → <dossier lab>/Master class/
  • vidéos → <dossier lab>/_attachments/master-class/
  • sources → <dossier lab>/_attachments/master-class/source/ (course-map.md, scripts/, scenes/)
• Appliquez le routage du modèle ci-dessus.

1 · Lire avec une profondeur limitée

• Lisez entièrement le lab/la note. Pour les notebooks, lisez le markdown et les concepts que le code démontre ; n'exécutez jamais les notebooks et ne lisez jamais de secrets ou de .env.
• Suivez les [[wikilinks]]/documents liés jusqu'à 2 niveaux de profondeur, seulement si pertinent pour l'intention du matériel. Ignorez les futurs labs, les prérequis déjà couverts et les digressions.
• Le web est autorisé pour vérifier ou compléter le pourquoi (docs officiels et spécifications). Citez-le.
• Tenez un journal : lu / écarté + raison.

2 · Plan de cours → arrêt pour approbation

Écrivez <source>/course-map.md comme examples/course-map.md :

• l'intention en 2–3 phrases, comme ce que l'apprenant sera capable de décider ;
• le journal de lecture ;
• un tableau des leçons : # · leçon · problème qu'elle ouvre · idée fausse · analogie/ouverture · résout → laisse ouvert, avec la leçon 00 comme vision d'ensemble et la dernière leçon comme synthèse sous forme de décisions.

3 · Scripts, une leçon par passage

Pour chaque leçon, dans l'ordre :

1. Relisez l'aide-mémoire, le modèle, la ligne de la leçon dans le plan et un exemple.
2. Copiez references/lesson-template.md vers <source>/scripts/NN - Titre court.script.md et remplissez-le. Le suffixe .script.md est obligatoire, car sinon Obsidian confond les scripts avec les notes de leçon.
3. Effectuez le lint (étape 4) et corrigez avant de passer à la leçon suivante.

La narration est écrite pour l'oreille : pas de listes, tableaux ou URL ; les nombres comme on les dit ; les identifiants/code entre guillemets (lire comme des mots). Le temps de récupération est titré Pause de récupération et contient … entre la question et la réponse. Si son Écran est la question elle-même, écrivez-la comme *"question"*.

Enfin, écrivez <source>/scripts/README.md : tableau des leçons + auto-évaluation par rubrique.

4 · Lint + rubrique (doit passer avant le rendu)

python3 ~/.copilot/skills/master-class/scripts/lint_script.py "<source>/scripts" --sources "<dossier lab>" <autres notes lues>

Corrigez chaque ERREUR. Corrigez chaque AVERTISSEMENT sauf s'il est intentionnel (par exemple, un nombre hypothétique dans un scénario clairement hypothétique). Le linter ne peut pas juger ces éléments, alors vérifiez-les vous-même :

• Pourquoi avant comment : la technologie n'apparaît qu'après les alternatives rejetées
• Compréhensible sans voir aucun code
• L'idée fausse est énoncée et démontée explicitement
• La question de l'accroche reçoit une réponse explicite
• L'Écran complète la narration (pas de texte dupliqué)
• Lu à voix haute, cela sonne comme un professeur, pas comme des points
• Les ouvertures/conclusions varient entre des leçons consécutives

5 · Rendu → master-class-render

Lisez ~/.copilot/skills/master-class-render/SKILL.md et suivez-le : écrivez les scènes, puis construisez les MP4, les notes de leçon et le MOC avec une seule commande, puis vérifiez.

6 · Rapport

Chemins (MOC en premier), nombre de leçons et durée totale, résultat du lint, tout élément non vérifié et un résumé du journal de lecture.