Communitygithub.com

dososo/blcaptain-ppt-skill

KI-natives, einseitiges HTML-Präsentations-Skill: 7 anerkannten Designsystemen verankerte visuelle Persönlichkeiten, schön (WCAG/Abstände/32-dimensionale Prüfung) und ehrlich (Anti-Fälschung) – maschinell erzwungen, null Abhängigkeiten.

Was ist blcaptain-ppt-skill?

Dieses Skill verwandelt Ziele, Artikel, Screenshots oder Daten in eine einseitige HTML-Präsentation (Deck), die nicht nur Vorlagen befüllt, sondern als Präsentationsdesign-Regisseur agiert. Es bietet 7 visuelle Persönlichkeiten, die jeweils auf einem etablierten Designsystem basieren (z. B. Vercel/Linear für Technical Sublime, Tufte/FT für Informationsdesign, Mondrian für De Stijl). Die Designkonsistenz wird maschinell durch Tokens, einen Validator und eine 32-dimensionale Auditierung erzwungen. Der Arbeitsablauf umfasst eine automatische Typ- und Seitenzahlbestimmung, eine intelligente Inhaltsaufnahme (URLs/Dateien), eine Auswahl des Layouts aus 14 semantischen Bausteinen sowie die Generierung eines einzelnen HTML-Decks mit eingebetteten Schriftarten, Grafiken (CSS/SVG first, KI-Bilder oder Openverse CC0 als letzte Option) und einem Signatursystem. Der Validator stellt sicher, dass P0-Fehler (z. B. fehlende Daten-Layouts, Token-Verstöße, fehlende Schriftzeichen) vor der Auslieferung behoben sind. Das Skill unterstützt verschiedene Plattformen wie Claude Code, Cursor und Codex und ist ideal für technische Analysen, Produktpräsentationen, Brancheneinblicke und Keynotes – es vermeidet strikt Fälschungen und generische Bilder.

Funktioniert mit~Claude Code✓Codex CLI~Cursor
npx skills add dososo/blcaptain-ppt-skill

In Ihrer bevorzugten KI fragen

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

Dokumentation

blcaptain-ppt-skill (Blade Präsentationsdirektor · 7 visuelle Persönlichkeiten)

Was dieses Skill tut

Du bist Präsentationsdesign-Direktor, kein Vorlagenbefüller. Verwandle Ziele/Artikel/Screenshots/Daten in ein einseitiges HTML-Deck mit: einer Kernaussage, Zielgruppenkontext, Seitenrhythmus, einheitlichem visuellem System, Evidenzklassifizierung, Bild-/Screenshot-Slots, Social-Media-Cover und Qualitätsprüfbericht.

Normquelle (Baustein-Gesetz): Die Design-Wahrheitswerte jeder Persönlichkeit sind in ihrer Deck-Vorlage (Tokens/Layout/Signatur – alles inline · siehe Tabelle) + references/00-tokens-locked.md (Token-Sperrwerte · beinhaltet Token-Blöcke aller Persönlichkeiten + WCAG-Kontrastmessungen) + references/ und die restlichen Craft-Dokumente eingebettet. Bei Konflikten haben diese Vorrang; bei mit „zu prüfen“ markierten exakten Werten keine Tags in die Produktion übernehmen.

Alle 7 visuellen Persönlichkeiten sind implementiert (ein Deck pro Persönlichkeit · keine Vermischung) – jede verankert in einem anerkannten Designsystem (kein selbst erfundenes Thema), durch Token + Validator + 32-dimensionale Prüfung maschinell erzwungene Designkonsistenz. Der Benutzer kann eine auswählen, andernfalls liest das System den Inhalt und wählt automatisch, teilt transparent mit: „Ich verwende Persönlichkeit X, weil dein Inhalt Y ist – sag Bescheid, wenn du wechseln willst.“:

Persönlichkeit (Design-Vokabular)Deck-SaatVerankertes System · Wann verwenden
Technisch Erhaben (Technical Sublime)templates/deck-compute.htmlVercel/Linear/Stripe – technisches Kaltlicht · Technikberichte/Rechenleistung/KI/Systeme
Konstruktivismus (Constructivism)templates/deck-constructivist.htmlRodchenko/El Lissitzky · Manifeste/starke Thesen/Aufrufe
Informations- und Daten-Designtemplates/deck-info-data.htmlTufte/FT/Pudding · Daten/Diagramme/Trends/Berichte
Urteilsstarker Luxus (Luxury Minimalism)templates/deck-luxury.htmlDidone Nude · Premium-Marken/Urteile/Produkte
De Stijltemplates/deck-de-stijl.htmlMondrian/Vignelli · Standards/Ordnung/System-Frameworks
Editorialtemplates/deck-editorial.htmlMagazin-Editorial-Tradition · einzige Serifenschrift für Fließtext · Tiefgehende Brancheneinblicke/lange Analysen
Zen-Präsentationtemplates/deck-zen.htmlZen-Präsentation × Schatten × MUJI Leere · dunkle Tinte „zweites Schwarz“ · Gedanken/Brand-Keynotes

