umarmsharif/strategy-deck-builder

Que fait strategy-deck-builder ?

Une compétence pour construire des decks de qualité consulting, ancrée sur le système de design v5 Bright White & Pine — un fond blanc lumineux presque pur (FCFCFA), un accent vert pin profond (12564A), du texte couleur espresso-INK (1A1A1A), une police d'affichage par deck (Charter par défaut) associée à Manrope pour le corps, l'emphase portée par des filets et le poids de la police plutôt que par des barres colorées, livraison prioritaire en PPTX. Le système a été conçu pour éliminer les motifs désormais largement perçus comme des marqueurs de conception IA — fonds crèmes chauds, police unique partout, barres d'accentuation unilatérales, étiquettes « eyebrow », grands numéros de section. La posture anti-« slop » fait partie de l'ADN : voir references/anti-slop.md (le catalogue du « slop » appliqué à la pertinence du deck) et les vérifications statiques dans scripts/deck_qa.js.

L'implémentation de référence canonique est assets/reference-build.js — un exemple complet pptxgenjs testé en rendu. Ouvrez-le pour faire correspondre l'intention de la diapositive, puis copiez des blocs. La bibliothèque complète de recettes, les fonctions d'aide et le tableau des pièges se trouvent dans references/build-helpers.md.

Quand déclencher

Utilisez cette compétence de manière proactive pour tout ce qui suit :

• Decks stratégiques, pitch decks, livrables de conseil, réponses à des études de cas
• Présentations au conseil, briefings de direction, feuilles de route, plans de transformation
• Analyses d'entrée sur le marché, decks de diagnostic, decks de recommandation, résumés exécutifs
• Tout ce où l'utilisateur fait référence au « style consulting », « MBB-style », « McKinsey-style », « Bain-style », « BCG », ou nomme un cabinet réel
• Tout deck client soigné où l'utilisateur souhaite un résultat de qualité marque avec une prose nette

Le workflow

Suivez ces étapes dans l'ordre. Les passerelles anti-« slop » pré et post-vol sont non-négociables.

Étape 0 — OBLIGATOIRE vol préliminaire anti-« slop »

Cette compétence produit une prose qui doit survivre à un lecteur sceptique. Avant de rédiger le moindre texte de diapositive, notes de l'orateur, ligne de thèse, lignes de contexte ou texte de briefing, lisez references/anti-slop.md pour calibrer le langage contre les marqueurs IA qui font qu'un deck est lu comme écrit par une machine.

Après avoir lu, maintenez ces contraintes lors de la rédaction :

• Pas de tirets cadratins sauf s'ils font un travail spécifique que vous pouvez défendre (un maximum par page)
• Vocabulaire zéro remplissage-buzzword (delve, leverage, robust, seamless, transformative, paradigm, cutting-edge, game-changer, et le reste du catalogue dans anti-slop.md)
• Pas de parallélismes négatifs (« ce n'est pas X, c'est Y » ; « non seulement A, mais B »)
• Phrases de moins de 30 mots ; noms concrets et nombres spécifiques plutôt que des abstractions
• Titres d'action, pas titres de sujet (la règle la plus importante — voir slide_patterns.md)

La construction structurelle peut être parfaite et le deck sera quand même dévalorisé dès que la prose sera lue comme du consulting-AI générique. Cette passerelle existe pour empêcher cela.

Étape 1 — Brief du deck

Utilisez AskUserQuestion (ou demandez en ligne là où l'outil n'est pas disponible) avec deux appels consécutifs avant d'écrire une seule diapositive ou ligne de build.js :

Appel 1 — Configuration du deck :

1. Audience + objectif — qui lit ceci, et quelle décision ou action voulez-vous d'eux ?
2. Archétype du deck — diagnostic / recommandation / feuille de route / entrée sur le marché / transformation / pitch / scqa / scr / bluf / inductif / arbre à problèmes / déductif. Le deck peut être simple (un archétype tout au long) ou en couches (un archétype colonne vertébrale + des surcharges au niveau des sections). S'il est en couches, décidez quel archétype couvre quelle plage de diapositives et respectez-le ; ne le réduisez pas à une seule forme.
3. Format de sortie — pptx / html / md / gamma / briefing (sélection multiple ; défaut : pptx)

Appel 2 — Marque + brief visuel :

