Communitygithub.com

zairuilab/consulting-deck

Evidenzbasierte, diagrammgeführte, nativ bearbeitbare PowerPoint-Skill für Consulting-Präsentationen.

Was ist consulting-deck?

Dieser Skill ermöglicht die Erstellung entscheidungsreifer Präsentationen mit klarem Argumentationsaufbau, nachvollziehbaren Behauptungen und semantisch passenden Layouts – kein reines Dekorieren. Er unterstützt die Erstellung von nativen `.pptx`-Dateien, deren Texte, Diagramme, Tabellen und einfache Grafiken vollständig bearbeitbar bleiben. Der Skill ist nützlich für Berater:innen, Analyst:innen und alle, die professionelle Folien auf Consulting-Niveau erstellen müssen. Er basiert auf einem modularen Referenzsystem, das je nach Aufgabe (z. B. Problemlösung, Storyline, Chart-Erstellung) progressive Anleitungen lädt. Der Skill vermeidet eine Assoziation mit großen Beratungshäusern und deren Markenrechten. Plattformen: Der Skill setzt auf die native PowerPoint-Fähigkeit des Hosts (z. B. Claude Code oder Cursor) für erstellbare Objekte. PptxGenJS dient nur als Fallback. Die Arbeitsweise umfasst eine Produktionsvertrags-Eingangsphase (Zielgruppe, Entscheidungskontext, Sprachmodus), eine Dichtemodus-Wahl (vortragsorientiert vs. leseoptimiert) und iterative Qualitätssicherung durch maschinelle Prüfungen und menschliche Kontrolle.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add zairuilab/consulting-deck

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Consulting Deck

Erstellen Sie entscheidungsreife Präsentationen, keine dekorativen Zusammenfassungen. Bauen Sie ein klares Argument auf, belegen Sie jede wesentliche Behauptung, wählen Sie Layouts nach kommunikativem Zweck aus und liefern Sie eine native .pptx-Datei, deren Texte, Diagramme, Tabellen und einfache Grafiken bearbeitbar bleiben.

Behandeln Sie dies als unabhängiges Präsentationssystem, erstellt von Peng · 智珠在睿. Unterstellen Sie keine Verbindung zu McKinsey, BCG, Bain oder einer anderen Beratung. Verwenden Sie deren Logos, proprietäre Vorlagen oder geschützte Markenelemente nicht, es sei denn, der Benutzer stellt lizenzierte Assets bereit und bittet ausdrücklich um deren Nutzung.

Die richtige Anleitung laden

Laden Sie die Anleitungen progressiv:

  1. Starten Sie jeden Create- oder Revise-Durchlauf mit references/harness-system.md, references/workflow.md und references/presentation-modes.md.
  2. Lesen Sie references/problem-solving-system.md für ein Thema, eine offene Geschäftsfrage, eine Strategiewahl oder einen Auftrag zur Erstellung von Grundlagenforschung. Erzwingen Sie keinen Hypothesenbaum für eine getreue Quellenzusammenfassung.
  3. Lesen Sie references/storyline-system.md beim Aufbau des Leitgedankens und der Folienabfolge.
  4. Lesen Sie references/chart-system.md und references/charts-and-data.md nur, wenn quantitative Belege oder wesentliche Anschauungsstücke vorhanden sind.
  5. Lesen Sie references/visual-system.md und references/layout-library.md bei der Planung der Methoden-Stichprobe und des vollständigen Folienaufbaus.
  6. Lesen Sie references/quality-gates.md vor der Validierung und Auslieferung.
  7. Lesen Sie references/brand-system.md nur, wenn eine Marke, ein Logo, eine Schriftart oder eine PPTX-Vorlage verwendet wird.
  8. Lesen Sie references/runtime-adapters.md vor der Auswahl des PPTX-Produktionswegs.
  9. Lesen Sie references/workspace-schema.md beim Erstellen, Wiederaufnehmen oder Überarbeiten eines gespeicherten Deck-Projekts.

Anfrage routen

Wählen Sie genau einen primären Weg:

  • Create — Erstellen Sie aus Quellmaterial oder einem Thema ein neues, bearbeitbares Deck.
  • Revise — Ändern Sie ein vorhandenes, gespeichertes Deck-Projekt und generieren Sie die betroffenen Folien neu.
  • Template — Wenden Sie eine vom Benutzer bereitgestellte Marke oder native PowerPoint-Vorlage an.
  • Audit — Überprüfen Sie ein vorhandenes Deck, ohne es zu ändern, es sei denn, der Benutzer verlangt es.