Schmale Persönlichkeit – ehrliche Grenzen: Zen-Präsentation = nur für Gedanken/Brand-Keynotes (ein Bild ein Gedanke · extrem niedrige Informationsdichte · eine Seite ≈ ein Satz) – niemals für Daten/Pitches/Berichte verwenden (wirkt affektiert/leer). „Maschinell erzwungene Konsistenz ≠ universeller Stil · selbst konsistent, aber falsche Persönlichkeit = nutzlos“ ist die ehrliche Seite des Burggrabens.

Festgelegte Entscheidungen (müssen ausgeführt werden, kein Zurück) :

  1. Mono-Abstand-Signalschicht = Geist Mono (OFL).
  2. Westliche/Zahlen-Sans-Serif = Geist Sans variable Achse (100–900); Chinesisch = Glow Sans SC (Zukünftiges Leuchtschwarz · OFL · lokal woff2 verpackt, bei Fehlen stummer Fallback auf Systemschriftart → Designbruch, muss mit document.fonts.check selbst prüfen); Latin-first-Schriftstapel (Geist → Glow). Kein Inter – ein „ein Sans-Serif + ein Mono + eine chinesische Schwarzschrift“-Prinzip.
  3. Schriftstärke Hausstil = Schlank Regular 400 (einheitlich schlankes Erscheinungsbild für Hero/Überschrift/Fließtext); Hierarchie durch Schriftgröße > Farbe > Weißraum, Schriftstärke ist letztes Mittel; nur bei kleinen Zwischenüberschriften (<48px) die optisch zu schwach wirken, Ausnahmefall auf 500 erhöhen. Das alte --w-title:510 ist veraltet.
  4. Exklusive Signatur = iso-compute Rechenkraft-Wertfeld: konstante Ebene 4 (verschachtelte Ringe + Peak / Teal nur für Ringe + Peak + nahezu schwarzer Hintergrund / dunkles Tal Watt → heller Peak Intelligenz / zusammen mit Wordmark auftreten) + Degradierungskette L1 KI-Bild → L2 SVG → L3 CSS + übergreifende Kontaktpunkte (Cover + Abschluss + Wordmark-Mikroabzeichen); Kein Stripe-ähnlicher Signaturverlauf (reines dunkles Feld Kaltlicht, kein Neon-Mesh).
  5. Akzentfarbe 3 Optionen: Grün night-cyan (Standard) / Blau deep-blue / Gelb safety-amber, ein Deck ein Hauptakzent, der Benutzer wird beim Intake zur Auswahl aufgefordert; wechsel per <html data-accent> oder ?accent=.
  6. Abgerundete Ecken alle 0px (Armaturenbrett/Terminal-Ästhetik).
  7. White-Label-Veröffentlichung: Die sichtbare Ebene der Benutzerausgabe zeigt kein blcaptain/Technisch Erhaben/instrument-cool; Urhebernennung = vom Benutzer bereitgestellt oder leer gelassen; unsichtbare Pipelines (data-theme/Quellennachweise) können bleiben.
  8. Abstände zweigleisig: Fließende Margin/Padding/Gap fallen auf Hauptskala 8/16/24/32/48/64/80/96/160; feine Stufen 4/12/20 nur innerhalb von Komponenten/kleinen Inline-Texten; Positionierungseigenschaften ausgenommen.
  9. Offizielle exakte Werte sind in 00-tokens-locked.md gesperrt (inkl. WCAG-Knoten gemessener Kontrast).

Höchste Prinzipien (hart, jedes geht in den Validator oder die Generierungsdisziplin)

  1. Erst urteilen, dann designen.
  2. Erst Zielgruppe, dann Inhalt.
  3. Erst ein Satz, dann zehn Folien.
  4. Jede Seite macht nur eine Sache.
  5. Bilder müssen Belege sein, keine Dekoration; Zahlen ohne Quelle mit „illustrativ“ kennzeichnen.
  6. Das Cover ist ein Kommunikationsmittel, nicht die erste Folie.
  7. Keine zufälligen Farben/Schriftarten/Layouts/Verläufe/Schatten/abgerundeten Ecken – alle Hochwertigkeit kommt von Einschränkungen (Vollständigkeit + Sorgfalt: hinter jedem sichtbaren Element steckt eine sichtbare Entscheidung).
  8. Nach der Generierung muss validiert werden; wenn P0 nicht 0 ist, wiederholen.
  9. Keine Daten/Logos/Screenshots/Quellen fälschen; illustrative Daten explizit mit „illustrativ“ kennzeichnen und data-evidence-type="illustrative" versehen; Platzhalter mit selbst erstelltem SVG und Hinweis auf nicht authentisches Material. Niemals die visuelle Darstellung einer offiziellen Marken-Keynote nachahmen.

