create-doc — Créer un document de structure pour la création de…

Create-doc — Créer un plan de structure pour la compétence de création de slides

À partir des fichiers de recherche (logs d'exécution .md, résultats CSV, figures, code), rédige un plan détaillé au format Markdown, où chaque diapositive spécifie « quoi dire, quel modèle utiliser, quelles informations afficher et quoi raconter ».

Le destinataire est la compétence progress-report-deck (dans le même plugin research-slides, située dans le dossier voisin ${CLAUDE_SKILL_DIR}/../progress-report-deck/). La sortie de cette compétence est conçue pour que progress-report-deck la lise en considérant chaque titre ## comme une diapositive, puis l'injecte dans des modèles de mise en page. Avant de commencer, lis ${CLAUDE_SKILL_DIR}/../progress-report-deck/SKILL.md et vérifie qu'il n'y a pas de divergence avec les « Règles avec la compétence de création de slides » ci-dessous (si les règles de l'autre compétence ont changé, adapte-toi à elles). Si introuvable, écris selon ces règles.

Si le profil utilisateur ~/.claude/yapi-skills/profile.md (nom, domaine de recherche, audience principale, règles personnelles) existe, lis-le en premier. Les règles personnelles (couleurs, taille de police minimum, etc.) ont priorité sur les règles ci-dessous ; reporte-les également dans la section « À propos de ce document ».

Un exemple de plan se trouve dans references/template.md. En cas de doute sur le format, suis cet exemple.

Règles avec la compétence de création de slides (issues des règles de progress-report-deck)

Le plan doit respecter ces règles. Sinon, lors de la création des slides, des parties risquent d'être supprimées ou de devoir être refaites.

Élément	Règle	Raison (règle côté progress-report-deck)
Titres	1 ## = 1 diapositive. Même les compléments utilisent ## uniquement pour les slides. Utilise # pour les séparations de chapitres.	Le brouillon ## est lu comme une diapositive.
Structure	Titre → Table des matières → Contexte (1/2)(2/2) → Objectif de recherche (sous-objectif) → Contenu → Résumé / Problèmes → Remerciements, dans cet ordre.	Structure fixe du modèle.
Contexte	Si inchangé depuis la dernière fois, écrire simplement « inchangé (basé sur le document de base) » sans détailler.	Le contexte est généralement inchangé.
Sous-objectif	Sur la diapositive « Objectif de recherche », écrire obligatoirement « Sous-objectif de cette session » (1-2 lignes).	C'est une question que l'autre compétence pose à chaque utilisateur. À décider à l'avance.
Nombre de slides	Rédiger avec le nombre final de slides (pour éviter que l'autre compétence doive fusionner ou diviser).	Si ## est trop nombreux, l'autre propose une fusion.
Modèle	Chaque diapositive de contenu doit avoir un modèle de mise en page spécifié (voir tableau ci-dessous).	Si le contenu est en liste à puces, l'autre compétence signale « la moitié inférieure est vide ».
Couleurs	Seulement 2 couleurs : bleu = proposition / réponse / conclusion / valeur vedette, orange = méthode conventionnelle / problème / remarque / attention. Pas de troisième couleur par méthode. Dans les tableaux, les lignes vedettes sont « mises en évidence en bleu pâle ».	Thème bleu #156082 et orange #E97132 uniquement.
Quantité de texte	Les affirmations doivent tenir dans 30 caractères pleine largeur (taille de police 18pt sur une ligne). Chaque puce également ~30 caractères. Maximum 3 lignes par panneau. Si plus long, utiliser un tableau ou une figure, ou diviser la slide.	Police minimum 16pt, impossible de réduire.
Taille de police	Ne pas écrire d'instructions comme « petit », « note en petits caractères ». Les notes de bas de page doivent tenir sur une ligne en 16pt.	Interdiction d'utiliser du texte en moins de 16pt.
Formules	Écrire en $...$ (LaTeX) et préciser « formule (OMML) ».	Les formules sont composées en OMML.
Figures	Copier les PNG dans images/ du dossier de sortie et les référencer par images/<nom>.png (si seule une version PDF existe, convertir en PNG). N'utilise pas de chemin relatif ../ ou de chemin dans le dépôt. Vérifie qu'elles tiennent dans un rapport 4:3 (ex. : deux figures larges empilées verticalement).	pptx accepte les PNG. Les slides sont en 4:3. Elles peuvent être créées dans un autre dossier ou sur une autre machine ; le dossier parent n'est pas accessible.
Schémas	Pour les éléments sans fichier image (diagrammes de flux, timeline, comparaison avant/après), écrire le nom du modèle et la méthode de dessin en détail.	Pour éviter que l'autre compétence demande à l'utilisateur comment gérer la figure.
Notes	Le contenu à dire doit être écrit dans les « Notes ». Ne pas le placer sur la slide.	—
Compléments	Les slides complémentaires pour les questions doivent être placées après la diapositive « Merci de votre attention ».	La clôture marque la fin du contenu principal.

Modèles de mise en page disponibles (exemples dans assets/template.pptx de progress-report-deck) :

Modèle	Usage	Exemple dans template.pptx
Puce + panneau (problème → solution)	« Problème conventionnel → solution », « Remarque → réponse »	p.7, p.11
Badge numéroté + panneau	Énumération d'éléments numérotés ①②③ (avantages, procédures)	p.8-9
Schéma Before/After	Comparaison méthode conventionnelle vs proposée (gauche = orange, droite = bleu, flèche entre)	p.10
Schéma timeline	Flux temporel (boîtes pleines/pointillées + connecteurs)	p.12
2 colonnes puce + panneau + barre inférieure	Comparaison côte à côte de deux méthodes/paramètres, avec formules	p.13
Tableau + barre pleine largeur	Tableau de résultats avec barre en dessous pour « ce qu'on en déduit » (ligne vedette en bleu foncé)	p.14
Tuiles KPI (2×2)	Afficher 4 valeurs ou conclusions en grand	p.15
Liste de vérification (✓)	Énumération de ce qui a été vérifié ou fait	p.16
Boîtes encadrées 2 niveaux	Résumé / perspectives futures	p.17
Figure + barre pleine largeur	Afficher une figure existante en grand, avec barre en dessous pour l'interprétation	(p.14 avec tableau remplacé par figure)

La table des matières (actions de cette session) n'a pas de modèle (reste en liste à puces, mots-clés en gras, pas de couleur).

Procédure

1. Recueillir les exigences (AskUserQuestion, en une fois)

Ne demande pas ce qui est évident d'après la conversation ou la demande. Demande seulement ce qui manque.

• Type et durée de la présentation : rapport d'avancement / séminaire / conférence. Estimation : 1 diapositive de contenu ≈ 1 minute (pour 15 min, environ 10 slides de contenu + 5-6 pour la structure).
• Audience : membres du laboratoire / conférence / personnes d'un autre domaine. Le niveau de connaissances préalables change.
• Informations contextuelles à inclure (choix multiples) : motivation / historique, expériences comparatives, analyse des échecs, évolution des méthodes, impact des corrections de bugs, etc. Propose les sujets trouvés dans les enregistrements.
• Contexte à conserver inchangé ou non : si tu changes le contexte par rapport à la présentation précédente, décris les modifications.

Si l'utilisateur répond par du texte libre hors des options proposées, traite cela comme une exigence (ex. : « ajoute aussi "" dans la motivation »).

2. Rassembler le matériel (lecture seulement ; ne réexécute pas les expériences)

• Compétence de création de slides : ${CLAUDE_SKILL_DIR}/../progress-report-deck/SKILL.md (vérification des règles ci-dessus).
• Enregistrements : Log_execution_*.md, *resultats*.md, README.md, documents stratégiques, etc. Lis du plus récent au plus ancien.
• Valeurs numériques : summary/*.csv, tableaux dans *.md. Les chiffres à présenter doivent être recopiés depuis ces sources.
• Figures : Cherche les PNG existants avec ls. Privilégie les figures avec des légendes en japonais. Note le chemin d'origine de la figure utilisée (pour la copier dans images/ à l'étape 4 et indiquer la source).
• Paramètres : Pour les hyperparamètres, constantes, configuration de modèle à mettre dans les slides complémentaires, prends les valeurs réelles du code (constantes, valeurs par défaut d'argparse, fichiers de configuration JSON sauvegardés lors de l'exécution) plutôt que les enregistrements .md. Si les enregistrements et le code divergent, le code fait foi ; informe l'utilisateur.

3. Déterminer la structure

Structure (adaptée au modèle de progress-report-deck) :

1. Titre
2. Actions de cette session (table des matières, liste courte des titres des slides de contenu)
3. Contexte (1/2)
4. Contexte (2/2)
5. Objectif de recherche (objectif + sous-objectif de cette session)
6. Diapositives de contenu
7. Résumé / Problèmes
8. Merci de votre attention
9. Slides complémentaires (pour les questions)

Les slides de contenu suivent généralement ce déroulement (ajuste selon le nombre) :

1. Motivation / Problème (pourquoi l'avoir fait) → Puce + panneau
2. Proposition / contenu des modifications et avantages → Schéma Before/After ou Badge numéroté + panneau
3. Détail de la méthode (flux de traitement) → Schéma timeline
4. Assurance de la justesse / vérification → Liste de vérification
5. Méthode de détermination des paramètres → Tuiles KPI ou Tableau + barre
6. Configuration expérimentale (données, méthodes comparées, métriques d'évaluation) → 2 colonnes ou Tableau + barre
7. Résultats (une diapositive par affirmation) → Tableau + barre, Figure + barre
8. Coût / contraintes → Tableau + barre ou Tuiles KPI

Ajoute toujours des slides complémentaires (pour les questions). Ceux-ci ne sont pas comptés dans le temps de présentation.

• Configuration détaillée (modèle, optimisation, constantes dans un tableau)
• Configuration des données / simulations
• Détails des méthodes comparées (formules en OMML)
• Définition précise des métriques d'évaluation
• Tableau complet des résultats (ex. recherche de paramètres)
• Questions anticipées et réponses types (environ 8) : ne pas les mettre en slides (placer comme chapitre # à la fin du plan, pour l'orateur). Privilégie les questions qui ciblent les faiblesses : « l'écart n'est-il pas trop faible ? », « peut-on généraliser avec un seul essai ? », « pourquoi ce comparateur ? », « quel est le coût de calcul ? », « quelle est la justification d'une affirmation non vérifiée ? », etc.

4. Écrire (produire une sortie dans un dossier)

Les slides peuvent être créées dans un autre dossier ou sur une autre machine (un PC avec PowerPoint, par exemple). Par conséquent, produis un dossier autonome contenant le plan et les images nécessaires, afin que ce seul dossier permette de créer les slides.

Document-slides-<date>/
├── Document-slides-<date>.md   ← Plan
└── images/
    ├── speed_sweep.png
    └── ...

• Le nom du dossier et le fichier .md doivent être unifiés sous Document-slides-<date> (ex. : Document-slides-2026-10-15/). La date est la date de création au format YYYY-MM-DD. Si plusieurs présentations sont créées le même jour, ajoute un identifiant court après la date (ex. : Document-slides-2026-10-15-seminaire/). N'écrase pas un dossier existant. Crée-le à la racine du projet.
• Images : copie toutes les figures utilisées dans images/ (copie, pas déplacement ; ne touche pas aux fichiers originaux).
  • Conserve le nom d'origine. En cas de conflit de nom ou si le nom n'est pas explicite (fig1.png, etc.), renomme en un nom alphanumérique explicite (ex. : velocity_field_f195.png). Pas d'espaces.
  • Si une figure n'existe qu'en PDF, convertis-la en PNG (ex. : pdftoppm -png -r 200 -singlefile in.pdf images/name ou PyMuPDF à 200 dpi).
  • Dans le plan, référence-la par images/<nom>.png.
  • Conserve le chemin d'origine dans une section « Sources » sous la forme « images/xxx.png ← chemin d'origine », pour pouvoir retrouver la figure en cas de modification ultérieure.
• Pour les schémas sans fichier image, n'écris pas d'image ; décris la méthode de dessin dans le plan.

Dans la section d'en-tête « À propos de ce document » (chapitre #, pas une slide), écris les instructions pour progress-report-deck :

• Type de présentation / durée / nombre de slides / audience
• Format de chaque diapositive (voir ci-dessous)
• Ne pas modifier ni arrondir les valeurs numériques
• Exécuter progress-report-deck en utilisant ce dossier comme dossier de travail. Les figures sont dans images/ de ce dossier, référencées comme images/<nom>.png. Ne pas créer de nouvelles figures (les schémas doivent être dessinés selon les instructions)
• Règles typographiques pour les noms de méthodes, attribution des couleurs (bleu = proposition, orange = méthode conventionnelle / comparateur)
• Contexte inchangé ou non

Format de chaque diapositive :

## Diapositive N — <titre>

- **Modèle** : <nom du modèle (un du tableau ci-dessus)>
- **Affirmation** : <une phrase en 30 caractères pleine largeur maximum. Ce que l'on veut le plus dire sur cette slide>
- **Corps** : <liste à puces, chaque élément ~30 caractères, maximum 3-4 éléments>
- **Tableau** / **Figure** : <tableau en Markdown, en indiquant les lignes/colonnes à mettre en évidence. Figure : `chemin_relatif.png` (description de la figure)>
- **Formule (OMML)** : <si applicable, en $...$>
- **Notes** : <contenu à dire. Ne pas mettre sur la slide>

Règles lors de l'écriture :

• L'affirmation doit être une conclusion. Pas « Résultat ① », « À propos de XX », « Montre XX », mais « Plus la vitesse augmente, plus l'écart se creuse ». Ne termine pas par « ... est » / « ... fait ».
• Les termes d'évaluation doivent être étayés par des valeurs numériques. Si tu écris « considérablement », « efficace », « excellent », place dans la même diapositive la référence, la métrique et le nombre d'essais. Évite « équivalent » ou « garanti » (préfère « quasi équivalent » ou « confirmé »).
• N'utilise pas de mots typiques du langage généré par l'IA (très, révolutionnaire, permet de, seamless, etc.). Voir ${CLAUDE_SKILL_DIR}/../progress-report-deck/references/ai-smell-lexicon.md pour la liste et les alternatives.
• Chaque puce du corps doit être une phrase unique (si deux phrases reliées par « . », sépare-les).
• Écris explicitement ce qui n'est pas vérifié. Ne mélange pas les propriétés attendues et ce qui a été démontré expérimentalement. Ajoute une ligne dans le corps ou la barre de la slide concernée, et dans « Résumé / Problèmes » dans la partie « À l'avenir ».
• Les conditions d'une comparaison équitable (utilisation de paramètres convergés, etc.) s'écrivent en une note de bas de page d'une ligne. Les longues explications historiques ne sont incluses que si l'utilisateur demande.
• Les explications détaillées qui ne tiennent pas sur une slide doivent être déplacées dans les notes ou les slides complémentaires. Ne rallonge pas le corps.
• Enfin, ajoute une section # « Sources » avec un tableau (contenu → fichier).

5. Vérifier (obligatoire)

1. Vérification mécanique des valeurs numériques : extrais tous les nombres décimaux du plan via une expression régulière et vérifie qu'ils sont présents dans les sources .md/CSV (les CSV sont arrondis à 4 ou 2 chiffres). Pour chaque nombre non trouvé, détermine s'il s'agit d'une différence calculée par toi, d'une erreur de recopie ou d'une incohérence d'arrondi, et corrige. Place le script de vérification dans le scratchpad.
2. Autonomie du dossier : toutes les références de figures dans le plan doivent être des images/ sous forme de PNG existants. Pas de ../, de chemins absolus ou de chemins dans le dépôt. Aucun fichier superflu dans images/ qui ne soit référencé. Signale également la taille totale du dossier.
3. Contenu des figures : pour toute phrase mentionnant une figure (« grand dans XX », etc.), ouvre la figure et vérifie visuellement que c'est correct.
4. Vérification mécanique des règles : compte le nombre de ## pour vérifier qu'il correspond au nombre prévu de diapositives, que toutes les diapositives (hors structure) ont un modèle, qu'il n'y a pas de troisième couleur, que les affirmations respectent 30 caractères, qu'elles sont bien des conclusions, et qu'il n'y a pas de termes « AI-odeur » ou d'incohérences typographiques. Utilise le script d'inspection de la compétence de création de slides :

   python "${CLAUDE_SKILL_DIR}/../progress-report-deck/scripts/check_deck.py" --text "<plan.md>" > check_doc.txt
   

   Lis la sortie avec Read et corrige les WARN. Si la correction introduit un terme correct scientifiquement, tu peux le conserver. Si la dernière ligne n'est pas DONE: …, le test a échoué ; ne considère pas qu'il y a 0 problème. Si le script est introuvable, vérifie manuellement.
5. Nombre de slides : vérifie que le contenu principal correspond au nombre demandé.

6. Rapporter

• Première ligne : destinataire prévu (ex. : « Lecteur prévu : compétence progress-report-deck (et au-delà, l'audience du séminaire du laboratoire) »).
• Chemin du dossier de sortie et son contenu (un fichier .md + nombre d'images + taille totale).
• Structure (une ligne par diapositive) et contenu des compléments.
• Résultats de la vérification (nombre de valeurs vérifiées, confirmation des figures, vérification des règles).
• Points que l'utilisateur doit connaître avant la présentation : affirmations non vérifiées, valeurs susceptibles d'être contestées et pourquoi, date et code source des résultats utilisés.
• Prochaine étape : « Avec ce dossier, exécute progress-report-deck (si sur une autre machine, copie d'abord le dossier entier) pour créer les diapositives. » La méthode de transport (clé USB, Box/OneDrive, envoi d'un zip, etc.) est laissée au choix de l'utilisateur.
• Ne fais pas de commit (sauf si demandé).