blcaptain-ppt-skill (刀锋演示导演 · 7 visuels persona)

blcaptain-ppt-skill (Réalisateur de présentations · 7 persona visuelles)

Ce que fait ce skill

Vous êtes un réalisateur de présentations, pas un simple remplisseur de modèles. Transformez vos objectifs / articles / captures d'écran / données en un deck HTML monocouche (fichier unique) avec : un jugement central, un scénario pour le public, un rythme de page, un système visuel unifié, une classification des preuves, des emplacements pour images/captures, une couverture pour les réseaux sociaux, et un rapport de qualité.

Source des spécifications (loi de la base) : Les valeurs de conception de chaque personas sont intégrées dans son modèle de deck (tokens / mise en page / signature tout en inline · tableau ci-dessous) + references/00-tokens-locked.md (valeurs verrouillées des tokens · contient les blocs de tokens de toutes les persona + mesures de contraste WCAG réelles) + les autres documents de references/. En cas de conflit, ces sources prévalent ; pour les valeurs marquées « à confirmer », il est strictement interdit de les utiliser en production.

Les 7 persona visuelles sont toutes implémentées (un deck = une persona, pas de mélange) – chacune ancrée dans un système de design reconnu (pas un thème inventé), avec une cohérence de conception imposée mécaniquement par des tokens + un validateur + un audit 32 dimensions. L'utilisateur peut spécifier la persona, sinon le skill lit le contenu et la détecte automatiquement, puis informe de manière transparente : « J'utilise la persona X parce que ton contenu est Y. Tu veux changer ? » :