1. Schéma de couleurs — demandez par intention (accent seulement ; le fond blanc lumineux + les neutres froids restent fixes). Proposez : Pin 12564A (défaut ; calme, moderne, croissance) / Bleu ardoise 1F3A5F (entreprise, finance, confiance) / Rouge oxblood 6E1423 (formel, institution) / Couleur hex client (travail verrouillé à la marque). Le choix définit ACCENT et dérive ACCENT_DK (~70% luminance) + TINT (~8% sur blanc) + TINT_BORDER. La teinte de l'oxblood penche légèrement vers le rose — réchauffez-la si choisie. Les valeurs de schéma validées se trouvent dans design_system.md §1.
2. Police d'en-tête — demandez par intention (le corps reste Manrope ; seule la police de titre change). Proposez : Charter (serif éditorial, défaut, rendu propre partout) / Manrope Bold (moderne, tout sans-serif, pas de serif) / Palatino (serif chaleureux) / Baskerville (serif formel ; meilleur dans PowerPoint/Google Slides, plus faible dans l'aperçu LibreOffice). Le choix définit DISPLAY, et DISPLAY_BOLD=true pour l'option tout sans-serif. Toute police installée avec du caractère est acceptable si elle est en dehors de la liste des sur-utilisées (Inter, Roboto, Fraunces, Geist, Plus Jakarta, Space Grotesk). Un choix tout sans-serif accepte consciemment l'avis de famille unique — voir references/anti-slop.md.
3. Marque + brief de contenu — nom du client/entreprise, présentateur, date, et une idée approximative diapositive par diapositive (même des notes en points sont bonnes ; Claude structure).

Le schéma se trouve dans assets/inputs.example.json. Le nombre de diapositives n'est PAS une entrée obligatoire — laissez-le découler de l'entretien sur le contenu et de l'archétype. Par défaut 8–12 pour les decks exécutifs, 15–18 pour les analyses plus approfondies, 26+ pour la synthèse de master-deck.

Écrivez inputs.json à partir des réponses avant de toucher à tout script de construction. Garder les entrées séparées du script de construction signifie que le même script gère chaque futur deck.

Étape 1.5 — OBLIGATOIRE ghost deck avant toute rédaction de contenu

Avant de remplir les corps de diapositives, panneaux, points, lignes de gantt, ou toute prose : émettez une version ghost deck de inputs.json avec seulement :

