Consulting Deck

Que fait Consulting Deck ?

Créez des présentations prêtes à la décision, pas des résumés décoratifs. Construisez un argumentaire clair, tracez chaque affirmation matérielle, sélectionnez les mises en page en fonction de l'objectif de communication et livrez un fichier .pptx natif dont le texte, les graphiques, les tableaux et les diagrammes simples restent modifiables.

Considérez ceci comme un système de présentation indépendant créé par Peng · 智珠在睿. N'impliquez pas d'affiliation avec McKinsey, BCG, Bain ou un autre cabinet de conseil. Ne copiez pas leurs logos, modèles propriétaires ou actifs de marque protégés, sauf si l'utilisateur fournit des actifs sous licence et demande explicitement de les utiliser.

Charger les bonnes instructions

Chargez les instructions de manière progressive :

1. Commencez chaque route Créer ou Réviser avec references/harness-system.md, references/workflow.md et references/presentation-modes.md.
2. Lisez references/problem-solving-system.md pour un sujet, une question commerciale ouverte, un choix stratégique ou une demande de recherche à partir de zéro. N'imposez pas un arbre d'hypothèses à une demande de synthèse de source fidèle.
3. Lisez references/storyline-system.md lors de la construction de la pensée directrice et de la séquence de diapositives.
4. Lisez references/chart-system.md et references/charts-and-data.md uniquement lorsque des preuves quantitatives ou des visuels matériels sont présents.
5. Lisez references/visual-system.md et references/layout-library.md lors de la planification de l'échantillon de méthode et du système complet de diapositives.
6. Lisez references/quality-gates.md avant la validation et la livraison.
7. Lisez references/brand-system.md uniquement lorsqu'une marque, un logo, une police ou un modèle PPTX est utilisé.
8. Lisez references/runtime-adapters.md avant de choisir la route de production PPTX.
9. Lisez references/workspace-schema.md lors de la création, de la reprise ou de la révision d'un projet de présentation sauvegardé.

Aiguiller la demande

Choisissez exactement une route principale :

• Créer — transformer une source ou un sujet en une nouvelle présentation modifiable.
• Réviser — modifier un projet de présentation sauvegardé existant et régénérer les diapositives affectées.
• Modèle — appliquer une marque fournie par l'utilisateur ou un modèle PowerPoint natif.
• Auditer — inspecter une présentation existante sans la modifier, sauf si l'utilisateur le demande.

Ne combinez pas silencieusement les routes. Une demande de modèle peut affiner Créer ou Réviser, mais le projet sauvegardé sous-jacent reste la source de vérité.

Établir le contrat de production

Avant la création :

1. Identifiez le public, la décision, le contexte de présentation, la langue, le nombre de pages, le mode de présentation, le mode de densité, la route d'analyse et les limites de la source.
2. Utilisez la capacité PowerPoint native actuelle de l'hôte lorsqu'elle peut créer des objets modifiables et rendre chaque diapositive pour inspection.
3. Utilisez PptxGenJS uniquement comme solution de repli lorsqu'il est déjà disponible ou que l'utilisateur approuve l'installation. Ne remplacez jamais le PPTX demandé par du HTML.
4. Préservez un espace de travail de projet modifiable. Ne faites pas du fichier .pptx final la seule source de vérité.
5. Gardez la sortie par défaut neutre en termes de marque. Appliquez assets/brands/peng.json uniquement lorsque l'utilisateur sélectionne explicitement le préréglage Peng.
6. Utilisez le système d'échafaudage par étapes dans references/harness-system.md. Ne passez pas d'un fichier source directement au code de rendu de diapositives.
7. Considérez les fichiers de portes de contrôle lisibles par machine comme la source de vérité. Ne déclarez jamais qu'une porte est passée à moins que le JSON correspondant n'existe et ne contienne "passed": true.

Appliquer la norme de conseil

Exigez tout ce qui suit :

