G-resentation

Que fait G-resentation ?

Transforme « faire un PPT » en un processus complet de bout en bout, de la question jusqu'à la livraison. Le nom vient de grill me in presentation : d'abord on te questionne jusqu'à ce que tu ne puisses plus rien dire de vague, puis on passe à l'action.

Ce skill ne fait que de l'orchestration : clarifier les besoins, définir la structure, choisir la route, confier le travail au bon skill de production, puis valider. Il ne dessine aucune page lui-même.

Avant la première utilisation, exécute python3 "<SKILL_DIR>/scripts/doctor.py" ; il t'indiquera ce qui manque et quoi faire ensuite. Le parcours complet est décrit dans QUICKSTART.md.

Limites

• À utiliser : lorsque le contenu n'est pas encore finalisé et que tu dois créer une présentation à partir de zéro.
• Ne pas utiliser : si tu as déjà un plan page par page et que tu souhaites uniquement la mise en page, une retouche, une conversion de format – dans ce cas, appelle directement le skill de production.
• Priorité de déclenchement : ce skill choisit d'abord la route, puis appelle le skill de production. Ne laisse pas les skills de production, qui peuvent aussi prétendre « générer une présentation », sauter l'étape 0.

Structure du projet

Chaque travail est dans un dossier decks/<slug>/, avec des noms de fichiers fixes que toutes les étapes suivantes reconnaissent :

