Communitygithub.com

Design-System-Builder

Erstelle, erweitere oder prüfe ein Designsystem für jedes Projekt und jede Plattform – Design-Tokens (Farbe, Typografie, Abstände, Radius, Höhe, Bewegung, Breakpoints), Token-Architektur (primitiv → semantisch → Komponente), das W3C DTCG-Token-Format, Theming (Hell/Dunkel, Marken, Dichte), plattformübergreifende Ausgabe (CSS-Variablen, Tailwind v4 @theme, React Native, Flutter, SwiftUI, Compose), Komponenten-API-Konventionen, Dokumentation (DESIGN.md, Storybook) und Governance.

Was ist Design-System-Builder?

Das Skill 'Design-System-Builder' ist ein umfassendes Werkzeug zur Erstellung, Erweiterung und Überprüfung von Designsystemen für jede Art von Projekt und Plattform. Es bietet eine strukturierte und skalierbare Methodik, die von der Definition der Designrichtung über die Generierung von Design-Tokens (Farbe, Typografie, Abstand, Radius, Höhe, Bewegung, Breakpoints) bis hin zur Auslieferung an verschiedene Plattformen reicht. Der Skill unterstützt die W3C-DTCG-Token-Architektur mit drei Ebenen (primitiv, semantisch, Komponente) und ermöglicht Theming für Hell/Dunkel, Marken und Dichte. Er generiert plattformspezifische Ausgaben wie CSS-Variablen, Tailwind v4 @theme, React Native (NativeWind/Unistyles/Tamagui), Flutter, SwiftUI und Jetpack Compose. Darüber hinaus behandelt der Skill Komponenten-API-Konventionen, Dokumentation (DESIGN.md, Storybook) und Governance-Prozesse. Er ist ideal für Entwickler, die ein neues App-Projekt starten, ein bestehendes UI konsistent gestalten oder ein umfassendes Designsystem für ein Multi-Team-Produkt aufbauen möchten. Der Skill arbeitet plattformunabhängig und ist mit Claude Code, Cursor, Codex und anderen KI-Agenten kompatibel.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/TomasValleDuran/pomos-skillzzeria/tree/HEAD/plugins/skillzzeria/skills/design-system-builder

In Ihrer bevorzugten KI fragen

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

Dokumentation

Was macht Design-System-Builder?

Ein Designsystem ist eine Sammlung von einmal getroffenen Entscheidungen, sodass nicht jeder Bildschirm sie neu treffen muss. Tokens halten die Entscheidungen, Komponenten wenden sie an, Dokumentation erklärt sie. Skaliere den Aufwand auf das Projekt: Eine App für ein Wochenende braucht eine 40-zeilige Token-Datei und eine DESIGN.md; ein Multi-Team-Produkt benötigt Pipelines und Governance. Starte klein, wachse durch Extraktion.

Prozess

0. Lese, was existiert

Suche nach: Tokens/Theme-Dateien, tailwind-Konfiguration oder @theme-Blöcke, components.json, CSS-Variablen, einem theme/-Modul, Figma-Links (verwende den Figma MCP get_variable_defs/search_design_system, falls verbunden), DESIGN.md/.interface-design/system.md. In bestehenden Codebasen extrahiere vor dem Erfinden: Grep die tatsächlich verwendeten Farben, Schriftgrößen, Abstände und Radien, gruppiere sie und schlage die konsolidierte Skala vor. Zeige dem Benutzer das Vorher→Nachher-Mapping.

1. Definiere die Richtung (ein Absatz)

Wer es nutzt, wie es sich anfühlen soll (in konkreten Worten: "dicht wie ein Handelsterminal", "ruhig wie eine Lese-App"), Plattform(en), Markenbeschränkungen, Dichte, Hell/Dunkel. Dies treibt alle folgenden Skalenentscheidungen. Wenn interface-design- oder frontend-design-Skills im Spiel sind, übernehmen diese den ästhetischen Schritt; dieser Skill verwandelt die Richtung in ein System.

2. Grundlagen (Tokens)