• Commencez par une pensée directrice et des titres de diapositives qui donnent la réponse en premier.
• Pour une route de résolution de problèmes, définissez les limites du problème, construisez un arbre d'analyse et maintenez des hypothèses falsifiables avant une recherche approfondie.
• Donnez à chaque diapositive un seul objectif de communication et un seul message clé.
• Assurez une logique horizontale cohérente entre les diapositives et une logique verticale suffisante dans chaque diapositive.
• Distinguez les faits, les calculs, les interprétations de sources et les hypothèses.
• Citez les affirmations et les actifs externes dans des notes de bas de page visibles ou des notes de l'orateur.
• Considérez les graphiques comme le langage analytique principal, pas une couche décorative secondaire.
• Écrivez un enregistrement charts.json déclaratif avant de rendre chaque visuel matériel.
• Utilisez les familles de graphiques basées sur les questions, le système d'annotation et la hiérarchie de rendu dans references/chart-system.md.
• Utilisez des graphiques natifs pour les données que les utilisateurs pourraient avoir besoin d'inspecter ou de modifier. Utilisez le vocabulaire visuel de Vizro et la route de prototypage optionnelle pour la sélection et la validation, pas comme permission d'aplatir le PowerPoint final.
• En mode Recherche Analytique, reconstruisez les visuels matériels de la source avant de créer des résumés conceptuels. Atteignez les seuils de graphiques natifs et basés sur les preuves dans references/presentation-modes.md.
• Utilisez une mise en page sémantique de references/layout-library.md ; n'inventez pas une mise en page simplement pour remplir l'espace.
• Utilisez l'appareil visuel « titre comme structure » uniquement sur les couvertures, les séparateurs de sections et un petit nombre de diapositives de perspectives décisives.
• Rendez et inspectez chaque diapositive en taille réelle avant la livraison.
• Gardez les vérifications automatiques et l'examen par un expert séparés. Les scripts de géométrie ne peuvent pas prouver la qualité des preuves, la véracité des graphiques ou la clarté exécutive.
• Enregistrez les prérequis réels entre les diapositives dans slides.json. Générez dans l'ordre de dépendance sûr, puis assemblez dans l'ordre d'affichage destiné au public.

Utiliser deux modes de densité

• Animé par l'orateur — moins de mots, police plus grande, plus de pages, rythme plus soutenu.
• Lecture d'abord — plus de preuves autonomes, annotations et notes de bas de page.

Choisissez un mode en fonction du contexte de présentation. Ne créez pas un mode intermédiaire vague. Lorsque le contenu ne tient pas, divisez la diapositive ou affinez l'argument avant de réduire la taille de la police.

Le mode de densité n'est pas le mode de présentation. Un Récit Exécutif en mode Lecture d'abord et un deck Recherche Analytique en mode Lecture d'abord peuvent avoir une densité de texte similaire, mais des parts différentes de visuels, notes de bas de page et pages conceptuelles.

Prévisualiser la direction visuelle

Lorsque l'utilisateur n'a pas fourni de modèle verrouillé ou de référence visuelle explicite :

1. Créez trois directions visuelles compactes à partir de references/visual-system.md.
2. Montrez une véritable couverture, une diapositive analytique/de données et une diapositive de cadre/action pour chaque direction.
3. Gardez le contenu de l'aperçu authentique par rapport au matériel de l'utilisateur ; n'affichez jamais d'étiquettes internes comme « Option A » à l'intérieur de la diapositive elle-même.
4. Demandez à l'utilisateur de choisir une seule fois, puis appliquez le système choisi de manière cohérente.

Sautez cette porte uniquement lorsque l'utilisateur demande explicitement de procéder directement ou fournit une référence visuelle claire. Enregistrez la direction choisie dans l'espace de travail du projet.

Préserver la modifiabilité

• Gardez le texte en tant que texte.
• Gardez les tableaux en tant que tableaux.
• Gardez les graphiques en tant que graphiques natifs chaque fois que possible.
• Gardez les données des graphiques et l'intention des graphiques séparées du code de mise en page des diapositives.
• Gardez les matrices simples, les chronologies, les processus et les arbres d'analyse en tant que formes natives.
• Utilisez des images pour les photographies, les œuvres d'art texturées ou les illustrations — pas pour des diapositives entières avec beaucoup de texte.
• Ne livrez jamais un deck dont les pages sont des captures d'écran aplaties.

Itérer à partir du projet sauvegardé

Pour des demandes comme « changer le titre de la diapositive 3 », modifiez la source du projet et régénérez la sortie affectée. Préservez le matériel source, les identifiants de preuves, les données des graphiques, les identifiants de diapositives et les notes de l'orateur. Réexécutez toutes les vérifications de qualité affectées et la vérification finale au niveau du deck.

Apprendre sans modifier la compétence installée

Classez chaque correction matérielle comme ponctuelle ou reproductible. Enregistrez les leçons reproductibles dans l'espace de travail du deck à qa/experience-log.md ; ne modifiez pas silencieusement la compétence installée pendant la production ordinaire de decks. Ne promouvez une leçon répétée dans cette compétence que par une mise à jour de compétence révisée et versionnée.

Livrer

Livrez le fichier .pptx final accompagné d'un résumé concis. Gardez les plans intermédiaires, les aperçus et les fichiers QA dans l'espace de travail du projet, sauf si l'utilisateur les demande. Mentionnez explicitement toute affirmation non vérifiée, substitution de police, limitation de compatibilité ou avertissement restant.