decks/<slug>/
├── brief.md      Cahier des charges (produit à l'étape 0)
├── outline.md    Plan page par page (P01, P02…)
├── assets/
│   ├── sources/  Matériaux originaux pour vérifier les faits
│   └── media/    Images, logos, captures d'écran réels à intégrer
├── out/          Livrables
└── versions/     Archivage des versions

Pour les petits travaux, assets/ et versions/ peuvent être omis.

Scripts

Les trois scripts ne font que des tâches déterministes ; ils ne remplacent pas le jugement. Ils utilisent uniquement la bibliothèque standard et fonctionnent avec n'importe quel Python 3.10+, sans besoin de paquets supplémentaires.

<SKILL_DIR> est le chemin absolu du dossier de ce skill ; remplace-le avant d'exécuter. Les commandes ci-dessous fonctionnent sous macOS / Linux / Git Bash ; sous PowerShell, remplace "$S/xxx.py" par "$S\xxx.py".

S="<SKILL_DIR>/scripts"

python3 "$S/new_deck.py" q4-review --title "Bilan Q4"      # Crée le dossier projet et deux fichiers vides
python3 "$S/new_deck.py" weekly-sync --small                # Petit travail
python3 "$S/check_outline.py" decks/q4-review               # Vérifie numéros de page consécutifs, six champs, comparaison avec la baseline gelée
python3 "$S/snapshot.py" decks/q4-review outline            # Archive la version, incrémente automatiquement v01, v02…

Sous Windows, python3 peut être un placeholder du Store ; vérifie d'abord avec python3 -V. Si cela ne fonctionne pas, utilise python ou py -3. Tous les scripts acceptent n'importe quel interpréteur fonctionnel.

Si check_outline.py retourne un code de sortie non nul, corrige d'abord avant de continuer. Exécute-le à nouveau après le gel ; il listera les différences de pagination par rapport à versions/v01-outline/, ce qui sert de filet de sécurité pour « modifier P07 uniquement par numéro ».

Dépendances externes (optionnelles, à installer selon les besoins)

Ce skill n'est qu'une couche d'orchestration ; il n'empaquette aucun outil de production. Les quatre dépendances ci-dessous sont nécessaires selon la route choisie. Si elles manquent, une option dégradée est proposée :

Dépendance	Route concernée	Que faire si absent
frontend-slides	Présentation HTML	Créer un HTML fichier unique, ou utiliser l'une des deux routes suivantes
guizang-ppt-skill	Autre style de présentation HTML	Utiliser frontend-slides en remplacement
ppt-master	PPTX éditable	Revenir au HTML ou aux images, en précisant « PPTX non généré »
imagegen	Pages en images	Utiliser la capture d'écran HTML pour exporter en PNG

Installation : npx skills add <owner/repo>, voir les dépôts respectifs. En cas de dépendance manquante, informe honnêtement l'utilisateur de ce qui manque et de l'impact, sans faire semblant de produire le résultat.

ppt-master a des dépendances hors bibliothèque standard (python-pptx, PyYAML, skia-pathops, uharfbuzz, etc.). Ne fige pas le chemin de l'interpréteur ; détecte d'abord :

PY=$(command -v python3 || command -v python)
"$PY" -c "import pptx, yaml, pathops, uharfbuzz" 2>/dev/null \
  || echo "Dépendance manquante : demande à l'utilisateur d'exécuter pip install -r <PPT_MASTER_DIR>/requirements.txt dans son environnement Python"

Passe ensuite son contrôle d'intégrité "$PY" "<PPT_MASTER_DIR>/scripts/attribution_guard.py". Si le code de sortie est non nul, arrête-toi ; ne corrige pas et ne contourne pas.

Sources et faits

Pour le contenu « actuel », n'écris pas de mémoire. Si le skill aihot est installé, utilise-le pour obtenir les dernières actualités. C'est une API publique en lecture seule, sans clé nécessaire :

curl -sL "https://aihot.virxact.com/api/v1/items?mode=selected&window=7d&q=<mot-clé>&limit=10"
curl -sL "https://aihot.virxact.com/api/v1/hot-topics"

• mode=selected est le pool de sélection ; si la requête avec q renvoie vide, essaye à nouveau avec mode=all et précise « non sélectionné ».
• Les réponses brutes sont stockées dans assets/sources/ pour vérification ultérieure, pas dans le livrable.
• En bas de page, indique uniquement la source originale tierce (éditeur, titre du rapport, date), ne paraphrase pas le résumé du site d'actualités et n'utilise pas son lien comme référence.
• L'API autorise un usage personnel et non commercial ; pour une livraison commerciale, une facturation ou une redistribution en volume, obtiens d'abord l'autorisation selon ses conditions, ne suppose pas qu'elle est autorisée par défaut.
• Si le skill n'est pas installé ou si la récupération échoue, tombe sur une recherche publique ou demande à l'utilisateur de fournir les sources, en indiquant la date des données.

Processus

1. Catégorisation

Un seul critère : peut-on revenir en arrière si le travail est mal fait ?

Client externe, revue formelle, archivage ou diffusion, livraison interdépartement → gros projet ; réunion interne, petit cercle de collègues, refaisable à tout moment → petit travail.

Annonce la décision en une phrase : « Je traite ce travail comme un gros projet » ou « Petit travail, remplis le formulaire ». L'utilisateur peut modifier la catégorisation, puis on continue.

2. Recueil des besoins (étape verrou)

• Petit travail : donne à l'utilisateur le fichier assets/brief-template.md à remplir. Si des champs manquent, pose des questions ciblées ; ne devine pas à sa place.
• Gros projet : pose une question à la fois, d'abord le contenu, puis les quatre dimensions de l'audience, enfin la forme. Les questions et la phraséologie sont dans references/step0.md.

Quelle que soit la catégorie, résume d'abord en trois phrases : « Ce document est pour qui, que veux-tu qu'ils fassent, que doivent-ils retenir ? ». N'écris brief.md qu'après confirmation.

3. Plan page par page (étape verrou)

Écris outline.md selon les sept champs de references/step0.md, chaque page avec un numéro, P01 en premier, dans l'ordre. Le titre sur la même ligne que le numéro, les six autres champs en dessous. Utilise le P1 Plan page par page de references/prompts.md, en remplaçant tous les [ ] par le contenu réel de brief.md. Après avoir écrit, exécute check_outline.py ; des numéros non consécutifs, des titres ou champs manquants signifient que ce n'est pas terminé.

Après confirmation, gèle : exécute immédiatement snapshot.py <deck> outline pour créer la baseline. Le nombre de pages et les numéros sont désormais fixes. Tout ajout ou suppression de page nécessite l'accord de l'utilisateur, et tout réarrangement doit être signalé (« ancien P07 → nouveau P05 »). Toutes les modifications ultérieures « page X » ne reconnaissent que le numéro.

4. Choix de la route + trois maquettes (étape verrou)

Propose d'abord un choix en déduisant une route à partir du brief, explique les raisons et laisse l'utilisateur la refuser. Ne demande pas directement « Quel type veux-tu ? ». Les critères et les appels sont dans references/paths.md.

Les maquettes doivent porter sur les trois pages les plus difficiles : la couverture, la page avec le plus d'informations, et la page avec un graphique ou un processus complexe. Fournis de vraies productions (HTML consultable, PNG visible, PPTX ouvrable), pas de captures d'écran. Ne passe à la production complète qu'après validation de la direction. Les prompts des trois routes (P3 / P4 / P6) intègrent déjà cette exigence de maquettes, pas besoin d'écrire à part.

5. Production

Appelle le skill correspondant à la route et exécute le prompt associé :

Route	Prompt utilisé	Skill
Présentation web	P3	frontend-slides ou guizang-ppt-skill
Pages en images	P4, éventuellement P5	imagegen ; P5 vers ppt-master
PPTX éditable	P6	ppt-master

S'il y a des références visuelles ou des exigences élevées, ajoute d'abord P2 Décomposition du style avant le prompt ; sinon, laisse le style par défaut du skill de production.

Remplace tous les [ ] dans les prompts par le contenu réel de brief.md ; n'en laisse aucun avant d'envoyer.

Produis par lots de dix pages, annonce « P11–P20 prêtes » sans interrompre le rythme. Ne t'arrête que si une page est vraiment impossible à réaliser.

Avant d'utiliser ppt-master, vérifie d'abord que l'interpréteur peut importer ses paquets ; sinon, demande à l'utilisateur d'installer son requirements.txt, sans figer le chemin de l'environnement virtuel :

PY=$(command -v python3 || command -v python)
"$PY" -c "import pptx, yaml, pathops, uharfbuzz" || echo "Dépendance manquante, voir la section des dépendances externes"

6. Validation + archivage

Passe en revue chaque élément selon les quatre catégories de references/checklist.md. Pour la version web, ouvre-la dans le navigateur intégré et teste la navigation, le zoom, et la déconnexion. Si un élément ne passe pas, utilise P7 Modification d'une seule page avec le numéro de page et une capture d'écran, en ne modifiant qu'une page à la fois ; pour des problèmes similaires sur plusieurs pages, décris la portée puis relis l'ensemble.

Avant la livraison, exécute snapshot.py <deck> final pour archiver une version.

7. Instructions de livraison

Résume en une phrase : depuis quel fichier ouvrir, les prérequis d'exécution, et les limitations connues.

Règles strictes

• À chaque point de contrôle, pose uniquement une question spécifique (« Cette direction pour les trois pages est-elle correcte ? Qu'est-ce qui ne va pas ? »), ne demande pas « Qu'en penses-tu ? ».
• N'invente pas de faits, de chiffres ou de cas d'usage. En cas de conflit ou de manque d'information, arrête-toi et pose une question, ne devine pas.
• Si une exigence est impossible, expose clairement la limitation et une alternative ; ne la réduis pas en silence.
• Si le même problème n'est pas résolu après deux rounds, cherche d'abord la cause, ne continue pas à générer en boucle.
• Le processus complet ne s'arrête qu'aux maquettes et à la validation finale ; pas de validation page par page entre les deux.