Baue in dieser Reihenfolge – jedes hängt vom vorherigen ab:

  1. Farbe → Führe das Tool des color-theory-Skills aus: python3 <skills-dir>/color-theory/scripts/palette.py system <brand-hex> --format tailwind|css|json (color-theory ist ein Geschwisterverzeichnis dieses Skills). Es erzeugt primitive Rampen + verifizierte helle/dunkle semantische Rollen.
  2. Typografie → Schriftfamilien (≤2, plus Mono), eine Schriftskala mit benannten Rollen, Zeilenhöhen, Gewichten, Tracking. Siehe references/scales.md.
  3. Abstand → 4px-Basisraster; T-Shirt- oder numerische Skala; Layout-Abstände getrennt von Komponenten-Padding.
  4. Form → Radius-Skala (und eine Regel für Verschachtelung: innerer Radius = äußerer − Padding), Rahmenbreiten.
  5. Höhe → Schatten-Skala (hell) und Oberflächenhelligkeitsstufen (dunkel), Z-Index-Ebenen.
  6. Bewegung → Dauern + Übergangsfunktionen als Tokens (und reduzierte-Bewegung-Verhalten).
  7. Layout → Breakpoints, Containerbreiten, Rasterspalten, sichere Bereiche (mobil).
  8. Größe → Steuerelement-Höhen (sm/md/lg), Symbolgrößen, minimale Touch-Ziele.

3. Token-Architektur

Drei Ebenen – Komponenten dürfen nur die semantische (oder Komponenten-)Ebene konsumieren:

primitive   --blue-600, --space-4, --radius-2          Rohwerte, benannt nach dem, was sie SIND
semantisch  --color-accent, --space-inset-md, --radius-control   Benannt nach der AUFGABE, aliasen primitive Werte, wechseln pro Theme
Komponente  --button-bg, --card-padding                 Optional; nur für Komponenten mit echtem Theming-Bedarf

Theme-Wechsel (Dark Mode, Marken, Dichte, hoher Kontrast) = Neuausrichtung semantischer Tokens. Komponenten ändern sich nie. Vollständige Namensregeln, DTCG-Format, Modi: references/token-architecture.md.

4. Auf die Plattform(en) ausliefern

  • Einzelne Web-App: Handgeschriebene CSS-Variablen + Tailwind v4 @theme sind ausreichend.
  • Web + mobil oder mehrere Apps: Erstelle Tokens in DTCG JSON (eine Quelle), baue mit Style Dictionary v5 oder Terrazzo in CSS, Tailwind, TS, Swift, Kotlin/Compose, Flutter, RN. Rezepte und Ausgabebeispiele pro Plattform: references/platform-outputs.md. Starter-DTCG-Datei: assets/tokens.example.json.

5. Komponenten

Baue auf zugänglichen Primitiven auf (siehe ui-stack-advisor). Konsistente API: variant (visuelle Absicht), size, tone/color nur bei Bedarf, Zustände über Datenattribute, Komposition über Konfiguration. Jede Komponente dokumentiert alle Zustände: Standard, Hover, Aktiv, Focus-visible, Deaktiviert, Laden, Fehler, Leer, Ausgewählt, Schreibgeschützt. Konventionen und Checkliste: references/components.md.

6. Dokumentieren und verwalten