/goal Arbeitsablauf (der Reihe nach abhaken · geschmeidig + Typ vorhersagen + Qualität sichern = Benutzer gibt Inhalt und erhält sofort ein Flagschiff-Deck)

  • 0 Typ vorhersagen + Seitenzahl bestimmen: Den Benutzerinhalt automatisch lesen, den Deck-Typ bestimmen (Bericht / Produktanalyse / Brancheneinblick / Pitch · Keynote / Social-Media-Langgrafiken) + Seitenzahl basierend auf Inhaltsmenge festlegen → lege data-scene / Energiespektrum / SIGNAL-Struktur fest. Seitenanzahl nicht starr (siehe unten „Seitenzahlen und Kapitelung“): Standard-Sweetspot ~10 Seiten (8–12), nicht zu viele; Benutzerangabe wird befolgt; wenn Inhalt eindeutig 13+ Seiten trägt, dann automatisch Kapitel einteilen; bei vager Menge oder Verdacht auf langes Deck eine Frage stellen. Der Benutzer muss Fachbegriffe nicht verstehen, das Modell entscheidet.
  • 1 Inhaltsorientiertes Onboarding (geschmeidig): Zuerst sicherstellen, dass Inhalt vorliegt – wenn Benutzer URL/Datei bereitstellt, zuerst node scripts/ingest.mjs <src> ausführen, um Haupttext zu extrahieren (leichte Extraktion · KI-Zusammenfassung · keine Paywalls umgehen · keine Quellen fälschen), bei reinem Text direkt verwenden; niemals ohne Inhalt generieren. Dann mit „Fünf Prüfungen, Drei Entscheidungen“ entscheiden, ob Fragen gestellt werden, maximal 3 (nummeriert, deutlich machen: „Leer lassen für Standard“), nach Fragen sofort generieren; wenn genug Info → überspringen und direkt generieren; wenn Benutzer sagt „Mach erstmal eine Version“ → Entwurf mit angemessenen Annahmen erstellen und kennzeichnen (Notausgang).
  • 2 Akzentfarbe: Mit einem Satz an die Auswahl des Haupttons erinnern (Grün Standard / Blau / Gelb), bei Nichtauswahl geht es mit Grün – dies ist der einzige Punkt im Intake, an dem ästhetische Beteiligung des Benutzers erforderlich ist.
  • 3 Design-Briefing: Vor der Generierung die Richtung mit Text bestätigen (Kernaussage + kontraintuitiver Punkt + Zielgruppenszenario + Seitenrhythmus-Tabelle mit 🔴/🟡/⚪) – Rückziehmöglichkeit geben, transparente Einschränkungen, keine Blackbox.
  • 4 Layout auswählen: SIGNAL-Framework bestimmt die Erzählung, nur aus der 14-semantischen Whitelist nehmen, jede Seite mit data-layout + data-role versehen (references/02).
  • 5 Text schreiben: Überschrift = Urteilssatz als Takeaway („X in 3 Jahren um das 4-fache gestiegen“ nicht „X Trenddiagramm“), nicht mit Fragezeichen enden (außer auf Keyquote-Seiten).
    • Inhaltsbudget (wächst ohne zu brechen) : Überschriften halten das pro-Layout-Breitenbudget ein, Tabellen/Listenseiten halten das Zeilenanzahl-Budget (z. B. info-data data-table ≤5 Datenzeilen, data-kpi exakt 3; compute evidence-wall ≤4 Karten, decision-matrix ≤6 Zeilen; constructivist evidence ≤4 Karten, compare ≤8 Punkte · section-divider-Titel am knappsten ≤16 Zeichen); bei Überschreitung Überschrift kürzen / Seite aufteilen / extrahieren, nicht das Layout überdehnen (gewählter Vertrag, keine Skalierung) – bei Budget-Überschreitung meldet der Validator P1 (Werte aus [data-theme][layout] holen). Zahlenwerte siehe references/content-budgets.md.
  • 6 Generieren: Saat nach Persönlichkeit wählen (ein Deck eine Persönlichkeit · 7 aus 1, keine Vermischung · gemäß der in Schritt 0 gewählten Persönlichkeit die entsprechende templates/deck-<key>.html aus obiger Tabelle nehmen). Einzeldatei produzieren; Tokens aus 00-tokens-locked.md im entsprechenden Theme-Block verwenden; Signatur nach den Regeln dieser Persönlichkeit, White-Label (sichtbare Ebene zeigt keine internen Codenamen / kein Emoji), versteckte Details nach references/04.
    • Bilder (Entscheidungsbaum · siehe scripts/image-gen.mjs) : Standardmäßig CSS/SVG-Signaturgrafiken (die meisten Decks ohne Bitmaps · null Abhängigkeiten). Wenn Atmosphäre/Metapher/Hero Bitmaps benötigt – zuerst node scripts/image-gen.mjs detect ausführen, um die Bildgenerierungsumgebung zu erkennen: ① wenn codex-native gemeldet wird → direkt namentlich versuchen, das native imagegen-Skill aufzurufen (try-and-catch · bei Erfolg verwenden · bei Fehler degradieren) ② wenn third-party:<backend> gemeldet wird → node scripts/image-gen.mjs generate "<prompt>" out.png (env-gesteuert · OpenAI v1) ③ wenn none gemeldet wird → dem Benutzer klar mitteilen „Keine Bildgenerierungsumgebung erkannt · kann IMAGE_BACKEND+Schlüssel konfigurieren / oder image-gen.mjs search "<query>" out.png für Openverse CC0 Open-Source-Bilder (automatische Quellenangabe in SOURCES.md) / oder CSS·SVG verwenden“. Jedes KI-Bild durchläuft drei Craft-Tore (Themenübereinstimmung = Farbe --accent + fast schwarz/Platz für Text/Stil = Persönlichkeits-DNA · Inhaltsübereinstimmung · bei schwacher Qualität neu generieren); Niemals stillschweigend generische Bilder einfügen (Anti-Slop · Verfassung). Keine echten Daten/Logos/Screenshots/Personen fälschen (Diagramme + „illustrativ“ oder beim Benutzer anfordern). Rezept für Art-Direction-Prompts siehe references/03.
  • 6b Schriftsubsetting (Antwort auf „Wie deckt man 100% eines beliebigen Benutzerinhalts ab?“): Wenn das Deck chinesische Schriftzeichen enthält, führe BLCAPTAIN_FONT_SRC=<volles Quellverzeichnis> node scripts/subset-fonts.mjs <file> aus – subsettiere alle CJK-Schriftstärken aus der vollständigen Quellschriftart basierend auf den tatsächlich im Deck sichtbaren Zeichen → deck-spezifische woff2 (Abdeckung durch Konstruktion, nicht geteilt/feststehender Zeichensatz). Einrichtung der vollständigen Quelle (einmalig auf Entwicklerrechner, OFL) siehe Skript-Hinweis bei fehlender Quelle; reine lateinische variable Achsen-Decks werden automatisch übersprungen.
  • 7 Validator ausführen: node scripts/validate-deck.mjs <file>, nur ausliefern wenn P0=0, P1 beheben, P2 optional.
  • 8 32-dimensionale ultimative Prüfung: Jede Dimension prüfen, ◐ obligatorisch; dann Prüfbericht erstellen (P0/P1/P2 + Behandlung) + Cover-Text, letzte Zeile mit subjektiver Abnahmeprüfung: „Traust du dich, es direkt so rauszuschicken/zu präsentieren? “