• title_slide rempli
• slides[i].breadcrumb, slides[i].title, slides[i].context remplis (les titres doivent être des titres d'action — voir Conventions universelles dans slide_patterns.md)
• slides[i].layout choisi (Claude choisit de manière décisive dans le pool filtré par archétype)
• Tous les blocs slides[i].content laissés vides {} ou avec seulement des noms de champs fictifs

Présentez le ghost deck comme un tableau avec les colonnes : # | Section / archétype | Breadcrumb | Titre d'action | Mise en page | Ligne de contexte (1 phrase) | Visuel / données principal (test 5 secondes).

La colonne Section / archétype rend visible la structure en couches en un coup d'œil. Pour les decks simples (un archétype tout au long), chaque ligne porte la même valeur (par exemple — / diagnostic). Pour les decks en couches, la colonne nomme la section à laquelle appartient la diapositive et l'archétype que cette section exécute — par ex. Build case / inductif, Sequence play / feuille de route, Close ask / bluf. Les limites des sections deviennent visuellement évidentes (les lignes adjacentes partagent une étiquette de section ; le changement marque la rupture).

Puis utilisez AskUserQuestion (ou demandez en ligne) avec ces questions :

1. L'arc narratif tient-il à travers les sections ? (Approuver tout / Réviser des diapos spécifiques / Restructuration majeure)
2. Un titre qui n'énonce pas un « et alors » ? (Listez les numéros de diapos à corriger, ou « tout bon »)
3. Un choix de mise en page qui semble erroné pour le travail de sa diapositive — y compris une diapositive dont la mise en page contredit l'archétype de sa section ? (Listez les numéros de diapos, ou « tout bon »)
4. Une ligne de contexte ou une description visuelle qui manque un détail critique ? (Listez les numéros de diapos, ou « tout bon »)

Attendez un feu vert explicite avant de rédiger tout contenu de corps. Si l'utilisateur demande des modifications, mettez à jour le tableau du ghost deck et redemandez — ne passez pas à l'Étape 1.6 tant que l'utilisateur n'a pas dit « tout bon » ou équivalent.

Pourquoi cela existe : il est plus rapide de jeter 10 titres de diapositives que 10 diapositives terminées. La discussion sur la structuration Pyramid Principle / SCQA se déroule ici, sur la version bon marché. Sauter cette étape est la raison la plus courante pour laquelle un deck fini doit être reconstruit, et c'est aussi ainsi que des diapositives héros clairsemées s'infiltrent là où des motifs de cheval de bataille denses devraient être.

Choix des motifs à l'intérieur du ghost deck : Claude choisit les mises en page de manière décisive dans le pool filtré par archétype (scripts/pattern_filter.js --archetype=<valeur>). N'utilisez AskUserQuestion que pour faire émerger un choix lorsque deux motifs sont vraiment à égalité sur l'adéquation du contenu ou lorsque l'utilisateur a exprimé une préférence de goût plus tôt. Le choix granulaire diapositive par diapositive produit 10 à 12 demandes forcées par deck sans gain de qualité proportionnel ; évitez-le.

Garde de monotonie (sélecteur opt-in) : en remplissant la colonne Mise en page, scannez pour deux diapositives adjacentes ou plus qui partageraient le même idiome visuel — le plus souvent des barres horizontales (voir references/slide_patterns.md → « Variez l'idiome de barre entre les diapositives adjacentes »). Lorsque vous trouvez une séquence, soit variez le traitement vous-même, soit soulevez le sélecteur d'aperçu pour la diapositive qui se répète : un AskUserQuestion avec la mise en page recommandée en premier (étiquetez-la (Recommandé)), puis 2 alternatives sûres pour le rendu, chacune portant un petit mini-maquette ASCII de la mise en page dans le champ preview de l'option afin que l'utilisateur choisisse à partir d'images, pas de noms de motifs. Cela reste opt-in — il se déclenche sur une répétition détectée, une égalité réelle, ou un « quelles sont mes options » de l'utilisateur, pas sur chaque diapositive. C'est l'équivalent économique du mode Variation de l'Étape 4.5 : rien n'est construit tant que l'utilisateur n'a pas choisi.

Sautez l'Étape 1.5 uniquement si l'utilisateur a déjà fourni un inputs.json complet ou a explicitement écrit « sautez le ghost deck ». Sinon, c'est non-négociable.

Étape 1.6 — Discipline de création par diapositive (5 étapes)

Pour chaque diapositive, remplissez le schéma dans cet ordre. Ne sautez pas d'étape.

1. Message — écrivez slides[i].title d'abord. Il doit être un titre d'action (le « et alors »). Si vous ne pouvez pas écrire le titre, vous ne comprenez pas encore à quoi sert la diapositive.
2. Structure — choisissez slides[i].layout dans le catalogue qui soutient le titre. Par défaut, utilisez des motifs de cheval de bataille denses (diagnostic-three-panel, prioritisation-matrix, phased-roadmap-gantt, three-col-comparison, waterfall-baseline-to-target). Utilisez des condiments clairsemés (stat-row, big-numeral-findings) uniquement comme ponts de section, jamais comme le gros du deck.
3. Graphiques / visuels principaux — remplissez slides[i].content. Le visuel doit être lisible en 5 secondes. Pour les matrices : où se trouvent les points ? Pour les gantts : quels flux de travail se chevauchent ? Pour les waterfalls : quel poste domine ?
4. Support — remplissez slides[i].context (cadre d'une phrase avant que les données n'arrivent) et slides[i].footer_note (source + réserve). Les deux sont non-négociables sur les diapositives de données.
5. Polissage — géré par scripts/check_titles.js + Étape 7 vol postérieur anti-« slop » + Étape 8 passerelle de livraison flight-check. Exécutez avant la livraison.

Choisir la mise en page avant le message est ainsi que les diapositives héros clairsemées s'infiltrent. Choisir les visuels avant la mise en page est ainsi que les graphiques finissent par ne pas soutenir leurs titres. Polir avant le contenu est un travail perdu. L'ordre compte.

Référence complète : references/methodology/slide_creation_process.md.

Étape 2 — Lire le système de design + les motifs

Lisez toujours (chaque construction), dans cet ordre :

1. references/design_system.md — palette/typographie/anatomie verrouillées. Ne déviez pas sans raison.
2. references/slide_patterns.md — le catalogue maître des motifs + conventions universelles (titres d'action, couleur sélective, honnêteté des graphiques, ordre des barres/colonnes, direct-étiquette, cercles d'échelle de zone, discipline des pieds de page, règles spécifiques aux waterfalls).
3. references/build-helpers.md — constantes de palette, les aides header()/title()/footer(), chaque recette de motif (§2.x), et le tableau des pièges. La référence d'implémentation pour chaque construction. assets/reference-build.js est l'exemple travaillé qui exerce celles-ci.
4. references/methodology/content-interview.md — cadre d'entretien sur le contenu (situation → problème → hypothèse → preuve → argument → réponse). Exécutez la Phase 1 avant de toucher à tout script de construction.

Lisez à la demande (uniquement lorsque le déclencheur s'applique) :

• references/chart-selection-guide.md + references/chart-library/ — lorsqu'une diapositive a besoin d'un graphique. Piloté par l'Étape 2.5 ; ne préchargez pas.
• references/slide-job-to-layout.md — lors du choix des mises en page aux Étapes 1.5 et 4.5, pour rendre la sélection des motifs traçable plutôt qu'intuitive.
• references/raci-guidance.md — lors de la construction d'un RACI ou de toute diapositive de propriété de rôle.

Si l'utilisateur fournit un deck ou une diapositive de référence à faire correspondre, extrayez ses miniatures pour la mise en page et son texte pour la structure des sections. Traitez toute référence externe comme structure uniquement : étudiez comment elle est construite, ne copiez jamais ses mots, chiffres ou images.

Étape 2.5 — Diapositives avec graphiques : consultez la bibliothèque de graphiques + le guide de sélection

Lorsqu'une diapositive a besoin d'un graphique (barre, ligne, empilé, double panneau, barre/ligne combiné, petits multiples, waterfall, mekko), n'improvisez pas. Deux références en séquence :

D'abord, references/chart-selection-guide.md — le tableau de sélection rapide en haut fait correspondre le message prévu de la diapositive au type de graphique. Le principe : le type de graphique correspond au message, pas à la forme des données. Appliquez les conseils spécifiques au graphique (pas de 3D, lignes d'étiquettes directes, ordre logique des barres, etc.).