Schreibe DESIGN.md im Projektstammverzeichnis aus assets/DESIGN.template.md – Richtung, Token-Tabelle, Komponenten-Inventar, Do's/Don'ts und das Warum hinter Entscheidungen. Diese Datei ist das, was zukünftige Sitzungen lesen, um konsistent zu bleiben; halte sie kurz und aktuell. Größere Systeme fügen Storybook (oder Ladle/Histoire), visuelles Regressionstesting, ein Changelog mit Semver und einen Beitragsprozess hinzu (references/components.md#governance).

Standardwerte, die funktionieren (wenn der Benutzer keine Präferenz hat)

GrundlageStandard
Basiseinheit4px; Abstandsskala 0, 1, 2, 4, 6, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96 px
Schriftskala12, 14, 16 (Textkörper), 18, 20, 24, 30, 36, 48, 60 px (≈1.2–1.25 Verhältnis); Produkt-UI können 14px Textkörper verwenden
Zeilenhöhe1.5 Textkörper, 1.2–1.3 Überschriften, 1.1 Display; Tracking bei großen Größen straffen (−0.01 bis −0.03em)
Radius0, 4, 6, 8, 12, 16, 24, voll – wähle eine Persönlichkeit: scharf (2–4), weich (8–12), rund (16+) und wende sie konsistent an
SteuerelementeHöhen 32 / 36–40 / 44–48 px; Touch-Ziele ≥ 44pt (iOS) / 48dp (Android) / 24px min WCAG 2.2 (ziel 44)
Bewegung100 / 150 / 200 / 300 / 500 ms; Ease-out cubic-bezier(0.23,1,0.32,1) für Eintritt, Ease-in-out für Bewegung, Federn auf Mobilgeräten
Breakpoints640, 768, 1024, 1280, 1536 (Tailwind); bevorzuge Container-Queries für Komponenten
Höhe4–5 Schattenebenen; Dark Mode verwendet hellere Oberflächen + subtile Ränder stattdessen
Z-IndexBasis 0, Dropdown 1000, Sticky 1100, Overlay 1300, Modal 1400, Popover 1500, Toast 1600, Tooltip 1700

Standardwerte sind eine Basis, kein Stil. Die Unterscheidungskraft kommt von den variierenden Entscheidungen: Schriftart, Akzentfarbe, Neutrale-Temperatur, Radius-Persönlichkeit, Dichte und Bewegungscharakter.

Qualitätsbarriere (vor Fertigmeldung prüfen)

  • Keine Rohwerte in Komponenten (Hex, px Schriftgrößen, willkürliche Abstände) – grep sie
  • Semantische Namen beschreiben Aufgaben, nicht Werte oder Farbtöne
  • Hell + Dunkel beide entworfen und kontrastgeprüft (WCAG 2.2 AA)
  • Jede interaktive Komponente hat sichtbare Fokus-, Deaktiviert-, Lade-, Fehlerzustände
  • Schriftskala hat benannte Rollen (display, h1–h3, body, label, caption, code), nicht nur Größen
  • Abstände konsistent: gleiche Beziehung → gleicher Token
  • Reduzierte-Bewegung-Variante für Bewegungs-Tokens
  • DESIGN.md geschrieben und korrekt
  • Mobil: Dynamic Type / Schrift-Skalierung beachtet, sichere Bereiche als Tokens, Touch-Ziele ≥ 44/48

Referenzen

  • references/token-architecture.md – Ebenen, Namensgrammatik, DTCG 2025.10-Format, Modi/Themes, Aliasing-Regeln
  • references/scales.md – Typografie (Skalen, flüssige Schrift, Paarung), Abstand, Radius, Höhe, Bewegung, Dichte, Breakpoints
  • references/platform-outputs.md – CSS, Tailwind v4, Shadcn-Theming, React Native (NativeWind/Unistyles/Tamagui), Flutter, SwiftUI, Compose, Style Dictionary/Terrazzo-Pipeline
  • references/components.md – Komponenten-API-Konventionen, Anatomie, Zustandsmatrix, Komposition, Dokumentation, Testing, Governance
  • assets/tokens.example.json – Starter-DTCG-Token-Datei
  • assets/DESIGN.template.md – DESIGN.md-Vorlage

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

TomasValleDuran/color-theory

Color theory and palette engineering for UI on any platform (web, iOS, Android, Flutter, React Native). Choose and derive brand palettes, build tonal ramps, tinted neutrals and status colors, map them to light/dark semantic tokens, and verify contrast (WCAG 2.2 + APCA) and color-blind safety with a bundled zero-dependency OKLCH tool. Use this whenever the user picks, generates, critiques or fixes colors — "what colors should I use", brand color, palette, color scheme, theme, dark mode colors, accent, gradient, "this looks dull/garish", contrast problems, color-blind friendliness, or turning one hex into a full system — even if they don't say "color theory".

TomasValleDuran/ui-stack-advisor

Curated, up-to-date knowledge of UI component libraries, animation libraries and building blocks (icons, charts, tables, forms, toasts, drag-and-drop, virtualization, rich text) for web (React, Next.js, Vue, Svelte, Solid, Angular) and mobile (React Native/Expo, Flutter, SwiftUI, Jetpack Compose), with a decision process for picking one. Use this whenever a project is being started or scaffolded, when the user asks "which UI library / component library / design kit should I use", compares libraries (shadcn vs MUI vs Mantine, Tamagui vs NativeWind, etc.), needs a specific widget (date picker, data table, command palette, carousel, bottom sheet, chart), wants "cool animated components", or when you are about to hand-roll a component that a mature library already solves well.

TomasValleDuran/ui-ux-playbook

The entry point for any UI/UX work on web or mobile — the end-to-end workflow (brief → direction → system → stack → build → motion → verify), industry standards and best practices (WCAG 2.2, Apple HIG, Material 3, Nielsen heuristics, Laws of UX, Core Web Vitals, forms, navigation, states, i18n), a pre-ship UI checklist, and a routing map telling you which specialized design/animation/color/library skill to load for each sub-task. Use this whenever you start or plan a frontend or mobile app, build or redesign screens, review UI/UX quality, answer "what's the best practice for X" in interface design, or when several design skills could apply and you need to decide which.

Verwandte Skills