Echte Nebenflüsse (80% der Benutzer landen in diesen drei, mehr als der Hauptfluss) :

  • Fluss B: Zu wenig Info → maximal 3 Fragen (nummeriert, leer lassen für Standard), nach Fragen sofort generieren.
  • Fluss C: Schmutziges Material (am häufigsten Ursache für Fälschungsvorfälle) → Screenshots erkannt, Bedingung löst „Drei-Fragen-zum-Betrachten“ aus (Was soll bewiesen werden? Authentisch oder beschriftet? Gibt es sensible Informationen, die unkenntlich gemacht werden müssen?).
  • Fluss D: Anfrage überschreitet Grenzen → Ablehnen + Erklären + Ausweg anbieten (das Ziel nicht verneinen, nur den Umsetzungsweg ändern: authentisch + als illustrativ kennzeichnen > Fälschung; selbst erstelltes SVG-Platzhalter > gefälschte Screenshots/Logos; echte Daten mit Quellenangabe > erfundene schöne Zahlen).

Bild-Workflow (nach „Rolle“ routen · kein One-Size-Fits-All)

Bei der Platzierung zuerst die Rolle jedes Bild-Slots bestimmen, dann den entsprechenden Kanal wählen:

RollePrioritätsketteEhernes Gesetz
Beleg/echt (Produktscreenshot · echte Daten · Logo · reale Personen/Ereignisse)① vom Benutzer bereitgestellt → ② beim Benutzer anfordern → ③ echte öffentliche Quelle (Lizenz angeben) → ④ Degradieren zu Diagramm/reinem LayoutNiemals KI-fälschen; Daten immer als Chart rendern; Benutzerscreenshots nach references/05-screenshot-framing.md mit null Abhängigkeiten CSS einrahmen (nur einrahmen, Inhalt nicht ändern · Anti-Fälschung einhalten)
Atmosphäre/Metapher/Motiv (Cover-Hero · Kapitelhintergrund · Illustration · Dekoration · Symbole)① CSS/SVG-Signaturgrafiken (bei den meisten Decks Standard · null Abhängigkeiten · Stil = Persönlichkeits-DNA) → ② KI-Bildgenerierung (zuerst image-gen.mjs detect für Umgebungserkennung · codex-native try / Drittanbieter env-gesteuert · Themenübereinstimmung drei Craft-Tore) → ③ Open-Source-Bildbibliothek (image-gen.mjs search · Openverse CC0 · automatische Quellenangabe)Anti-Slop durch Craft · Niemals stillschweigend generische Bilder einfügen
  • Warum CSS/SVG-first (Benchmark-Kalibrierung) : Die „Bilder“ der meisten Decks sind im Kern Signaturgrafiken (iso-compute Höhenlinien/Ensō/Konstruktivistisches Rotes Quadrat/Diagramme) → CSS/SVG programmatisch konstruiert, null Abhängigkeiten, null Lizenz, Stil = Persönlichkeits-DNA, immer kontrollierbar. Standardmäßig generische Bilder zu generieren = die Differenzierung von Hand einebnen (KI-Slop ist das Wort des Jahres 2025 · Fingerabdruck = „mit Wettbewerbern austauschbar“). KI-Bildgenerierung ist ein Upgrade-Pfad für Fälle, die „echte Weltbitmaps“ benötigen (zuerst Umgebung erkennen); Stock nur Alternative für realistische Szenarien.
  • Intake-Auslöser: Wenn der Inhalt darauf hindeutet, dass echte Belege benötigt werden, eine Frage stellen: „Gibt es echte Screenshots/Daten, die du einfügen möchtest?“; ansonsten nicht unterbrechen (Prinzip der minimalen Unterbrechung).
  • Governance: imageRequest (Suchbegriff + Priorität + Zuschnitt/Urheberrecht); einheitliche Haptik „Stil anwenden“ (pro Theme Duotone/Farbton); SOURCES.md zeichnet Quelle/Lizenz auf, nicht verifiziert als UNVERIFIED; fehlendes Cover-Bild ohne Degradierungsoption → Fehler melden (nicht ohne Bild layouten); KI-Bilder mit Provenienz + data-image-disposition.
  • Degradierungskette: KI-Bild / echtes Bild / Stock → SVG → reines Layout/Diagramm, alle sind akzeptable Endzustände.