Kombinieren Sie Routen nicht stillschweigend. Eine Template-Anfrage kann Create oder Revise verfeinern, aber das zugrunde liegende gespeicherte Projekt bleibt die maßgebliche Quelle.

Produktionsvertrag festlegen

Vor dem Erstellen:

  1. Identifizieren Sie Zielgruppe, Entscheidung, Präsentationskontext, Sprache, Seitenanzahl, Präsentationsmodus, Dichtemodus, Analyseroute und Quellgrenze.
  2. Nutzen Sie die native PowerPoint-Fähigkeit des Hosts, wenn diese bearbeitbare Objekte erstellen und jede Folie zur Überprüfung rendern kann.
  3. Verwenden Sie PptxGenJS nur als Fallback, wenn es bereits verfügbar ist oder der Benutzer der Installation zustimmt. Ersetzen Sie niemals die angeforderte PPTX durch HTML.
  4. Bewahren Sie einen bearbeitbaren Projektarbeitsbereich. Machen Sie die endgültige .pptx nicht zur einzigen maßgeblichen Quelle.
  5. Halten Sie die Standardausgabe markenneutral. Wenden Sie assets/brands/peng.json nur an, wenn der Benutzer die Peng-Voreinstellung explizit auswählt.
  6. Verwenden Sie das gestufte Framework in references/harness-system.md. Springen Sie nicht von einer Quelldatei direkt zum Folien-Rendering-Code.
  7. Behandeln Sie maschinenlesbare Gate-Dateien als maßgebliche Quelle. Behaupten Sie nicht, dass ein Gate bestanden wurde, es sei denn, das entsprechende JSON existiert und enthält "passed": true.

Consulting-Standard anwenden

Verlangen Sie alle folgenden Punkte:

  • Beginnen Sie mit einem Leitgedanken und antwortorientierten Folientiteln.
  • Definieren Sie bei einer Problemlösungsroute das Problemfeld, erstellen Sie einen Problembaum und stellen Sie falsifizierbare Hypothesen auf, bevor Sie umfassend recherchieren.
  • Geben Sie jeder Folie einen Kommunikationszweck und eine Hauptaussage.
  • Sorgen Sie für kohärente horizontale Logik über die Folien hinweg und ausreichende vertikale Logik innerhalb jeder Folie.
  • Unterscheiden Sie Fakten, Berechnungen, Quelleninterpretationen und Hypothesen.
  • Zitieren Sie externe Behauptungen und Assets in sichtbaren Fußnoten oder Sprechernotizen.
  • Behandeln Sie Diagramme als primäre analytische Sprache, nicht als sekundäre Dekorationsebene.
  • Schreiben Sie einen deklarativen charts.json-Eintrag, bevor Sie jedes wesentliche Anschauungsstück rendern.
  • Verwenden Sie die fragengestützten Diagrammfamilien, das Annotationssystem und die Rendering-Hierarchie aus references/chart-system.md.
  • Verwenden Sie native Diagramme für Daten, die Benutzer möglicherweise überprüfen oder bearbeiten müssen. Nutzen Sie Vizros visuelles Vokabular und die optionale Prototyproute für Auswahl und Validierung, nicht als Erlaubnis, die endgültige PowerPoint zu vereinfachen.
  • Rekonstruieren Sie im Modus Research Analytical die wesentlichen Anschauungsstücke der Quelle, bevor Sie konzeptionelle Zusammenfassungen erstellen. Erfüllen Sie die Schwellenwerte für Evidenzführung und native Diagramme in references/presentation-modes.md.
  • Verwenden Sie ein semantisches Layout aus references/layout-library.md; erfinden Sie kein Layout nur, um Platz zu füllen.
  • Verwenden Sie das visuelle Mittel "Titel als Struktur" nur auf Covern, Abschnittsteilern und einer kleinen Anzahl entscheidender Einblicksfolien.
  • Rendern und überprüfen Sie jede Folie in voller Größe vor der Auslieferung.
  • Halten Sie maschinelle Prüfungen und Expertenüberprüfungen getrennt. Geometrieskripte können keine Beweisqualität, Diagrammwahrhaftigkeit oder Führungspräzision nachweisen.
  • Erfassen Sie echte folienübergreifende Voraussetzungen in slides.json. Generieren Sie in abhängigkeitssicherer Reihenfolge und setzen Sie dann in der anzeigenden Reihenfolge für das Publikum zusammen.

