ckm:design-system

Überblick

Was ist ckm:design-system?

ckm:design-system ist ein Design-System-Skill, der Design-Token-Architektur, Komponenten-Spezifikationen und die Generierung von Präsentations-Slides in einen einzigen, wiederverwendbaren Workflow kombiniert.

Die Basis ist ein dreischichtiges Token-Modell (primitive → semantic → component) mit begleitenden Referenzen und Scripts für:

• CSS-Variable-Systeme
• Spacing- und Typografie-Skalen
• Komponenten-States und -Varianten
• Tailwind-Theme-Konfiguration
• Systematische Slide- und Pitch-Deck-Layouts

Der Skill enthält vorgefertigte, meinungsstarke Datentabellen und Templates für Slide-Hintergründe, Farb-Logik, Copy-Formeln, Layouts und Narrative-Strategien sowie Scripts, um Tokens und Slide-Strukturen zu generieren und zu validieren.

Für wen ist dieser Skill gedacht?

ckm:design-system richtet sich an:

• Design-System-Verantwortliche und UI/UX-Designer:innen, die eine klare Token-Architektur und Referenzen für Komponenten-Spezifikationen suchen.
• Frontend- und React/Tailwind-Entwickler:innen, die eine robuste Token-Pipeline brauchen (CSS-Variablen, Validatoren, Hinweise zur Tailwind-Integration).
• Gründer:innen, PMs und Marketer:innen, die regelmäßig Pitch-Decks erstellen und wiederholbare, markenkonsistente Slide-Frameworks statt Einzelanfertigungen wollen.

Wenn du Figma-ähnliches Design-Denken mit implementierungsreifen Tokens und einem wiederverwendbaren Slide-System verbinden möchtest, passt dieser Skill sehr gut.

Welche Probleme löst der Skill?

ckm:design-system hilft dir dabei:

• Design-Tokens zu standardisieren – mit einer dokumentierten Primitive → Semantic → Component-Schichtung.
• CSS-Tokens aus JSON zu generieren und ihre Verwendung in deinem Code zu validieren.
• Tailwind-Themes zu planen – basierend auf derselben Token-Architektur.
• Komponenten-Spezifikationen zu definieren, inklusive States und Varianten, damit UI über Screens hinweg konsistent bleibt.
• Markenkonsistente Präsentationen zu gestalten – mit vordefinierten Slide-Layouts, Chart-Empfehlungen, Farb- und Emotionslogik und Copy-Formeln.

Du bekommst eine strukturierte Sicht auf UI und Slides als Systeme – nicht als isolierte Einzelstücke.

Wann ist ckm:design-system eine gute Wahl?

Nutze diesen Skill, wenn:

• Du ein Design-System einführst oder refaktorst und explizite Token-Ebenen möchtest.
• Du CSS-Variable- und Tailwind-Guidance brauchst, die an eine Token-Architektur gekoppelt ist.
• Du Design-Tokens generieren und validieren willst, statt sie manuell zu pflegen.
• Du regelmäßig Pitch-Decks, Sales-Präsentationen oder Produkt-Demos erstellst und eine wiederholbare Slide-Struktur brauchst.

Weniger geeignet ist er, wenn du nur ein einzelnes statisches UI-Mockup benötigst oder überhaupt nicht mit Tokens bzw. CSS-Variablen arbeitest.

Nutzung

Installation und grundlegendes Setup

1. ckm:design-system Skill installieren

Installiere den Skill in deine Agent/skills-Umgebung:

npx skills add https://github.com/nextlevelbuilder/ui-ux-pro-max-skill --skill design-system

Damit wird der design-system Skill aus dem Repository nextlevelbuilder/ui-ux-pro-max-skill in dein lokales Skills-Verzeichnis geladen.

2. Zentrale Dateien erkunden

Nach der Installation öffne den Skill-Ordner und starte mit:

• SKILL.md – Überblick auf hoher Ebene, Einsatzszenarien, Token-Architektur und Quick-Start-Commands.
• references/ – Konzeptionelle Dokumentation zu Tokens, Komponenten, Varianten und Tailwind-Integration.
• data/ – CSV-Dateien für Slide-Hintergründe, Farb-Logik, Copy-Formeln, Layouts, Typografie und Strategien.
• scripts/ – Utility-Scripts zum Generieren, Einbetten und Validieren von Tokens sowie Slide-Such-Helper.
• templates/design-tokens-starter.json – Start-Template im JSON-Format für deinen eigenen Token-Satz.

Diese Struktur ermöglicht dir, schnell zu entscheiden, welche Teile du übernehmen willst: nur Tokens, nur Slides oder das komplette System.