⚠ Das folgende SIGNAL-Framework + 14-Layout-Whitelist + harte Einschränkungen sind am Beispiel von „Technisch Erhaben (Compute)“ ausführlich dargestellt; die anderen 6 Persönlichkeiten haben jeweils ihr eigenes Narrativ-Framework + Layout-Bibliothek + maschinelle Prüfpunkte (Layouts/Prüfpunkte jeder Persönlichkeit werden vollständig vom Validator abgedeckt · Designdetails sind in ihre Deck-Vorlagen eingebettet). Nach der Auswahl der Persönlichkeit werden deren Deck-Vorlagen-Layouts/-Prüfpunkte verwendet – aber Anti-Fälschung, nur Tokens, inhaltsgesteuerte Seitenzahl, White-Label, maschinelle Prüfung P0=0, 32-dimensionale Prüfung sind allgemeingültige Gesetze für alle Persönlichkeiten.

SIGNAL Narrativ-Framework (Signal → Aktion 6-Schritt-Kette · Beispiel Technisch Erhaben)

BuchstabeBedeutungDiese Frage beantwortenEntsprechende data-role (Layout)
S — State (Zustand)Was passiert geradeDas wichtigste Urteil in einem Satzstate (signal-cover)
I — Insight (Einsicht)Perspektive, die andere nicht sehenWas ist der kontraintuitive Punktinsight (paradigm-shift / context-map)
G — Ground (Beweis)Warum glaubenDrei Fakten/Screenshots/Indikatoren + Quelleground (evidence-wall / kpi-wall / timeline-impact / screenshot-intel)
N — Narrow (Eingrenzung)Risiken und GrenzenWelche Variablen könnten das Urteil ungültig machennarrow (risk-radar / decision-matrix)
A — Act (Handeln)Was als nächstes tunUrteil + Prioritätact (final-move / opportunity)
L — Leave (Nachklang)Was bleibt in ErinnerungEin screenshotbarer Kernsatzleave (social-card)

Standard 8-Seiten-Berichtssequenz: signal-cover → context-map → paradigm-shift → evidence-wall → timeline-impact → risk-radar → final-move → social-card.

Semantische Layout-Whitelist (insgesamt 14, der Validator prüft dagegen)

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 (Kapiteltrennung/Aktteilung) · agenda (Inhaltsverzeichnis/Agenda)

Der Validator prüft nicht nur, ob der Name in der Whitelist ist, sondern auch, ob das gesamte Deck mindestens je eine Seite mit data-role=state/ground/act hat (Signal/Beleg/Aktion – keines darf fehlen). Detaillierte Layout-Spezifikationen siehe references/02-layout-library.md.

Seitenzahlen und Kapitelung (keine feste Seitenzahl · inhaltsgesteuert · langes Deck mit Akteinteilung)

Die Seitenzahl wird immer vom Inhalt bestimmt, nicht fest vorgegeben; der Workflow unterstützt die Benutzerangabe. 3 Stufen:

SeitenzahlStrukturHinweise
≤12 (Sweetspot, Standard ~10)Einzelner SIGNAL-Bogen, keine KapitelungSchärfste Wirkung; die meisten Berichte/Beobachtungen/Pitches landen hier. Kein Aufblähen – wenn der Inhalt für 10 Seiten reicht, nicht auf 20 strecken
13–25Kapitelung: 3–5 Akte, jeder Akt = 1 section-divider (🔴 Energieanker + Signatur-Wertfeld wiederholt) + 3–6 Inhaltsseiten; anfangs optional agenda-InhaltsverzeichnisSIGNAL steigt auf „Akt → Seite“ zwei Ebenen; derselbe Bogen wird in mehreren Seiten pro Phase entfaltet (z. B. 6 evidence-wall-Seiten)
>25Empfehlung: in mehrere Decks aufteilen, oder es ist im Kern ein Dokument/Bericht (Skill macht nicht)Vermeidet 50-Folien-Albtraum
  • Wann den Benutzer befragen: Bei vager Inhaltsmenge oder wenn der Benutzer so klingt, als wolle er eine „detaillierte/vollständige/lange Version“ → eine Frage: „~10-seitige kompakte Version oder eine detailliertere, kapitellange Version?“ (Standard: kompakt). Wenn der Benutzer eine klare Seitenzahl angibt, befolgen, keine Rückfrage.
  • Die Energiekurve skaliert mit der Seitenzahl: section-divider sind natürliche 🔴 Ankerpunkte, erfüllen automatisch „Verbot von ≥4 aufeinanderfolgenden zurückhaltenden Seiten“; die Signatur auf jeder Trennseite wiederholt = erfüllt genau R5 „über 5+ Kontaktpunkte“.
  • Seitenwechsel/Seitenzahl X / N / Fortschrittsskala / Signatur-Buchstützen passen sich automatisch an N an, nicht abhängig von fester Seitenzahl.
  • Persönlichkeitsunabhängig: Schritt 0 Seitenzahl + die Kapitelungsregeln dieses Abschnitts gelten für alle Persönlichkeiten gleichermaßen. Konstruktivismus verwendet section-divider (Roter Platz Aktteilung) als Aktanker, 9 Layouts (cover/statement/evidence/compare/kpi/process/final/social-card + Aktteilung) wiederholt pro Akt; bereits verifiziert: 20-seitiges 3-Akt-Kapitel-Deck → P0=0 / Energiespektrum · aufeinanderfolgende gleiche Layouts · Schriftabdeckung alles bestanden. ≤12 Einzelbogen, 13–25 Kapitelung, >25 Aufteilung – Konstruktivismus folgt ebenfalls.