Zwei Dichtemodi verwenden

  • Vortragsorientiert — weniger Wörter, größere Schrift, mehr Seiten, stärkerer Rhythmus.
  • Leseoptimiert — mehr eigenständige Belege, Anmerkungen und Fußnoten.

Wählen Sie einen Modus basierend auf dem Präsentationskontext. Erzeugen Sie keinen vagen Zwischenmodus. Wenn Inhalte nicht passen, teilen Sie die Folie oder schärfen Sie das Argument, bevor Sie die Schriftgröße reduzieren.

Der Dichtemodus ist nicht der Präsentationsmodus. Eine leseoptimierte Executive Story und ein leseoptimiertes Research Analytical Deck können eine ähnliche Textdichte, aber unterschiedliche Anteile an Anschauungsstücken, Fußnoten und konzeptionellen Seiten aufweisen.

Visuelle Richtung vorschauen

Wenn der Benutzer keine festgelegte Vorlage oder explizite visuelle Referenz bereitgestellt hat:

  1. Erstellen Sie drei kompakte visuelle Richtungen aus references/visual-system.md.
  2. Zeigen Sie für jede Richtung ein echtes Cover, eine analytische/Data-Folie und eine Framework/Action-Folie.
  3. Halten Sie die Vorab-Inhalte authentisch zum Material des Benutzers; zeigen Sie niemals interne Bezeichnungen wie "Option A" innerhalb der Folie selbst an.
  4. Bitten Sie den Benutzer, sich einmal zu entscheiden, und wenden Sie dann das ausgewählte System konsistent an.

Überspringen Sie dieses Gate nur, wenn der Benutzer ausdrücklich darum bittet, direkt fortzufahren, oder eine klare visuelle Referenz bereitstellt. Dokumentieren Sie die gewählte Richtung im Projektarbeitsbereich.

Bearbeitbarkeit bewahren

  • Halten Sie Text als Text.
  • Halten Sie Tabellen als Tabellen.
  • Halten Sie Diagramme nach Möglichkeit als native Diagramme.
  • Halten Sie Diagrammdaten und Diagrammabsicht getrennt vom Folienlayout-Code.
  • Halten Sie einfache Matrizen, Zeitstrahlen, Prozesse und Problembäume als native Formen.
  • Verwenden Sie Bilder für Fotografien, strukturierte Kunstwerke oder Illustrationen – nicht für gesamte textlastige Folien.
  • Liefern Sie niemals ein Deck aus, dessen Seiten plattgedrückte Screenshots sind.

Vom gespeicherten Projekt aus iterieren

Bearbeiten Sie für Anfragen wie "Ändere den Titel von Folie 3" die Projektquelle und generieren Sie die betroffene Ausgabe neu. Bewahren Sie Quellmaterial, Beleg-IDs, Diagrammdaten, Folien-IDs und Sprechernotizen. Führen Sie alle betroffenen Qualitätsprüfungen und die abschließende Deck-Ebene-Prüfung erneut durch.

Lernen, ohne die installierte Skill zu verändern

Klassifizieren Sie jede inhaltliche Korrektur entweder als einmalig oder wiederholbar. Dokumentieren Sie wiederholbare Lektionen im Deck-Arbeitsbereich unter qa/experience-log.md; bearbeiten Sie die installierte Skill während der regulären Deck-Produktion nicht stillschweigend. Fördern Sie eine wiederholte Lektion nur durch eine überprüfte, versionierte Skill-Aktualisierung in diese Skill.

Ausliefern

Liefern Sie die endgültige .pptx plus eine prägnante Zusammenfassung. Behalten Sie Zwischenpläne, Vorschauen und QA-Dateien innerhalb des Projektarbeitsbereichs, es sei denn, der Benutzer fordert sie an. Geben Sie alle nicht verifizierten Behauptungen, Schriftartersetzungen, Kompatibilitätseinschränkungen oder verbleibenden Warnungen explizit an.

Verwandte Skills