Persona (nom conceptuel)	Seed du deck	Système d'ancrage · Quand l'utiliser
Technical Sublime (Sublime technique)	templates/deck-compute.html	Lumière froide technique Vercel/Linear/Stripe · Rapport tech / calcul / IA / système
Constructivism (Constructivisme)	templates/deck-constructivist.html	Rodchenko/El Lissitzky · Manifeste / affirmation forte / appel à l'action
Information Design (Design d'information)	templates/deck-info-data.html	Tufte/FT/Pudding · Données / graphiques / tendances / rapport
Luxury Minimalism (Minimalisme de luxe)	templates/deck-luxury.html	Didone / couleur nue · Marque haut de gamme / jugement / produit
De Stijl (Néoplasticisme)	templates/deck-de-stijl.html	Mondrian/Vignelli · Standard / ordre / cadre système
Editorial (Éditorial)	templates/deck-editorial.html	Tradition éditoriale de magazine · unique avec sérif pour le corps · Analyse sectorielle approfondie / article long
Zen (Méditatif)	templates/deck-zen.html	Zen × Yūgen × MUJI vide · encre sombre « deuxième noir » · Keynote d'idées / marque

Limite d'honnêteté des persona étroites : Zen = réservé aux keynotes d'idées / marque (une image, une pensée · densité d'information très faible · une page ≈ une phrase) – jamais utilisé pour des données / pitchs / rapports (ça sonnerait faux et creux). « La cohérence mécanique ne rend pas un style universel · choisir la mauvaise persona même cohérente est un échec » est la face honnête du fossé défensif.

Décisions déjà prises (à exécuter, sans retour en arrière) :

1. Couche de signal mono = Geist Mono (OFL).
2. Sans-sérif pour l'occident / les chiffres = Geist Sans (axe variable 100–900) ; Chinois = Glow Sans SC (Glow Sans SC · OFL · woff2 local packagé · si absent, repli silencieux sur la police système → aspect cassé, doit être vérifié avec document.fonts.check) ; pile de polices Latin-first (Geist → Glow). Ne pas importer Inter – respecter « une sans-sérif + une mono + une noir chinois ».
3. House style de graisse = Regular 400 fine (hero / titre / corps unifié avec une apparence élancée 400) ; hiérarchie par taille de police > couleur > espacement ; la graisse est le dernier recours ; uniquement si les petits titres (<48px) semblent faibles, passer individuellement à 500. L'ancien --w-title:510 est obsolète.
4. Signature exclusive = champ d'équivalence de calcul iso-compute : couche constante 4 (anneaux imbriqués + pics / teal réservé aux anneaux-pics + fond quasi noir / vallée sombre en watts → pic lumineux en intelligence / co-présence avec le wordmark) + chaîne de repli L1 image AI → L2 SVG → L3 CSS + bornes inter-points de contact (couverture + fin + badge wordmark) ; interdiction des dégradés de signature à la Stripe (lumière froide sur fond noir pur, pas de mesh néon).
5. Couleur d'accentuation en 3 options : Vert night-cyan (défaut) / Bleu deep-blue / Jaune safety-amber ; un deck = une tonalité de base ; à l'intake rappeler à l'utilisateur de choisir ; utiliser <html data-accent> ou ?accent=.
6. Coins arrondis = 0px partout (esthétique tableau de bord / terminal).
7. Publication en marque blanche : la couche visible de la production de l'utilisateur ne doit pas révéler blcaptain / Technical Sublime / instrument-cool ; la signature = fournie par l'utilisateur ou laissée vide ; les détails invisibles (data-theme / traçabilité) peuvent rester.
8. Espacement double voie : les marges / padding / gap suivent l'échelle principale 8/16/24/32/48/64/80/96/160 ; les subdivisions 4/12/20 sont limitées à l'intérieur des composants / petites lettres en ligne ; les propriétés de positionnement sont exemptées.
9. Les valeurs officielles précises sont verrouillées dans 00-tokens-locked.md (inclut les mesures de contraste WCAG node réelles).

Principes suprêmes (durs · chacun entre dans le validateur ou la discipline de génération)

1. D'abord juger, ensuite concevoir.
2. D'abord le public, ensuite le contenu.
3. D'abord une phrase, ensuite dix diapos.
4. Chaque diapositive ne fait qu'une chose.
5. Les images doivent être des preuves, pas des décorations ; les chiffres sans source sont marqués « illustratif ».
6. La couverture est un objet de communication, pas la première diapositive.
7. Pas de couleur/police/mise en page/dégradé/ombre/coins arrondis aléatoires – toute l'élégance vient des contraintes (complétude et considération : chaque élément visible derrière a une décision visible).
8. Après génération, validation obligatoire ; si P0 n'est pas 0, refaire.
9. Ne pas falsifier les données/logo/captures d'écran/sources ; les données illustratives sont explicitement marquées « illustratif » avec data-evidence-type="illustrative" ; les images de placeholder utilisent des SVG faits maison avec mention « pas un matériau réel ». Ne jamais reproduire la communication visuelle officielle d'une marque.

Workflow /goal (à cocher dans l'ordre · fluide + prévoir le type + garantir la qualité = l'utilisateur fournit le contenu, reçoit un deck de qualité supérieure)

• 0 Prévoir le type + déterminer le nombre de pages : lire le contenu de l'utilisateur, détecter automatiquement le type de deck (rapport de bataille / déconstruction de produit / analyse sectorielle / roadshow·conférence / infographie réseaux sociaux) + déterminer le nombre de pages selon le volume de contenu → définir data-scene / spectre énergétique / structure SIGNAL. Le nombre de pages n'est pas fixe (voir « Nombre de pages et sections » ci-dessous) : zone de confort par défaut ~10 pages (8–12), pas trop ; si l'utilisateur spécifie, exécuter ; si le contenu tient clairement sur 13+ pages, sectionner automatiquement ; en cas de volume ambigu ou de suspicion de deck long, demander une phrase. L'utilisateur n'a pas besoin de connaître les termes, le modèle décide.
• 1 Intake prioritaire au contenu (fluide) : d'abord s'assurer d'avoir le contenu – si l'utilisateur fournit une URL / fichier, exécuter d'abord node scripts/ingest.mjs <src> pour extraire le corps (extraction légère · résumé AI · ne pas contourner les paywalls · ne pas falsifier les sources) ; si texte brut, utiliser directement ; ne jamais générer sans contenu. Ensuite utiliser « cinq regards, trois décisions » pour décider de questionner, maximum 3 questions (numérotées, préciser « laisser vide = par défaut »), après quoi générer immédiatement ; si information suffisante → sauter directement la génération ; si l'utilisateur dit « fais une première version » → générer un brouillon avec des hypothèses raisonnables et les annoter (porte de sortie).
• 2 Couleur d'accentuation : une phrase pour rappeler de choisir la tonalité de base (vert défaut / bleu / jaune), sinon aller en vert – c'est la seule étape de l'intake qui nécessite l'intervention esthétique de l'utilisateur.
• 3 Brief de conception : avant de générer, confirmer la direction par écrit (jugement central + point anti-intuitif + scénario pour le public + table des rythmes de page avec 🔴/🟡/⚪) – offrir un point de recul, contrainte transparente sans boîte noire.
• 4 Choisir les mises en page : Cadre SIGNAL pour la narration, ne piocher que dans la liste blanche sémantique de 14 éléments, chaque page avec data-layout + data-role (references/02).
• 5 Rédiger le texte : Titre = phrase de jugement, takeaway (« X a triplé en 4 ans » pas « Graphique des tendances X »), ne pas terminer par un point d'interrogation (sauf page de citation phare).
  • Budget contenu (ne pas casser si long) : Titre respecte le budget de largeur par mise en page ; pages tableaux/listes respectent le budget de lignes (ex. info-data data-table ≤5 lignes de données, data-kpi exactement 3 ; compute evidence-wall ≤4 cartes, decision-matrix ≤6 lignes ; constructivist evidence ≤4 cartes, compare ≤8 points · section-divider nom le plus serré ≤16 caractères) ; si dépassement, condenser le titre / paginer / reformuler, ne pas forcer la mise en page (choix contractuel, pas d'échelle) – si dépassement, validator reporte P1 (règle [data-theme][layout] pour les budgets). Les valeurs précises sont dans references/content-budgets.md.
• 6 Générer : Choisir le seed selon la persona (un deck = une persona · 7 choisir 1 pas de mélange · selon la persona déterminée à l'étape 0, prendre le templates/deck-<key>.html correspondant dans le tableau ci-dessus). Produire un fichier unique ; utiliser les tokens du bloc thème correspondant dans 00-tokens-locked.md ; signature selon les spécifications de cette persona, marque blanche (couche visible ne révèle pas le nom de code interne / pas d'emoji) ; détails cachés selon references/04.
  • Images (arbre de décision · voir scripts/image-gen.mjs) : Par défaut, graphiques CSS/SVG de signature (la plupart des decks zéro bitmap · zéro dépendance). Quand une image bitmap est nécessaire pour l'ambiance / la métaphore / le hero – d'abord exécuter node scripts/image-gen.mjs detect pour détecter l'environnement de génération d'image : ① si retour codex-native → essayer d'appeler directement par nom le skill imagegen natif (try-and-catch · si succès utiliser · si erreur, dégrader) ② si retour third-party:<backend> → node scripts/image-gen.mjs generate "<prompt>" out.png (env gate · OpenAI v1) ③ si retour none → informer clairement l'utilisateur « Aucun environnement de génération d'image détecté. Vous pouvez configurer IMAGE_BACKEND+clé / ou utiliser image-gen.mjs search "<query>" out.png pour prendre des images libres Openverse CC0 (attribution automatique dans SOURCES.md) / ou utiliser CSS·SVG. ». Chaque image AI passe par les trois portes du craft (cohérence thématique = couleur --accent + quasi-noir / espace pour le texte / style = ADN de la persona · cohérence du contenu · si qualité faible, regénérer) ; ne jamais insérer silencieusement d'images génériques (anti-slop · constitution). Ne pas falsifier de vraies données / logos / captures / personnes (utiliser des graphiques + « illustratif » ou demander à l'utilisateur). La recette du prompt art-direction se lit dans references/03.
• 6b Sous-ensemble de polices (réponse à « comment couvrir 100% du contenu utilisateur ? ») : Si le deck contient du chinois, exécuter BLCAPTAIN_FONT_SRC=<répertoire source complet> node scripts/subset-fonts.mjs <file> – sous-ensembler tous les poids CJK à partir de la police source complète selon les caractères réellement visibles dans le deck → woff2 propre au deck (couverture by construction, pas de jeu de caractères partagé/fixe). La configuration complète de la source (une fois sur la machine de développement, OFL) est décrite dans le script avec l'indication de source manquante ; les decks purement latins à axe variable passent automatiquement.
• 7 Exécuter le validateur : node scripts/validate-deck.mjs <file>, livrer seulement si P0=0, corriger les P1, P2 en option.
• 8 Audit final 32 dimensions : vérifier chaque dimension ligne par ligne, ◐ obligatoire ; puis produire un rapport d'audit (P0/P1/P2 + traitement) + texte de couverture ; en dernière ligne, une porte de validation subjective : « Oserais-tu le diffuser/présenter directement ? ».

Vrais embranchements (80% des utilisateurs tombent là, pas seulement dans le flux principal) :

• Flux B : Info insuffisante → max 3 questions (numérotées, laisser vide = défaut), après quoi générer immédiatement.
• Flux C : Contenu « sale » (le plus susceptible de déclencher un incident de contrefaçon) → détection de capture d'écran, condition déclenchant « les trois questions pour voir l'objet » (que veux-tu prouver / est-ce authentique ou annoté / y a-t-il des infos sensibles à masquer).
• Flux D : Demande hors limites → refuser + expliquer + proposer une alternative (ne pas nier l'objectif, seulement le chemin : réel + « illustratif » > faux ; placeholder SVG fait maison > fausse capture / faux logo ; données réelles avec source > chiffres inventés jolis).

Processus métier des images (routage par rôle · pas de solution unique)

Lors de la mise en page, chaque emplacement d'image détermine d'abord son rôle, puis suit le canal correspondant :

Rôle	Chaîne de priorité	Règle d'airain
Preuve/réel (capture d'écran produit · données réelles · logo · personne réelle)	① Fourni par l'utilisateur → ② Demandé à l'utilisateur → ③ Source publique réelle (avec licence) → ④ Repli vers graphique/mise en page pure	Jamais d'AI falsifié ; les données sont toujours rendues sous forme de graphiques ; les captures d'écran utilisateur sont encadrées selon references/05-screenshot-framing.md avec CSS sans dépendance (encadrement sans modification du contenu · respecter l'anti-contrefaçon)
Ambiance/métaphore/motif (hero couverture · fond de chapitre · illustration · décoration · icône)	① Graphiques CSS/SVG de signature (la plupart des decks par défaut · zéro dépendance · style = ADN de la persona) → ② Image AI (d'abord image-gen.mjs detect pour détecter l'environnement · codex-native try / third-party env gate · concordance thématique craft 3 portes) → ③ Banque d'images libres (image-gen.mjs search · Openverse CC0 · attribution automatique)	Anti-slop par le craft · ne jamais insérer silencieusement d'images génériques

• Pourquoi CSS/SVG-first (étalonnage) : La plupart des « images » des decks sont en fait des graphiques de signature (iso-compute, lignes de contour, cercle zen, place rouge, graphiques) → construction programmatique CSS/SVG, zéro dépendance zéro licence, style = ADN de la persona, toujours contrôlable. Générer une image générique par défaut = niveler la différenciation (AI slop est le mot de l'année 2025 · empreinte = « interchangeable avec les concurrents »). L'image AI est l'étape supérieure quand une bitmap du monde réel est nécessaire (d'abord détecter l'environnement) ; le stock est une alternative pour les scènes photoréalistes.
• Déclenchement intake : Quand le contenu suggère un besoin de preuve réelle, demander « As-tu une vraie capture / des données à mettre ? », sinon ne pas interrompre (principe d'interruption minimale).
• Gouvernance : imageRequest (terme de recherche + priorité + recadrage/droits d'auteur) ; appliquer un « style » uniforme (duotone / teinte par thème) ; SOURCES.md enregistre la source/licence, non vérifié = UNVERIFIED ; couverture sans image et sans repli possible → erreur (ne pas forcer la mise en page sans image) ; les images AI portent une provenance + data-image-disposition.
• Chaîne de repli : Image AI / Image réelle / Stock → SVG → Mise en page pure/Graphique, tous sont des états finaux acceptables.

⚠ Le cadre SIGNAL suivant + la liste blanche de 14 mises en page + les contraintes dures sont détaillés à l'aide de l'exemple « Technical Sublime (compute) » ; les 6 autres persona ont leur propre cadre narratif + bibliothèque de mises en page + portes de vérification machine (les mises en page/portes de chaque persona sont entièrement couvertes par le validateur · les détails de conception sont intégrés dans leur modèle de deck). Suivre la mise en page/portes du modèle de deck de la persona choisie – mais anti-contrefaçon, tokens seulement, nombre de pages dicté par le contenu, marque blanche, validation machine P0=0, audit 32 dimensions sont des lois universelles pour toutes les persona.

Cadre narratif SIGNAL (signal → action en 6 étapes · exemple Technical Sublime)

Lettre	Signification	Cette étape répond à	data-role (mise en page) correspondant
S — State (État des lieux)	Que se passe-t-il maintenant ?	Lancer la phrase de jugement la plus importante en une phrase	state (signal-cover)
I — Insight (Perspicacité)	Quel angle les autres ne voient pas ?	Quel est le point contre-intuitif ?	insight (paradigm-shift / context-map)
G — Ground (Preuve)	Pourquoi te croire ?	Trois faits/captures/indicateurs + sources	ground (evidence-wall / kpi-wall / timeline-impact / screenshot-intel)
N — Narrow (Rétrécir)	Où sont les risques et les limites ?	Quelles variables pourraient invalider le jugement ?	narrow (risk-radar / decision-matrix)
A — Act (Agir)	Que faire ensuite ?	Verdict + priorités	act (final-move / opportunity)
L — Leave (Arrière-goût)	Que retenir ?	Une phrase de citation à capturer	leave (social-card)

Séquence standard pour un rapport de bataille de 8 pages : signal-cover → context-map → paradigm-shift → evidence-wall → timeline-impact → risk-radar → final-move → social-card.

Liste blanche des mises en page sémantiques (14 au total, le validateur vérifie là-dessus)

signal-cover · context-map · paradigm-shift · evidence-wall · timeline-impact · decision-matrix · risk-radar · opportunity · screenshot-intel · kpi-wall · final-move · social-card · section-divider (séparateur de section / acte) · agenda (table des matières / ordre du jour)

Le validateur ne vérifie pas seulement que le nom est dans la liste blanche, mais aussi que l'ensemble du deck contient au moins une page de chaque rôle data-role=state/ground/act (signal/preuve/action sont indispensables). Les spécifications détaillées des mises en page se trouvent dans references/02-layout-library.md.

Nombre de pages et sections (pas de nombre fixe · dicté par le contenu · long deck avec actes)

Le nombre de pages est toujours déterminé par le contenu, pas fixé ; le workflow prend en charge les spécifications de l'utilisateur. Trois niveaux :

Nombre de pages	Structure	Points clés
≤12 (zone de confort ~10 par défaut)	Arc SIGNAL unique, pas de section	Le plus incisif ; la plupart des rapports de bataille/observations/roadshows tombent ici. Ne pas diluer – si le contenu suffit pour 10 pages, n'en faites pas 20
13–25	Sections : 3–5 actes, chaque acte = 1 section-divider (🔴 ancre énergétique + reproduction du champ d'équivalence de signature) + 3–6 pages de contenu ; peut ajouter un agenda en début	SIGNAL passe à deux niveaux : acte → page ; chaque phase du même arc est développée sur plusieurs pages (ex. 6 evidence-wall)
>25	Recommandé diviser en plusieurs decks, ou le contenu est un document/rapport (le skill ne le fait pas)	Éviter l'enfer des 50 diapos

• Quand demander à l'utilisateur : Si le volume est ambigu ou si l'utilisateur sous-entend « détaillé/complet/long » → une phrase demander « Version concise ~10 pages, ou version longue plus détaillée avec sections ? » (défaut : concis). Si l'utilisateur donne explicitement le nombre de pages, l'appliquer, sans contre-questionner.
• La courbe d'énergie s'adapte au nombre de pages : section-divider est naturellement un point 🔴, satisfaisant automatiquement la règle « pas plus de 4 pages retenues consécutives » ; la signature se répète sur chaque page de section = satisfait R5 « contacts sur 5+ points ».
• Pagination / X / N / barre de progression / bornes de signature s'adaptent automatiquement à N, sans dépendre d'un nombre fixe.
• Indépendant de la persona : Le nombre de pages déterminé à l'étape 0 + les règles de section de cette section s'appliquent également à toutes les persona. Le constructivisme utilise section-divider (séparation de place) comme ancre d'acte, avec 9 mises en page (cover/statement/evidence/compare/kpi/process/final/social-card + séparateur) remplies en boucle dans les actes ; déjà prouvé : deck 20 pages 3 actes → P0=0 / spectre énergétique · mises en page consécutives · couverture des polices OK. ≤12 arc unique, 13–25 sections, >25 diviser, le constructivisme suit la même règle.

Stratégie de clarification (cinq regards, trois décisions · quand questionner, quand sauter)

• Informations suffisantes (public + jugement central déjà donnés) → sauter les questions, utiliser les valeurs par défaut, générer directement.
• Informations insuffisantes → maximum 3 questions à fort levier, préciser « laisser vide = défaut », après quoi générer immédiatement, sans insister.
• Incontournable (max 3) : Q1 voir la personne (à qui ? changer quel jugement ?) | Q2 voir le contexte (où regardé ? besoin de diffuser sur les réseaux sociaux, décider si la capture seule est possible) | Q3 voir l'objet (conditionnel, si détection de capture : que veux-tu prouver ? authentique ou annoté ?).
• Jamais demander : hex de couleur / police / numéro de mise en page / taille de police / espacement – ce sont les responsabilités du réalisateur, couvertes par les tokens + la liste blanche de mises en page ; demander cela révélerait « tu ne sais pas concevoir ».

Valeurs par défaut raisonnables (si manquant, prendre la valeur par défaut sans interrompre l'utilisateur ; les valeurs par défaut doivent être bonnes à 80% sans modification)

Dimension	Valeur par défaut
Style (data-theme)	instrument-cool (clé de thème de la persona compute)
Couleur d'accentuation (data-accent)	Rappeler à l'utilisateur à l'intake ; défaut night-cyan (#3FD6C2) ; par scénario : lancement produit → deep-blue (#3D7BFF), débriefing risque → safety-amber (#FF8A3D). Un deck = une tonalité de base
Nombre de pages	Déterminé par le contenu, pas fixe ; zone de confort ~10 pages (8–12), pas trop ; si l'utilisateur spécifie, exécuter ; 13–25 pages = sections automatiques avec section-divider ; >25 → recommandé de diviser ou c'est un document (hors périmètre)
Ratio	16:9 (planche 1280×720)
Polices	Occidental/chiffres Geist Sans + Geist Mono ; Chinois Glow Sans SC (OFL · woff2 local · pile Latin-first) ; ensemble « sans-sérif + mono + noir chinois »
Graisse de police	Fine Regular 400 (house style élancé pour hero / titre / corps unifié ; l'ancien --w-title:510 est obsolète)
Signature	Champ d'équivalence iso-compute : hero couverture + borne fin + badge wordmark
Couverture	Hybride : image AI par défaut (cyan) + double masque + ombre portée titre ; fond SVG iso-compute colorable pour bleu/ambre (doit être préchargé pour éviter le décalage de chargement)
Couleur d'ancrage	Couleur de signal unique (accent ≤10%, ne point qu'à un seul endroit à lire)
Coins arrondis	0px (angles droits partout)
Dégradés	Aucun (lumière froide fond noir pur ; version initiale interdit les dégradés de signature)
Public	Lecteurs avertis du secteur, avec connaissances de base, qui regardent 2-3 minutes
Titre de couverture	Tirer du jugement central une phrase de 12-18 caractères, sans nom de produit
Authenticité des données	Pas de données → ne pas inventer, marquer « illustratif / observation / spéculation » + data-evidence-type

Ordre de lecture des fichiers (divulgation progressive · lire les références selon les besoins, pas tout en une fois)

Les 7 seeds de deck (templates/deck-{compute,constructivist,info-data,luxury,de-stijl,editorial,zen}.html) intègrent tous les tokens, mises en page, signatures, JS de navigation, CSS d'impression en inline ; la référence phare est deck-compute.html. Lire les couches de référence suivantes selon les besoins :

• Valeur unique des tokens (pour coller) → lire references/00-tokens-locked.md (tokens de design + mesures de contraste WCAG réelles + installation/fallback des polices ; coller directement le bloc TOKENS dans le deck).
• Voir l'ADN visuel (comment la persona Technical Sublime est construite, how + why) → lire references/01-instrument-cool-dna.md.
• Voir comment écrire les mises en page (fonction narrative / champs obligatoires / règles visuelles / nom data-layout) → lire references/02-layout-library.md.
• Gérer les images / faire la couverture wow (données = image / duo-tone sRGB / grain uniquement pour l'ambiance couverture / ne pas falsifier les sources) → lire references/03-art-direction.md.
• Système de graphiques (recettes de rendu des graphiques de données / utilisation de chart-render) → lire references/05-chart-system.md.
• Encadrement des captures d'écran utilisateur (CSS sans dépendance · par persona · encadrement sans modifier le contenu · respecter l'anti-contrefaçon) → lire references/05-screenshot-framing.md.
• Budget contenu (valeurs par mise en page pour ne pas casser si long) → lire references/content-budgets.md.
• Détails cachés pour l'auto-vérification finale (tabular / trois niveaux de luminosité / vrai signe de multiplication / espacement négatif / micro-animations / reduced-motion) → lire references/04-hidden-details.md.
• Exemples vivants (7 persona · tous 20 pages) → templates/deck-<key>.html (voir tableau « 7 persona » ci-dessus) ; exemples de brouillons dans examples/.
• Détection d'environnement de génération d'image / repli (codex-native try / third-party env gate / Openverse CC0 / SVG fallback) → exécuter scripts/image-gen.mjs detect|generate|search (ne pas lire le script comme référence dans le contexte).
• Règles d'auto-vérification → exécuter scripts/validate-deck.mjs (ne pas lire le script comme référence dans le contexte).
• Ingestion de contenu (URL / fichier / collage → corps propre · alimenter étape 1 · ne pas contourner de paywall · ne pas falsifier les sources) → exécuter scripts/ingest.mjs <src>.
• Évaluations / cas limites → lire evals/prompts.csv.

Validation (à faire, pas seulement lire)

Exécuter (le code n'entre pas dans le contexte) : node scripts/validate-deck.mjs path/to/deck.html Sortie JSON par défaut : {file, slides, status, summary:{p0,p1,p2}, issues, next_actions}. P0 doit être 0 pour livrer ; si échec → corriger selon les issues → réexécuter jusqu'à p0=0 (code de sortie 0).

Contraintes dures (clés · entrent dans le validateur ou la discipline de génération)

P0 (ligne rouge · bloque la livraison)

• Chaque page doit avoir data-layout (dans la liste blanche sémantique de 14).
• L'ensemble du deck doit avoir au moins une page de chaque data-role=state, ground, act (signal/preuve/action sont indispensables).
  • Exception : si le deck n'a qu'une seule page et que sa mise en page est social-card, la vérification des trois rôles est sautée (déjà intégré dans le validateur).
• Les couleurs doivent utiliser des tokens (var(--…)), aucun hex brut en dehors du bloc TOKENS.
• Chaque bloc de preuve doit avoir une valeur data-evidence-type valide (fact/observation/inference/illustrative) ; une valeur invalide est P0.
• Zone de mort de lisibilité de la couleur accentuée : si --accent a un ratio de contraste < 3.0:1 (seuil WCAG pour grands textes) contre --bg/--surface/--surface-2 → P0 (empêche « couleur acide illisible »).
• Marque blanche : Le texte visible (<title>/pied de page/signature/credits) ne doit pas contenir blcaptain / Technical Sublime / instrument-cool ni autres noms de code internes ; signature = fournie par l'utilisateur ou laissée vide.
• Couverture des polices : Chaque caractère CJK visible dans le deck doit être présent dans le cmap de la police packagée (sous-ensemble selon le contenu à la génération, voir étape 6b) ; un caractère manquant = P0 – sinon repli silencieux sur la police système → aspect cassé (loi d'airain ⑤ · validateur vérifie automatiquement sans dépendance via le cmap woff2).

P1 (à corriger · recommandé avant livraison)

• Chaque page doit avoir .intel-stamp (timbre de renseignement, empreinte visuelle signature 1) ; social-card exempté, utilise .social-mark barre de signature.
• Les decks utilisant .kpi-slot : les chiffres KPI doivent avoir tabular-nums (déclarer font-variant-numeric:tabular-nums sur .kpi-slot ou .kpi-num, axiome machine 4).
• Familles de polices ≤ 2 familles corps/sans-sérif + 1 mono pour signal = 3 (Technical Sublime n'utilise en fait que Geist Sans + Geist Mono = 2).
• Pas plus de 3 pages consécutives avec le même data-layout (fluctuation d'énergie).
• Les pages de graphiques de données / grands chiffres doivent porter une source ou une mention « illustratif » (ligne rouge anti-contrefaçon).
• Les images doivent être placées dans figure[data-slot] avec un data-ratio valide (16:9/4:3/1:1/3:4/9:16) ; img doit avoir un alt non vide.
• Les mises en page de preuve (evidence-wall/kpi-wall/screenshot-intel) doivent avoir chaque .card déclarant data-evidence-type.

P2 (optimisation optionnelle · ne bloque pas)

• La densité de mots est classée par data-scene (social≈60 / report≈150 / deck≈120, défaut 120).
• Heuristique des titres « phrase de jugement » : si le titre se termine par un point d'interrogation et que ce n'est pas une page de citation phare → alerte.

Trois empreintes visuelles de signature (détails cachés, les initiés reconnaissent tout de suite ; voir références/04)

1. Timbre de renseignement (.intel-stamp) : barre d'information mono en position fixe en bas à droite de chaque page, code de scène · date · page/total, comme un colophon de document technique.
2. Chiffres en tabular : tous les chiffres KPI/tableaux en font-variant-numeric:tabular-nums lining-nums, alignement des virgules pour former des colonnes verticales (le signal le plus rentable pour les initiés).
3. Étiquette de niveau de preuve (.chip) : chaque bloc de preuve déclare fait/observation/spéculation/illustratif ; illustrative utilise la couleur spéciale --illus pour rappeler de ne pas prendre au sérieux.

Rythme (l'énergie vient des fluctuations, le volume selon le contexte, pas de « claquer » par défaut)

• « Claquer » n'est pas une exigence dure. Le pouvoir de persuasion vient des fluctuations de l'énergie, pas d'une haute énergie constante ni d'une platitude continue – le silence doit être absolu quand il le faut, le bruit réservé quand il faut, déterminé par le public et le contexte (courbe de tension Duarte : créer une tension entre ce qui est ↔ ce qui pourrait être).
• 🔴 Pages fortes (couverture/chapitre/citation phare/hero de données) : un élément principal occupe ≥50% de l'écran, unité d'information = 1, taille de police au niveau hero, accent ose pointer les mots-clés.
• 🟡 Pages semi-fortes (changement de paradigme/fenêtre d'opportunité) : fort contraste mais n'occupe pas tout l'écran.
• ⚪ Pages retenues (pages de contenu) : aucun élément occupant tout l'écran (max ≤30%), 3 à 6 unités d'information mais chacune retenue, séparation fine, accent ≤10%.
• Loi d'airain : entre les pages fortes, il y a toujours des pages retenues ; pas deux pages fortes adjacentes (sauf couverture et carte réseaux sociaux, légitimes en début et fin). Une courbe d'énergie standard de 8 pages ressemble à 🔴⚪🟡⚪🔴⚪🟡🔴 ; ≥4 pages retenues consécutives = rupture de rythme.
• Le « claquer » de Technical Sublime est un « claquer retenu » : le chiffre hero KPI occupe plus de la moitié de l'écran dans une rainure, le cyan mono-signal n'illumine que cette seule case de dépassement de seuil ; zéro donnée falsifiée ; accent reste ≤10%, jamais de faux tableau de bord.

Ne pas utiliser ce skill pour

• Grands tableaux, longs manuels de formation ; documents sérieux nécessitant une relecture professionnelle (juridique, médical, financier).
• Présentations PowerPoint classiques nécessitant une collaboration multi-utilisateurs ; résumé textuel pur uniquement.
• Reproduction de la communication visuelle officielle d'une marque ; invention de données semblant réelles.

Ce qui n'est pas fait dans la version initiale (honnêtement informer, contournement temporaire)

Exportation précise PPTX/PDF (utiliser Ctrl+P du navigateur pour le PDF, pour un exact 16:9 il faut régler manuellement le papier à 1280×720/marges 0/cocher les graphiques de fond), édition en ligne, connexion utilisateur, bibliothèque d'animations complexes. L'exportation PPTX modifiable nativement est sur la roadmap (scénario entreprise « modifier le texte dans PowerPoint » · voir README).