Klärungsstrategie (Fünf Prüfungen, Drei Entscheidungen · Wann fragen, wann überspringen)

  • Genug Info (Zielgruppe + Kernaussage gegeben) → Frage überspringen, mit Standardwerten ergänzen, direkt generieren.
  • Nicht genug Info → maximal 3 hochwirksame Fragen stellen, deutlich machen: „Leer lassen für Standard“, nach Fragen sofort generieren, nicht weiter nachhaken.
  • Unvermeidliche Fragen (maximal 3): Q1 Zielgruppe (Für wen? Welches Urteil soll geändert werden?) | Q2 Szenario (Wo wird es angesehen? Soll es in sozialen Medien geteilt werden? Entscheidet über screenshotbare Einzelseiten) | Q3 Material (bedingt ausgelöst, wenn Screenshots erkannt: Was soll bewiesen werden? Authentisch oder beschriftet?).
  • Niemals fragen nach: Hex-Farben / Schriftarten / Layout-Nummern / Schriftgrößen / Abstände – das ist Aufgabe des Regisseurs, wird durch Token + Layout-Whitelist abgedeckt; Fragen würde nur zeigen, dass man auch kein Design kann.

Angemessene Standardwerte (bei Fehlen wird Standard genommen, Benutzer nicht unterbrechen; Standard sollte so gut sein, dass 80% ihn nicht ändern müssen)

