Designsystem aus Frontend-Code extrahieren
Analysiere Frontend-Quellcode, um ein umfassendes Designsystem-Dokument (DESIGN.md) zu extrahieren, das die visuelle Sprache des Projekts erfasst – Farben, Typografie, Abstände, Komponentenmuster und Layout-Prinzipien – direkt aus den Quelldateien, ohne die Anwendung bauen oder rendern zu müssen.
Warum es das gibt
Der design-md-Skill arbeitet mit gerendertem HTML. Aber oft hat man eine Codebasis und möchte deren Designsystem verstehen, bevor man die App überhaupt ausführen kann – vielleicht fehlen Abhängigkeiten, der Build ist defekt oder man möchte einfach eine schnelle Prüfung. Dieser Skill liest die Quelldateien selbst: Stylesheets, Komponentendateien, Theme-Konfigurationen und Tailwind-Setups. Er ist schneller und funktioniert überall.
Wann verwenden
- Der Nutzer hat eine Frontend-Codebasis und möchte deren Designsystem extrahieren oder dokumentieren
- Der Nutzer möchte die visuelle Identität eines Projekts zu Stitch migrieren
- Der Nutzer bittet darum, „das Styling zu prüfen“ oder „die Designsprache“ eines Repos zu verstehen
- Der Nutzer möchte aus vorhandenem Quellcode eine DESIGN.md erstellen
- Die App kann nicht gebaut/gerendert werden, aber der Quellcode ist verfügbar
- Der Nutzer möchte inkonsistente Styles in einer Codebasis vereinheitlichen oder abgleichen
Voraussetzungen
- Zugriff auf das Quellverzeichnis des Frontend-Projekts
- Keine Build- oder Laufzeitabhängigkeiten erforderlich – dieser Skill liest nur Quelldateien
Arbeitsablauf
Phase 1: Projektentdeckung
Beginne damit zu verstehen, womit du arbeitest. Das bestimmt, welche Extraktionsmuster verwendet werden.
1. Framework und Stack erkennen
Scanne das Projektverzeichnis nach charakteristischen Dateien:
| Signaldaten | Framework / Tool |
|---|---|
package.json mit react | React / Next.js |
package.json mit vue | Vue / Nuxt |
package.json mit svelte | Svelte / SvelteKit |
package.json mit @angular/core | Angular |
tailwind.config.js/ts | Tailwind CSS |
postcss.config.js | PostCSS-Pipeline |
styled-components oder @emotion in Abhängigkeiten | CSS-in-JS |
Nur .css / .scss / .less-Dateien | Reines CSS / SASS |
theme.js / theme.ts / tokens.js | Design-Token-Dateien |
Lies zuerst package.json – es zeigt Framework, CSS-Tooling und etwaige Design-Token-Bibliotheken (z.B. style-dictionary, @chakra-ui/react, @mui/material, ant-design). Dieser Kontext sagt dir, wo du nach Styling-Informationen suchen musst.
2. Quellbaum abbilden
Identifiziere die wichtigsten Verzeichnisse und Dateien, die du analysieren wirst:
src/
├── components/ ← Komponenten-Styles
├── styles/ ← Globale Stylesheets
├── theme/ ← Theme-Definitionen, Tokens
├── assets/ ← Schriftarten, Bilder
├── app.css ← Root-Styles
└── index.css ← Einstiegs-CSS
Überprüfe außerdem:
tailwind.config.js/tailwind.config.ts– Benutzerdefinierte Farben, Schriftarten, Abständeglobals.css/global.css– CSS-Custom-Properties (Variablen)- Alle
theme.*- odertokens.*-Dateien - Komponentenbibliotheks-Konfiguration (z.B.
chakra-theme.ts,vuetify.config.ts)
3. Frameworkspezifische Anleitung lesen
Konsultiere die entsprechende Referenz für Extraktionsmuster:
- React / Next.js / Tailwind → references/react-tailwind.md
- Vue / Nuxt → references/vue.md
- Svelte / SvelteKit → references/svelte.md
- Angular → references/angular.md
- Reines CSS / SASS / Less → references/plain-css.md
Diese Referenzen enthalten frameworkspezifische Muster zum Auffinden von Farben, Typografie, Abständen und Komponenten-Styles. Lies die passende, bevor du fortfährst.
Phase 2: Tiefenextraktion
Arbeite jede Design-Dimension systematisch durch. Sammle für jede Rohdaten aus den Quelldateien und synthetisiere sie in beschreibende Sprache.
Das Ziel ist nicht, jede CSS-Eigenschaft auszugeben – es geht darum, die Absicht hinter den Styling-Entscheidungen zu verstehen und sie in einer menschenlesbaren, redaktionellen Sprache zu beschreiben, die ein anderer Designer (oder Stitch) verwenden kann, um das gleiche visuelle Gefühl nachzubilden.
1. Visuelles Thema & Atmosphäre
Lies zuerst die breitesten Stylings, um die Gesamtstimmung zu verstehen:
- Root-Hintergrund: Was ist der
body- oder Root-Element-Hintergrund? Helles Creme (#f-Bereich) signalisiert luftig/sauber; dunkel (#0-#2-Bereich) signalisiert stimmungsvoll/dramatisch. - Whitespace-Philosophie: Sind die Abstandswerte großzügig (32px+) oder eng? Überprüfe Padding/Margin-Werte auf Root-Containern, Abschnitts-Wrappern und Kartenkomponenten.
- Dichte: Zähle die Komponenten pro Seite/Abschnitt. Wenige mit viel Platz = minimalistisch; viele dicht gepackt = informationsdicht.
- Farbtemperatur: Sind die Neutraltöne warm (Creme-, Töne) oder kühl (Blautöne, Schiefer)?
- Gesamteindruck: Synthetisiere in 1-2 reichhaltige Sätze, die die Stimmung einfangen.
Suche nach diesen Signalen im Quellcode:
| Quellort | Was es dir sagt |
|---|---|
background-color des Root-Elements oder bg-* von Tailwind auf Layouts | Gesamthelligkeit/-dunkelheit |
| Abstandsskala in Tailwind-Config oder CSS-Variablen | Whitespace-Philosophie |
| Anzahl der Komponenten im Vergleich zum Wrapper-Padding | Dichte |
Benennung von Custom Properties (--warm-* vs --cool-*) | Farbtemperatur-Absicht |
| Kommentare in Theme-Dateien | Design-Absicht in den eigenen Worten des Entwicklers |
2. Farbpalette & Rollen
Extrahiere jede eindeutige Farbe aus der Codebasis und weise funktionale Rollen zu. Durchsuche alle Ebenen:
Wo Farben zu finden sind:
| Ebene | Wonach suchen |
|---|---|
| CSS-Custom-Properties | --color-*, --primary, --bg-* |
| Tailwind-Config | theme.extend.colors |
| Theme-/Token-Dateien | Farbobjekte, Paletten |
| Komponenten-Styles | background-color, color, border-color |
| Inline-/Scoped-Styles | bg-*, text-*-Klassen in Templates |
| CSS-in-JS-Theme-Objekte | colors, palette-Schlüssel |
So organisierst du: Gruppiere Farben nach Funktion, nicht nach Farbton:
- Primäre Basis – Hintergrund- und Oberflächenfarben
- Akzente & Interaktion – CTA-Buttons, aktive Zustände, Links
- Typografie & Texthierarchie – Primärer, sekundärer, tertiärer Text
- Funktionale Zustände – Erfolg, Fehler, Warnung, Info
Erstelle für jede Farbe einen beschreibenden Namen, der den Charakter der Farbe hervorruft und nicht ihren rohen Hex-Wert:
- ❌
#294056→ „Blau“ - ✅
#294056→ „Tiefes, gedämpftes Blaugrau“ – Primärer CTA, aktive Navigation
Entdoppelung ist wichtig. Codebasen haben oft fast identische Farben (z. B. #333 und #2C2C2C). Fasse sie unter einem Namen zusammen, der die beabsichtigte Farbe am besten repräsentiert.
3. Typografie-Regeln
Extrahiere das vollständige typografische System:
Schriftfamilien:
- Überprüfe CSS
font-family, TailwindfontFamily, Google Fonts-Links oder lokale@font-face-Deklarationen. - Notiere den Charakter jeder Schriftart: geometrisch vs humanistisch, Serife vs serifenlos, das Gefühl, das sie vermittelt.
Schriftgrößen-Skala (Hierarchie):
- Finde jede Überschriftenebene (H1-H6) und Fließtext, notiere:
font-size(in rem oder px)font-weight(numerischer Wert + beschreibender Name)letter-spacing(und warum – Eleganz? Kompaktheit?)line-height(großzügig für Lesbarkeit? eng für Anzeige?)
- Ordne die Komponentenverwendung zu: Welche Überschriftenebene verwenden Produktkarten? Was ist mit Hero-Abschnitten?
Abstandsprinzipien:
- Wie hängt der Textabstand mit der gesamten Abstandsskala zusammen?
- Muster des Buchstabenabstands bei Überschriften gegenüber Fließtext
- Line-Height-Philosophie (großzügig/entspannt für Fließtext, enger für Anzeige)
4. Komponenten-Stylings
Analysiere die 4-5 wichtigsten UI-Primitive:
Buttons:
- Eckradius (und was er kommuniziert – verspielt? professionell? minimalistisch?)
- Farbschema für primäre, sekundäre und Ghost-Varianten
- Hover-/Fokus-/Aktivzustände und Übergangszeiten
- Padding-Verhältnisse (horizontal vs vertikal)
Karten / Container:
- Eckradius (oft anders als bei Buttons – etwas runder)
- Shadow-Strategie: flache, subtile Hover-Schatten oder immer erhaben?
- Randbehandlung: feine Linien, farbige Akzente oder keine?
- Innenabstand (großzügig oder kompakt?)
- Bildbehandlung innerhalb von Karten (randlos, mit Padding, abgerundet?)
Navigation:
- Layout-Muster (horizontale Leiste, vertikale Seitenleiste, Drawer)
- Typografische Behandlung (Großbuchstaben, Buchstabenabstand, Schriftstärke)
- Aktiv-/Hover-Zustandsanzeigen (Unterstrich, Farbe, Hintergrund)
- Mobiles Verhalten (Hamburger, untere Navigation, Drawer)
Eingabefelder & Formulare:
- Randstil und Verhalten des Fokus-Zustands
- Konsistenz der Eckenstile mit Buttons
- Padding- und Touch-Target-Größe
Domänenspezifische Komponenten:
- Identifiziere 1-2 Komponenten, die für dieses Projekt einzigartig sind (z. B. Produktkarten, Dashboard-Widgets, Chat-Bläschen) und beschreibe ihre Styling-Muster.
5. Layout-Prinzipien
Extrahiere das strukturelle System:
Raster & Struktur:
- Maximale Inhaltsbreite (aus
max-widthauf Containern) - Spaltensystem (CSS Grid, Flexbox-Muster, definierte Breakpoints)
- Responsive Breakpoints (aus Media Queries oder Tailwind-Config)
Whitespace-Strategie:
- Basis-Abstandseinheit (8px-Raster? 4px? benutzerdefiniert?)
- Abschnittsabstände (wie viel Abstand zwischen Hauptabschnitten)
- Randabstände (Seitenränder bei verschiedenen Breakpoints)
Ausrichtung & visuelles Gleichgewicht:
- Textausrichtungsmuster (zentrierte Hero-Abschnitte, linksbündiger Fließtext)
- Bild-zu-Text-Verhältnisse
- Verteilung des visuellen Gewichts
Responsives Verhalten:
- Mobile-First oder Desktop-First?
- Wie brechen Raster zusammen? Padding-Skala?
- Touch-Target-Größe
6. Notizen zur Stitch-Generierung
Synthetisiere die Extraktion in umsetzbare Anweisungen für Stitch:
- Atmosphärensprache: Übersetze die Stimmung in natürliche Beschreibungen
- Farbreferenzen: Liste Farben nach beschreibendem Namen + Hex auf
- Komponenten-Prompts: Schreibe 2-3 Beispiel-Prompts, die Schlüsselkomponenten in Stitch nachbilden würden
- Iterationsanleitung: Tipps zur Verfeinerung von Bildschirmen in diesem Designsystem
Phase 3: DESIGN.md schreiben
Füge alles im Standard-DESIGN.md-Format zusammen. Platziere es unter .stitch/DESIGN.md im Projektverzeichnis (erstelle das .stitch/-Verzeichnis, falls es nicht existiert).
[!IMPORTANT] Du MUSST den YAML-Frontmatter am Anfang der Datei mit
name- undcolors-Mapping einfügen, genau wie im Beispiel unter examples/DESIGN.md gezeigt. Diese strukturierten Daten werden von anderen Skills benötigt, um das Designsystem zu parsen.Das Fehlen dieses YAML-Blocks mit mindestens den Kern-Farb-Tokens ist ein Fehler in der korrekten Verwendung dieses Skills.
Verwende das Format aus dem Beispiel unter examples/DESIGN.md als Vorlage. Die Datei muss mit dem YAML-Block beginnen, gefolgt von den Markdown-Abschnitten:
# Designsystem: [Projektname]
**Projekt-ID:** [Falls bekannt, sonst weglassen]
## 1. Visuelles Thema & Atmosphäre
[Reichhaltige 2-Absatz-Beschreibung von Stimmung, Philosophie und Hauptmerkmalen]
## 2. Farbpalette & Rollen
### Primäre Basis
### Akzente & Interaktion
### Typografie & Texthierarchie
### Funktionale Zustände
## 3. Typografie-Regeln
### Hierarchie & Schriftstärken
### Abstandsprinzipien
## 4. Komponenten-Stylings
### Buttons
### Karten & [domänenspezifische Container]
### Navigation
### Eingabefelder & Formulare
### [Domänenspezifische Komponenten]
## 5. Layout-Prinzipien
### Raster & Struktur
### Whitespace-Strategie
### Ausrichtung & visuelles Gleichgewicht
### Responsives Verhalten & Touch
## 6. Notizen zum Designsystem für die Stitch-Generierung
### Zu verwendende Sprache
### Farbreferenzen
### Komponenten-Prompts
### Inkrementelle Iteration
Phase 4: Integration (optional)
Wenn der Nutzer das Designsystem in Stitch übernehmen möchte:
- Übergib an den
manage-design-system-Skill für die MCP-Erstellungs-/Aktualisierungsaufrufe - Die von dir geschriebene DESIGN.md ist die Eingabe – der
manage-design-system-Skill übernimmt die Stitch-API-Integration
Wenn der Nutzer nur das Dokument möchte, bist du nach Phase 3 fertig.
Qualitäts-Checkliste
Bevor du die DESIGN.md auslieferst, überprüfe:
- Jede Farbe hat einen beschreibenden Namen, Hex-Code und eine funktionale Rolle
- Die Typografie enthält Schriftfamilie, Charakterbeschreibung und vollständige Hierarchie
- Komponentenstile beschreiben Form, Farbe, Zustände und Übergänge
- Das Layout umfasst maximale Breite, Raster, Breakpoints und Abstandsstrategie
- Notizen zur Stitch-Generierung verwenden natürliche Sprache, nicht CSS-Syntax
- Der Atmosphärenabschnitt liest sich wie redaktioneller Text, nicht wie technische Dokumentation
- Fast identische Farben wurden zusammengefasst
- Das Dokument erfasst die Absicht hinter dem Styling, nicht nur die Rohwerte
Tipps für eine bessere Extraktion
- Lies Kommentare und Commit-Nachrichten. Entwickler dokumentieren Design-Absichten oft in Code-Kommentaren (
/* Hero-Bereich – luftig */) und Commit-Nachrichten. Diese sind Gold wert, um das Warum zu verstehen. - Suche nach Design-Token-Bibliotheken. Wenn das Projekt
style-dictionary,@tokens-studiooder ähnliches verwendet, sind diese Dateien die maßgeblichste Quelle für Designwerte. - Theme-Dateien sind aussagekräftiger als Komponentenstile. Eine
theme.ts, die eine Palette definiert, sagt dir das beabsichtigte Designsystem; verstreute Inline-Styles in Komponenten sagen dir, was tatsächlich ausgeliefert wurde. Beide sind wichtig, aber beginne mit dem Theme. - Die Tailwind-Config ist ein Designsystem. Wenn ein Projekt eine benutzerdefinierte
tailwind.config.jshat, ist das das Designsystem – extrahiere zuerst daraus und überprüfe dann stichprobenartig Komponenten auf Überschreibungen. - CSS-Custom-Properties sind absichtsvoll. Wenn ein Entwickler
--brand-primarydefiniert hat, sagt er dir, dass dies ein Design-Token ist. Respektiere das.