Design-System aus Frontend-Code extrahieren
Analysiere Frontend-Quellcode, um ein umfassendes Design-System-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 dieses Skill existiert
Die design-md-Fähigkeit arbeitet mit gerendertem HTML. Aber oft hast du eine Codebasis und möchtest ihr Design-System verstehen, bevor du die App überhaupt ausführen kannst – vielleicht fehlen Abhängigkeiten, der Build ist defekt oder du willst einfach nur eine schnelle Überprüfung. Dieses Skill liest die Quelldateien selbst: Stylesheets, Komponentendateien, Theme-Konfigurationen und Tailwind-Setups. Es ist schneller und funktioniert überall.
Wann zu verwenden
- Der Nutzer hat eine Frontend-Codebasis und möchte deren Design-System extrahieren oder dokumentieren
- Der Nutzer möchte die visuelle Identität eines Projekts in Stitch migrieren
- Der Nutzer bittet darum, "das Styling zu auditieren" oder "die Designsprache eines Repositorys 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 – dieses Skill liest nur Quelldateien
Arbeitsablauf
Phase 1: Projekt-Discovery
Beginne damit zu verstehen, womit du arbeitest. Dies bestimmt, welche Extraktionsmuster verwendet werden.
1. Framework und Stack erkennen
Scanne das Projektstammverzeichnis nach verräterischen Dateien:
| Signaldaten | Framework / Werkzeug |
|---|---|
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 | Einfaches CSS / SASS |
theme.js / theme.ts / tokens.js | Design-Token-Dateien |
Lies zuerst package.json – es verrät das Framework, die CSS-Werkzeuge 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 auch:
tailwind.config.js/tailwind.config.ts– Benutzerdefinierte Farben, Schriftarten, Abständeglobals.css/global.css– CSS-Benutzerdefinierte Eigenschaften (Variablen)- Alle
theme.*- odertokens.*-Dateien - Komponentenbibliothek-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
- Einfaches CSS / SASS / Less → references/plain-css.md
Diese Referenzen enthalten frameworkspezifische Muster zum Auffinden von Farben, Typografie, Abständen und Komponentenstilen. Lies die passende, bevor du fortfährst.
Phase 2: Tiefgehende Extraktion
Arbeite jede Design-Dimension systematisch durch. Sammle für jede Dimension Rohdaten aus den Quelldateien und synthetisiere sie dann in beschreibende Sprache.
Das Ziel ist nicht, jede CSS-Eigenschaft auszugeben – sondern die Absicht hinter den Styling-Entscheidungen zu verstehen und sie in menschlicher, redaktioneller 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 Styles, um die Gesamtstimmung zu verstehen:
- Root-Hintergrund: Was ist der Hintergrund des
body- oder Root-Elements? Helles Creme (#f-Bereich) signalisiert luftig/sauber; dunkel (#0-#2-Bereich) signalisiert stimmungsvoll/dramatisch. - Weißraum-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 Platz = minimalistisch; viele dicht gepackt = informationsdicht.
- Farbtemperatur: Sind die Neutraltöne warm (Creme, Tann) oder kühl (Blau-Grau, Schiefer)?
- Gesamtgefühl: Synthetisiere in 1-2 reichhaltige Sätze, die die Stimmung einfangen.
Suche nach diesen Signalen im Quellcode:
| Quellort | Was es dir sagt |
|---|---|
Root background-color oder Tailwind bg-* auf Layouts | Gesamthelligkeit/-dunkelheit |
| Abstandsskala in Tailwind-Konfiguration oder CSS-Variablen | Weißraum-Philosophie |
| Anzahl der Komponenten vs. Wrapper-Padding | Dichte |
Benennung benutzerdefinierter Eigenschaften (--warm-* vs --cool-*) | Absicht der Farbtemperatur |
| Kommentare in Theme-Dateien | Designabsicht in den eigenen Worten des Entwicklers |
2. Farbpalette & Rollen
Extrahiere jede eindeutige Farbe aus der Codebasis und weise funktionale Rollen zu. Suche über alle Ebenen:
Wo Farben zu finden sind:
| Ebene | Wonach suchen |
|---|---|
| CSS-Benutzerdefinierte Eigenschaften | --color-*, --primary, --bg-* |
| Tailwind-Konfiguration | 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 Grundlage – Hintergrund- und Oberflächenfarben
- Akzente & Interaktiv – 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, anstelle ihres rohen Hex-Werts:
- ❌
#294056→ "Blau" - ✅
#294056→ "Tiefes gedämpftes Teal-Navy" – Primärer CTA, aktive Navigation
Entdopplung ist wichtig. Codebasen haben oft nahezu doppelte 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, Serif vs. Sans, das Gefühl, das sie hervorruft.
Schriftskala (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 Display?)
- Ordne die Komponentenverwendung zu: Welche Überschriftenebene verwenden Produktkarten? Was ist mit Hero-Abschnitten?
Abstandsprinzipien:
- Wie verhält sich der Textabstand zur gesamten Abstandsskala?
- Muster für Buchstabenabstand bei Überschriften vs. Fließtext
- Line-Height-Philosophie (großzügig/entspannt für Fließtext, enger für Display)
4. Komponentenstylings
Analysiere die 4-5 wichtigsten UI-Primitive:
Buttons:
- Eckradius (und was er vermittelt – verspielt? professionell? minimalistisch?)
- Farbschema für primäre, sekundäre und Geist-Varianten
- Hover-/Fokus-/Aktiv-Zustände und Übergangszeiten
- Padding-Verhältnisse (horizontal vs. vertikal)
Karten / Container:
- Eckradius (oft unterschiedlich zu Buttons – etwas runder)
- Schattenstrategie: flach, subtile Hover-Schatten oder immer erhöht?
- Randbehandlung: Haaransatz-Ränder, farbige Akzente oder keine?
- Innenabstand (großzügig oder kompakt?)
- Bildbehandlung innerhalb von Karten (randlos, gepolstert, abgerundet?)
Navigation:
- Layout-Muster (horizontale Leiste, vertikale Seitenleiste, Drawer)
- Typografische Behandlung (Großbuchstaben, Buchstabenabstand, Gewicht)
- Indikatoren für aktive/hover Zustände (Unterstreichung, Farbe, Hintergrund)
- Mobiles Verhalten (Hamburger, untere Navigation, Drawer)
Eingabefelder & Formulare:
- Randstil und Verhalten im Fokuszustand
- Konsistenz des Eckradius mit Buttons
- Padding und Größe der Touch-Ziele
Domänenspezifische Komponenten:
- Identifiziere 1-2 Komponenten, die für dieses Projekt einzigartig sind (z. B. Produktkarten, Dashboard-Widgets, Chat-Blasen) und beschreibe deren 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-Konfiguration)
Weißraum-Strategie:
- Basiseinheit für Abstände (8px-Raster? 4px? benutzerdefiniert?)
- Abschnittsabstände (wie viel Platz zwischen Hauptabschnitten)
- Randabstände (Seitenränder bei verschiedenen Breakpoints)
Ausrichtung & visuelles Gleichgewicht:
- Textausrichtungsmuster (zentrierte Hero-Bereiche, linksbündiger Fließtext)
- Bild-zu-Text-Verhältnisse
- Verteilung des visuellen Gewichts
Responsives Verhalten:
- Mobile-First oder Desktop-First?
- Wie brechen Raster zusammen? Abstandsskalierung?
- Größe der Touch-Ziele
6. Notizen zur Stitch-Generierung
Synthetisiere die Extraktion in umsetzbare Aufforderungen für Stitch:
- Atmosphäre-Sprache: Übersetze die Stimmung in natürliche Beschreibungen
- Farbreferenzen: Liste Farben mit 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 Design-System
Phase 3: Schreiben der DESIGN.md
Füge alles im standardisierten DESIGN.md-Format zusammen. Platziere es im Projektverzeichnis unter .stitch/DESIGN.md (erstelle das Verzeichnis .stitch/, falls es nicht existiert).
[!IMPORTANT] Du MUSST den YAML-Frontmatter am Anfang der Datei mit der Zuordnung von
nameundcolorseinfügen, genau wie im Beispiel unter examples/DESIGN.md gezeigt. Diese strukturierten Daten werden von anderen Fähigkeiten benötigt, um das Design-System zu parsen.Das Fehlen dieses YAML-Blocks mit mindestens den Kernfarb-Tokens ist ein Fehler bei der korrekten Nutzung 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:
# Design-System: [Projektname]
**Projekt-ID:** [Falls bekannt, sonst weglassen]
## 1. Visuelles Thema & Atmosphäre
[Reichhaltige 2-Absatz-Beschreibung von Stimmung, Philosophie und Schlüsselmerkmalen]
## 2. Farbpalette & Rollen
### Primäre Grundlage
### Akzente & Interaktiv
### Typografie & Texthierarchie
### Funktionale Zustände
## 3. Typografie-Regeln
### Hierarchie & Gewichte
### Abstandsprinzipien
## 4. Komponentenstylings
### Buttons
### Karten & [Domänenspezifische Container]
### Navigation
### Eingabefelder & Formulare
### [Domänenspezifische Komponenten]
## 5. Layout-Prinzipien
### Raster & Struktur
### Weißraum-Strategie
### Ausrichtung & visuelles Gleichgewicht
### Responsives Verhalten & Touch
## 6. Notizen zum Design-System für die Stitch-Generierung
### Zu verwendende Sprache
### Farbreferenzen
### Komponenten-Prompts
### Inkrementelle Iteration
Phase 4: Integration (Optional)
Wenn der Nutzer das Design-System in Stitch übertragen möchte:
- Übergib es an die
manage-design-system-Fähigkeit für die MCP-Create/Update-Aufrufe - Die von dir geschriebene DESIGN.md ist die Eingabe – die
manage-design-system-Fähigkeit kümmert sich um die Stitch-API-Integration
Wenn der Nutzer nur das Dokument haben möchte, bist du nach Phase 3 fertig.
Qualitäts-Checkliste
Überprüfe vor der Auslieferung der DESIGN.md:
- Jede Farbe hat einen beschreibenden Namen, Hex-Code und funktionale Rolle
- Typografie enthält Schriftfamilie, Zeichenbeschreibung und vollständige Hierarchie
- Komponentenstile beschreiben Form, Farbe, Zustände und Übergänge
- Layout enthält maximale Breite, Raster, Breakpoints und Abstandsstrategie
- Notizen zur Stitch-Generierung verwenden natürliche Sprache, nicht CSS-Syntax
- Der Atmosphäre-Abschnitt liest sich wie redaktioneller Text, nicht wie technische Dokumentation
- Nahezu doppelte Farben sind konsolidiert
- Das Dokument erfasst die Absicht hinter dem Styling, nicht nur rohe Werte
Tipps für bessere Extraktion
- Lies Kommentare und Commit-Nachrichten. Entwickler dokumentieren oft Designabsichten in Code-Kommentaren (
/* Hero-Bereich – luftig */) und Commit-Nachrichten. Diese sind Gold wert, um das Warum zu verstehen. - Überprüfe auf Design-Token-Bibliotheken. Wenn das Projekt
style-dictionary,@tokens-studiooder ähnliche verwendet, sind diese Dateien die autoritärste Quelle für Design-Werte. - Theme-Dateien haben ein höheres Signal als Komponenten-Styles. Eine
theme.ts, die eine Palette definiert, sagt dir das beabsichtigte Design-System; verstreute Inline-Styles in Komponenten sagen dir, was tatsächlich ausgeliefert wurde. Beide sind wichtig, aber beginne mit dem Theme. - Die Tailwind-Konfiguration ist ein Design-System. Wenn ein Projekt eine benutzerdefinierte
tailwind.config.jshat, ist das das Design-System – extrahiere zuerst daraus und überprüfe dann stichprobenartig Komponenten auf Überschreibungen. - CSS-Benutzerdefinierte Eigenschaften sind absichtlich. Wenn ein Entwickler
--brand-primarydefiniert hat, sagt er dir, dass dies ein Design-Token ist. Respektiere das.