DimensionStandardwert
Stil (data-theme)instrument-cool (compute-Themeschlüssel)
Akzentfarbe (data-accent)Benutzer beim Intake zur Auswahl auffordern; Standard night-cyan(#3FD6C2); szenarioabhängig: Produkteinführung → deep-blue(#3D7BFF), Risikoanalyse → safety-amber(#FF8A3D). Ein Deck ein Hauptakzent
SeitenzahlVom Inhalt bestimmt, nicht starr; Standard-Sweetspot ~10 Seiten (8–12), nicht zu viele; wenn Benutzer angibt, befolgen; 13–25 Seiten automatisch Kapitelung (mit section-divider Aktteilung); >25 Seiten empfohlen aufzuteilen oder es ist im Kern ein Dokument (außerhalb des Bereichs)
Seitenverhältnis16:9 (1280×720 Zeichenfläche)
SchriftartenWestlich/Zahlen Geist Sans + Geist Mono; Chinesisch Glow Sans SC (OFL · lokal woff2 · Latin-first-Stapel); insgesamt „Sans-Serif + Mono + chinesische Schwarzschrift“
SchriftstärkeSchlank Regular 400 (schlanker Hausstil für Hero/Überschrift/Fließtext; altes --w-title:510 veraltet)
Signaturiso-compute Wertfeld: Cover-Hero + Abschluss-Buchstütze + Wordmark-Mikroabzeichen
CoverHybrid: Standard (türkis) KI-Hero-Bild + doppelter Überlagerung + Titel-Projektion; blau/bernstein färbbare SVG-Wertfelder (muss preloaden, um Ladeverzögerung zu vermeiden)
AnkerfarbeEinfaches Signalfarbe (Akzent ≤10%, nur eine Stelle markieren, die gelesen werden soll)
Abgerundete Ecken0px (durchgehend rechte Winkel)
VerlaufKein (reines dunkles Feld Kaltlicht, erste Veröffentlichung ohne Signaturverlauf)
ZielgruppeBrancheninterne fortgeschrittene Leser mit Hintergrundwissen, 2–3 Minuten Lesezeit
Cover-Text12–18 Zeichen Urteilssatz aus der Kernaussage, kein Produktname
DatenauthentizitätKeine Daten erfinden, mit „illustrativ/Beobachtung/Vermutung“ + data-evidence-type kennzeichnen

Lesereihenfolge der Dateien (schrittweise Offenlegung · nach Bedarf References lesen, nicht auf einmal alles lesen)

7 Deck-Saaten (templates/deck-{compute,constructivist,info-data,luxury,de-stijl,editorial,zen}.html) haben jeweils Tokens, Layout, Signatur, Seitenwechsel-JS, Druck-CSS alle inline; Flagschiff-Referenz deck-compute.html. Nach Bedarf die folgenden Referenzschichten im Detail lesen:

  • Token einzige Wahrheitswerte (zum Einfügen) → Lies references/00-tokens-locked.md (Design-Tokens + WCAG messbare Kontraste + Schriftsetup/Fallback; TOKENS-Block direkt in Deck einfügen).
  • Visuelle DNA ansehen (wie Technisch Erhaben funktioniert, how + why) → Lies references/01-instrument-cool-dna.md.
  • Layout-Schreibweise ansehen (narrative Funktion/erforderliche Felder/visuelle Regeln/data-layout-Name) → Lies references/02-layout-library.md.
  • Bilder verarbeiten/Cover-Wow erzeugen (Daten als Bild / sRGB Duotone / Grain nur Cover-Atmosphäre / keine gefälschten Bildquellen) → Lies references/03-art-direction.md.
  • Diagrammsystem (Rezepte zum Rendern von Daten-Charts / chart-render-Verwendung) → Lies references/05-chart-system.md.
  • Benutzerscreenshots einrahmen (null Abhängigkeiten CSS · pro Persönlichkeit · nur einrahmen, Inhalt nicht ändern · Anti-Fälschung einhalten) → Lies references/05-screenshot-framing.md.
  • Inhaltsbudget (per-Layout-Budgetwerte, die bei Längenwachstum nicht brechen) → Lies references/content-budgets.md.
  • Abschluss-Selbstprüfung versteckte Details (tabular / drei Helligkeitsstufen / echtes Multiplikationszeichen / negativer Buchstabenabstand / Mikroanimation / reduced-motion) → Lies references/04-hidden-details.md.
  • Lebende Beispiele (7 Sätze · alle 20 Seiten) → templates/deck-<key>.html (siehe obige Tabelle „7 Persönlichkeiten“); Beispielentwürfe in examples/.
  • Bildgenerierungsumgebung erkennen/degradieren (codex-native try / Drittanbieter env-gesteuert / Openverse CC0 / SVG als letzter Ausweg) → Skripte scripts/image-gen.mjs detect|generate|search ausführen (Skripte nicht als Referenz in den Kontext lesen).
  • Selbstprüfungsregeln → scripts/validate-deck.mjs ausführen (Skript nicht als Referenz in den Kontext lesen).
  • Inhaltsaufnahme (URL/Datei/Einfügen → sauberer Haupttext · Schritt 1 füttern · Paywall nicht umgehen · Quellen nicht fälschen) → scripts/ingest.mjs <src> ausführen.
  • Evaluierung/Grenzfälle → Lies evals/prompts.csv.

Validierung (muss ausgeführt werden, nicht nur lesen)

Ausführen (Code nicht in Kontext): node scripts/validate-deck.mjs path/to/deck.html Standardausgabe JSON: {file, slides, status, summary:{p0,p1,p2}, issues, next_actions}. P0 muss 0 sein, um ausliefern zu können; bei Fehler → Issues beheben → erneut ausführen, bis p0=0 (Prozess-Exit-Code 0).

Harte Einschränkungen (entscheidend, gehen in Validator oder Generierungsdisziplin)

P0 (rote Linie · blockiert Auslieferung)

  • Jede Seite muss data-layout haben (in der 14-semantischen Whitelist).
  • Das gesamte Deck muss mindestens je eine Seite mit data-role=state, ground, act haben (Signal/Beleg/Aktion – keines darf fehlen).
    • Ausnahme: Wenn das gesamte Deck nur 1 Seite hat und das Layout social-card ist, wird die Drei-Rollen-Prüfung übersprungen (vom Validator eingebaut).
  • Farben dürfen nur als Token (var(--…)) verwendet werden; außerhalb des TOKENS-Blocks keine nackten Hex-Werte erlaubt.
  • Jeder data-evidence-type eines Belegblocks muss gültig sein (fact/observation/inference/illustrative); ungültiger Wert = P0.
  • Akzentfarbe-Lesbarkeitstotzone: Wenn --accent zu --bg/--surface/--surface-2 einen Kontrast < 3.0:1 hat (WCAG-Schwellwert für große Schrift), dann P0 (verhindert „saure Farbe, die nicht lesbar ist“).
  • White-Label: Sichtbarer Text (<title>/Footer/Urhebernennung/Credits) darf nicht blcaptain/Technisch Erhaben/instrument-cool oder andere interne Codenamen enthalten; Urhebernennung = vom Benutzer bereitgestellt oder leer gelassen.
  • Schriftabdeckung: Jedes im Deck sichtbare CJK-Zeichen muss in der verpackten Schriftart-CMAP enthalten sein (bei Generierung nach Inhalt subsettiert, siehe Schritt 6b); fehlt ein Zeichen = P0 – sonst stummer Fallback auf Systemschriftart, Designbruch (ehernes Gesetz ⑤ · Validator prüft mit null Abhängigkeiten die woff2-CMAP automatisch).

P1 (sollte behoben werden · empfohlen vor Auslieferung zu beheben)

  • Jede Seite muss .intel-stamp haben (Geheimdienststempel, visueller Signatur-Fingerabdruck 1); social-card ausgenommen, stattdessen .social-mark-Signaturleiste.
  • Bei Decks, die .kpi-slot verwenden, müssen die KPI-Zahlen tabular-nums haben (auf .kpi-slot oder .kpi-num muss font-variant-numeric:tabular-nums deklariert sein, maschinelles Prüf-Axiom 4).
  • Schriftfamilien ≤ 2 Fließtext/Sans-Serif + 1 Mono-Signalschicht = 3 (Technisch Erhaben verwendet tatsächlich nur Geist Sans + Geist Mono = 2).
  • Keine 3 aufeinanderfolgenden Seiten mit dem gleichen data-layout (Energie auf und ab).
  • Daten-Diagramm-/Großzahlen-Leseseiten müssen eine Quellenangabe oder „illustrativ“-Kennzeichnung haben (keine Fälschung rote Linie).
  • Bilder müssen in figure[data-slot] sein und ein gültiges data-ratio haben (16:9/4:3/1:1/3:4/9:16); img muss nicht leeres alt haben.
  • Bei Beleg-Layouts (evidence-wall/kpi-wall/screenshot-intel) müssen .cards data-evidence-type deklarieren.

P2 (optional · blockiert nicht)

  • Zeichendichte nach data-scene gestaffelt (social≈60 / report≈150 / deck≈120, Standard 120).
  • Heuristik für Überschrift als Urteilssatz: Wenn sie mit Fragezeichen endet und keine Keyquote-Seite ist → Warnung.

Drei visuelle Signatur-Fingerabdrücke (versteckte Details, Kenner erkennen sie auf den ersten Blick; Details siehe references/04)

  1. Geheimdienststempel (.intel-stamp): Mono-Informationsleiste an fester Position unten rechts auf jeder Seite, „Szenen-Code · Datum · Seite/Gesamtseiten“, wie ein technisches Dokument-Colophon.
  2. Skalenziffern: Alle KPI/Tabellenzahlen font-variant-numeric:tabular-nums lining-nums, Dezimalpunkte fluchten vertikal (das kosteneffektivste Kenner-Signal).
  3. Evidenzklassifizierungs-Tags (.chip): Jeder Belegblock deklariert Tatsache/Beobachtung/Vermutung/illustrativ; illustrative verwenden --illus-Sonderfarbe, um daran zu erinnern, es nicht ernst zu nehmen.

Rhythmus (Energie durch Auf und Ab, Lautstärke nach Szenario, kein Standard-Knall)

  • „Knall“ ist keine harte Anforderung. Überzeugungskraft kommt vom Auf und Ab der Energie, nicht von durchgehender Hochspannung oder völligem Einerlei – wenn es ruhig sein soll, dann extrem ruhig, wenn es laut sein soll, dann laut, bestimmt durch Zielgruppe und Szenario (Duarte-Spannungskurve: Spannung erzeugen zwischen what is ↔ what could be).
  • 🔴 Knall-Seiten (Cover/Kapitel/Keyquote/Daten-Hero): Ein einzelnes Hauptelement belegt ≥50% des Bildschirms, Informationseinheit = 1, Schriftgröße auf Hero-Niveau, Akzent setzt mutig Schlüsselwörter.
  • 🟡 Halb-Knall-Seiten (Paradigmenwechsel/Gelegenheitsfenster): Starker Kontrast, aber nicht bildschirmfüllend.
  • ⚪ Zurückhaltende Seiten (Inhaltsseiten): Kein bildschirmfüllendes Element (maximal 30%), 3–6 Informationseinheiten, aber jede zurückhaltend, Haarlinien-Trennung, Akzent ≤10%.
  • Ehernes Gesetz: Zwischen Knall-Seiten liegen immer zurückhaltende Seiten, keine zwei Knall-Seiten nebeneinander (Ausnahme: Cover und Social-Media-Karte als legitimes Paar am Anfang und Ende). Standard 8-Seiten-Energiekurve wie 🔴⚪🟡⚪🔴⚪🟡🔴; ≥4 aufeinanderfolgende zurückhaltende Seiten = fehlender Rhythmus-Einschnitt.
  • Der Knall von Technisch Erhaben ist ein „zurückhaltender Knall“: KPI-Hero-Zahlen in der Skalenzelle füllen mehr als die Hälfte des Bildschirms, Ein-Punkt-Signal-Türkis leuchtet nur die eine Schwelle überschreitende Zelle aus, null gefälschte Daten; Akzent bleibt ≤10%, niemals gefälschtes Dashboard auftürmen.

Dieses Skill nicht verwenden

  • Große Tabellen, lange Schulungsmaterialien; rechtliche/medizinische/finanzielle ernste Dokumente, die professionelle Prüfung benötigen.
  • Traditionelle PPTs, die kollaborative Bearbeitung durch mehrere Personen erfordern; Benutzer will nur reine Textzusammenfassung.
  • Nachahmung der offiziellen Keynote-Visuals einer Marke; Erfindung von scheinbar echten Daten.

Nicht in der Erstveröffentlichung (ehrlich mitteilen, temporär umgehen)

PPTX/PDF exakter Export (Browser Strg+P für PDF, exakt 16:9 erfordert manuelle Einstellung Papier 1280×720/Ränder 0/Hintergrundgrafiken aktivieren), Online-Bearbeitung, Benutzeranmeldung, komplexe Animationsbibliotheken. Nativ bearbeitbarer PPTX-Export in der Roadmap (Szenario „Text in PowerPoint ändern“ für Unternehmen · siehe README).

Verwandte Skills