Deine Token-Architektur entwerfen

3. Das dreischichtige Token-Modell verstehen

SKILL.md und references/token-architecture.md beschreiben eine dreistufige Struktur:

Primitive (raw values)
       ↓
Semantic (purpose aliases)
       ↓
Component (component-specific)

Nutze die Referenzdateien, um jede Ebene zu gestalten:

• references/primitive-tokens.md – Basisfarben, Spacing, Radii, Typografie-Primitives.
• references/semantic-tokens.md – Purpose-getriebene Tokens wie --color-primary, --surface-elevated, --text-muted.
• references/component-tokens.md – Komponenten-spezifische Variablen wie --button-bg, --card-border, --badge-pill-radius.

Diese Trennung macht es einfacher:

• Themes zu tauschen, ohne Komponenten neu zu schreiben.
• Implementierungsdetails (CSS-Variablen, Tailwind-Konfiguration) mit der Design-Sprache abzugleichen.

4. Dein Token-JSON erstellen oder anpassen

Nutze templates/design-tokens-starter.json als Basis für deine eigene Token-Datei.

Typischer Workflow:

1. Kopiere templates/design-tokens-starter.json in dein Projekt als tokens.json.
2. Fülle zuerst die Primitive-Werte (Farben, Spacing, Schriftgrößen).
3. Mappe Primitive auf semantische Rollen (primary, secondary, surface, border etc.).
4. Mappe semantische Tokens auf Komponenten-Tokens für jede zentrale UI-Komponente.

Siehe dazu:

• references/component-specs.md – Für das Denken darüber, wie Komponenten Tokens konsumieren.
• references/states-and-variants.md – Für Hover-, Focus-, Disabled-, Error-States und Varianten.

Tokens generieren und validieren

5. CSS-Variablen aus Tokens generieren

Nutze das in SKILL.md beschriebene Token-Generierungs-Script:

node scripts/generate-tokens.cjs --config tokens.json -o tokens.css

• --config verweist auf dein Token-JSON (z. B. tokens.json).
• -o definiert die Ausgabe-CSS-Datei (z. B. tokens.css).

Das Ergebnis ist eine CSS-Datei, die deinen Token-Satz als --custom-properties bereitstellt – bereit zum Import in dein Frontend.

6. Token-Verwendung in deinem Code validieren

Um sicherzustellen, dass dein Code nur freigegebene Tokens nutzt, führe den Token-Validator aus:

node scripts/validate-tokens.cjs --dir src/

Dieser prüft das angegebene Verzeichnis (z. B. src/) auf Token-Verwendungsmuster und hilft dir dabei:

• Hardcodierte Werte zu finden, die eigentlich Tokens sein sollten.
• Veraltete oder nicht definierte Tokens zu identifizieren.

Weitere Validatoren in scripts/ sind:

• html-token-validator.py – Scant HTML auf Token-Verwendungsmuster.
• slide-token-validator.py – Validiert Token-Verwendung in Slide-bezogenen Kontexten.

Nutze diese, um UI und Slides konsequent an deinem Design-System auszurichten.

7. Tokens dort einbetten, wo sie benötigt werden

Wenn deine Umgebung verlangt, Tokens direkt in Dokumentation oder HTML einzubetten, kannst du nutzen:

• scripts/embed-tokens.cjs – Betten Tokens in Ziel-Dateien ein.

Sieh dir die Inline-Kommentare im Script und in SKILL.md an, um Hinweise zur Nutzung in deinem Setup zu erhalten.

Tailwind und Implementierungsaspekte

8. Tailwind-Integration planen

Der Skill enthält eine eigene Tailwind-Referenz:

• references/tailwind-integration.md – Hinweise zum Mapping von Token-Namen und -Skalen in eine Tailwind-Theme-Konfiguration.

Nutze sie, um:

• Primitive/semantische Tokens in Tailwind-colors, spacing und fontSize-Skalen zu mappen.
• Tailwind-Utility-Klassen mit deinem Token-Design zu synchronisieren (z. B. eine primary-Palette, die aus Primitives abgeleitet ist).

Auch wenn du Tailwind nicht sofort verwendest, ist diese Referenz hilfreich, um zu planen, wie dein Token-System in utility-first CSS skalieren kann.

Systematisierte Slide-Decks aufbauen

Auch wenn der Schwerpunkt auf Design-Systemen liegt, unterstützt ckm:design-system ebenfalls strukturierte Präsentationsgestaltung.

9. Slide-Datentabellen für Layout und Visuals nutzen

Im Verzeichnis data/ findest du CSV-Dateien mit Best-Practice-Slide-Mustern:

• data/slide-backgrounds.csv – Empfohlene Hintergrundbild-Typen, Overlays und Platzierung nach Slide-Typ (Hero, Vision, Team, Testimonial, CTA, Problem, Solution etc.).
• data/slide-color-logic.csv – Wie Emotionen (frustration, hope, fear, relief, trust, urgency, curiosity etc.) auf Hintergrundstile, Textfarben und Akzentnutzung gemappt werden.
• data/slide-typography.csv – Typografie-Empfehlungen pro Slide-Typ (Hierarchie, Hervorhebung etc.).
• data/slide-layout-logic.csv – Layout-Muster, gesteuert durch Narrative-Ziele und Emotionen (hook, problem, solution, proof, traction, CTA, timeline, features etc.).
• data/slide-layouts.csv – Konkrete Layout-Muster mit CSS-Struktur-Hinweisen (z. B. Grids, Split-Layouts, Hero-Strukturen, Animationsempfehlungen).

Du kannst diese Tabellen in deine eigenen Pipelines (Scripts, Spreadsheets oder einen Deck-Generator) laden, um konsistente Slides zu erstellen, die von Narrativ und Emotion statt von zufälligen Designentscheidungen getrieben sind.

10. Slide-Copy mit erprobten Formeln strukturieren

data/slide-copy.csv enthält Copywriting-Formeln für unterschiedliche Slide-Typen, u. a.:

• AIDA (Attention → Interest → Desire → Action)
• PAS (Problem → Agitate → Solution)
• 4Ps (Promise → Picture → Proof → Push)
• Before-After-Bridge
• QUEST
• Star-Story-Solution

Jede Zeile enthält:

• formula_name und keywords
• Strukturierte components
• use_case und example_template
• emotion_trigger und slide_type

Nutze diese, um:

• Einen Agenten anzustoßen, der Slide-Copy nach einer bestimmten Formel entwirft.
• Copy quer über Pitch-Decks und Sales-Präsentationen zu standardisieren.

11. Slide-Strategien für komplette Decks auswählen

data/slide-strategies.csv definiert komplette Deck-Muster, zum Beispiel:

• YC Seed Deck
• Guy Kawasaki 10/20/30
• Series A Deck

Jede Strategie beinhaltet:

• Empfohlene Anzahl von Slides
• Reihenfolge (title, problem, solution, traction, market etc.)
• Ziel, Zielgruppe und Tonalität
• Narrative- und Emotionsbögen

Damit kannst du:

• Eine vollständige Slide-Outline für eine gewählte Strategie generieren.
• Design-System und Narrative-Struktur in Einklang halten.

12. Mit Slide-Scripts arbeiten

Im Verzeichnis scripts/ findest du Utilities für Slide-Workflows:

• scripts/generate-slide.py – Zentrale Logik zur Slide-Generierung (kannst du in deinen eigenen Deck-Generator oder deine Pipeline adaptieren).
• scripts/search-slides.py und scripts/slide_search_core.py – Such-Utilities, mit denen du passende Slide-Muster oder Strategien nach Keywords und Kontext findest.
• scripts/fetch-background.py – Hilft beim Abruf von Hintergrundbildern (z. B. von Pexels/Unsplash) basierend auf den Richtlinien in data/slide-backgrounds.csv.

Diese Scripts sind Bausteine, die du je nach Umgebung und Automatisierungsgrad ausführen oder anpassen kannst.

Mit Referenzen und Dokumentation arbeiten

13. Referenzen als Implementierungs-Checklisten nutzen

Der Ordner references/ ist nicht nur Dokumentation, sondern zugleich eine Checkliste für den Aufbau deines Design-Systems:

• references/token-architecture.md – Prüfen, ob deine Primitive/Semantic/Component-Schichtung stimmig ist.
• references/primitive-tokens.md – Sicherstellen, dass du einen vollständigen Satz an Basis-Tokens hast.
• references/semantic-tokens.md – Kontrollieren, ob jedes semantische Token einen klaren Zweck hat.
• references/component-tokens.md – Tokens konkreten Komponenten zuordnen.
• references/component-specs.md – States, Varianten, Interaktionen und Accessibility-Aspekte erfassen.
• references/states-and-variants.md – Verhindern, dass Hover-, Focus-, Active-, Disabled-, Error- und Success-States vergessen werden.

Nutze diese Dateien in Design-Reviews und beim Handover, um Designer:innen und Entwickler:innen synchron zu halten.

Den Skill an deinen Stack anpassen

14. Schrittweise integrieren

Du musst den Skill nicht komplett auf einmal übernehmen. Häufige, sinnvolle Einstiege:

• Nur Tokens einführen – Starte mit templates/design-tokens-starter.json, generate-tokens.cjs und validate-tokens.cjs, um eine Token-Pipeline aufzubauen.
• Nur Slides nutzen – Verwende die CSVs in data/ und scripts/generate-slide.py, um deine Präsentationen zu standardisieren, während du dein bestehendes Design-System beibehältst.
• Komplettsystem übernehmen – Kombiniere Tokens, Komponenten und Slide-Strukturen, um ein einheitliches Brand-System über Produkt-UI und Pitch-Decks hinweg aufzubauen.

Fokussiere zuerst den Teil, der dein dringendstes Problem löst, und erweitere dann schrittweise.

FAQ

Ist ckm:design-system ein UI-Kit oder eine Design-Token-Engine?

Es ist in erster Linie ein Design-System- und Token-Architektur-Skill, der zusätzlich ein strukturiertes Slide-System enthält. Es wird nicht als Figma-UI-Kit ausgeliefert, bietet dir aber:

• Eine dreischichtige Token-Architektur
• Scripts zum Generieren und Validieren von Tokens
• Referenzen für Komponenten-Spezifikationen und States

Du kannst dieselben Tokens und Komponenten problemlos in Figma oder jedem anderen Design-Tool spiegeln.

Kann ich ckm:design-system ohne Tailwind oder React verwenden?

Ja. Die Tailwind-Integration ist in references/tailwind-integration.md dokumentiert, aber optional. Tokens werden als standardisierte CSS-Variablen generiert und können in jedem Stack eingesetzt werden:

• Vanilla CSS oder CSS Modules
• Styled-components oder andere CSS-in-JS-Lösungen
• Design-Tokens für Web Components oder andere Frameworks

Wie unterstützt ckm:design-system Präsentationen?

Der Skill behandelt Slide-Decks als Design-System-Thema:

• data/slide-layouts.csv und data/slide-layout-logic.csv definieren Layout-Muster und CSS-Strukturen.
• data/slide-backgrounds.csv und data/slide-color-logic.csv mappen Slide-Typen und Emotionen auf Visuals.
• data/slide-copy.csv und data/slide-strategies.csv liefern Copy-Formeln und Deck-Strukturen.
• Scripts wie generate-slide.py und search-slides.py helfen bei Automatisierung und Wiederauffindbarkeit.

Damit kannst du wiederholbare, markenkonsistente Decks statt einmaliger Slides aufbauen.

Muss ich die mitgelieferten CSV-Daten unverändert übernehmen?

Nein. Die CSVs sind meinungsstarke Defaults. Du kannst sie:

• Unverändert nutzen, um schnell Pitch-Decks zu erstellen.
• Forken und an deine Markenstimme und deinen visuellen Stil anpassen.
• Komplett durch eigene Daten ersetzen, solange du die gleichen Script-Muster beibehältst.

Wo sollte ich anfangen, wenn mir nur Design-Tokens wichtig sind?

Wenn dein Fokus auf Tokens und UI-Implementierung liegt:

1. Lies SKILL.md, insbesondere die Abschnitte "When to Use" und "Token Architecture".

2. Öffne references/token-architecture.md sowie die Referenzen zu Primitive/Semantic/Component-Tokens.

3. Kopiere templates/design-tokens-starter.json und erstelle deine tokens.json.

4. Führe aus:

   node scripts/generate-tokens.cjs --config tokens.json -o tokens.css
   node scripts/validate-tokens.cjs --dir src/
   

Damit erhältst du eine funktionierende Token-Pipeline, ohne das Slide-System anfassen zu müssen.

Ist ckm:design-system für kleine Projekte geeignet?

Kann sein, aber seine Stärken kommen vor allem bei Projekten zum Tragen, in denen:

• Mehrere Personen an UI oder Decks arbeiten
• Konsistenz und Skalierbarkeit wichtig sind
• Du erwartest, Marke oder Produkt im Laufe der Zeit weiterzuentwickeln

Für eine einmalige Landingpage oder eine einzelne interne Präsentation kann das vollständige System mehr Struktur bieten, als du brauchst. Du kannst aber dennoch die Token-Architektur oder Slide-Formeln als leichte Orientierung nutzen.

Wie sehe ich alles, was im Skill enthalten ist?

In deinem Skills-Browser oder File-Explorer kannst du den kompletten Tree des design-system Skills ansehen, insbesondere:

• SKILL.md
• data/
• references/
• scripts/
• templates/design-tokens-starter.json

So siehst du alle verschachtelten Referenzen und Helper-Scripts und kannst entscheiden, welche Teile du in deinen eigenen Workflow integrierst.