145 lines
6.8 KiB
Markdown
145 lines
6.8 KiB
Markdown
|
|
---
|
|
name: styleguide erstellung
|
|
description: Verwenden für jede Weiterentwicklung oder Prüfung des zentralen Styleguides: CSS, HTML, Tokens, Components, Patterns, Layouts, Templates, Doku oder Styleguide-Struktur. Erzwingt ein kaskadierendes, portalübergreifendes Design-System ohne lokale Insellösungen, Workarounds, Hardcoded Design Values oder redundante UI-Bausteine.
|
|
---
|
|
|
|
# Styleguide-Erstellung
|
|
|
|
## Ziel
|
|
|
|
Pflege den Styleguide als zentrales Design-System für mehrere modulare Webportale.
|
|
|
|
- Core: allgemeine Foundations, semantische Tokens, Components, Patterns und Guidelines für alle Portale.
|
|
- Portal-spezifisch: nur klar benannte Layouts/Templates/Pages, z. B. mit Portalname im Dateinamen.
|
|
- Ergebnis: cleanes, produktionsreifes Template ohne lokale Styles, Overrides, Workarounds, Legacy-Reste oder visuelle Nachbauten.
|
|
|
|
## Kaskade
|
|
|
|
Immer diese Ebene wählen und einhalten:
|
|
|
|
```text
|
|
Foundations → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines
|
|
```
|
|
|
|
Regeln:
|
|
|
|
- Foundations sind die einzige Quelle konkreter Designwerte: Farben, Typografie, Spacing, Radius, Shadows, Motion, Breakpoints, Z-Index, Containergrößen.
|
|
- Neue Foundation Tokens nur nach expliziter Freigabe; bestehende Foundation Tokens bevorzugt wiederverwenden.
|
|
- Semantische Tokens sind Aliase/Kaskaden auf Foundation Tokens; nie hardcoded Design Values.
|
|
- Components, Patterns, Layouts, Templates, Pages und HTML dürfen keine eigenen Foundation Tokens, lokalen `:root`-Blöcke oder hardcoded Design Values enthalten.
|
|
- Jede neue/geänderte CSS-Datei muss in `styleguide.css` importiert sein; `styleguide.css` ist der einzige CSS-Einstiegspunkt.
|
|
|
|
## Ebenenregeln
|
|
|
|
### Core vs. Portal
|
|
|
|
- Foundations, globale semantische Tokens, Components und generische Patterns sind portalübergreifend.
|
|
- Portal-spezifische Layouts/Templates/Pages dürfen Core-Bausteine komponieren, aber nicht duplizieren, überschreiben oder visuell nachbauen.
|
|
- Portal-spezifische Dateien müssen eindeutig nach Portal benannt sein.
|
|
- Wird eine portal-spezifische Lösung für mehrere Portale relevant, abstrahiere sie in den Core.
|
|
- Fachliche Bedeutung oder Dateninterpretation gehört ins jeweilige Portal/owning Fachmodul, nicht in den Styleguide.
|
|
|
|
### Components
|
|
|
|
- Components sind kanonische UI-Bausteine.
|
|
- Ohne Freigabe nicht verändern: HTML, Klassen, Nesting, Semantik, Varianten.
|
|
- Component-Internals nie von außen überschreiben.
|
|
- Components nie visuell nachbauen.
|
|
|
|
### Patterns
|
|
|
|
- Patterns komponieren bestehende Components für Anwendungsfälle.
|
|
- Erlaubt: Pattern-Klassen, Wrapper, Layout, Responsiveness.
|
|
- Verboten: Component-Optik duplizieren, Component-Internals stylen, Components ersetzen.
|
|
- Falls ein Pattern Component-Internals stylen müsste: stoppen und Component-Token/-Variante oder andere Architekturentscheidung vorschlagen.
|
|
|
|
### Layouts und Templates/Pages
|
|
|
|
- Layouts regeln Struktur, Container, Raster, Anordnung und Responsiveness.
|
|
- Templates/Pages sind reine Komposition aus Layouts, Patterns und Components.
|
|
- Sie dürfen keine neuen Foundations, Token-Logiken, Component-Varianten, lokalen Styles oder visuellen Regeln einführen.
|
|
|
|
### Dokumentation
|
|
|
|
Nachführen, wenn betroffen:
|
|
|
|
- `index.html` bei neuen HTML-Seiten
|
|
- `foundations.html` bei Foundation-Änderungen
|
|
- semantische Token-Seiten bei Token-Änderungen
|
|
- betroffene Component-, Pattern-, Layout-, Template- oder Page-Doku
|
|
|
|
## CSS-Struktur
|
|
|
|
- Foundation Tokens: nur in vorgesehenen Foundation-/Base-Dateien, insbesondere `01-foundations.css` und, falls vorhanden/strukturell vorgesehen, `02-base.css`.
|
|
- Semantische Tokens: nur in vorgesehenen zentralen Token-Bereichen oder klar zugeordneten Component-/Pattern-/Layout-/Template-Dateien; immer über `styleguide.css` importiert.
|
|
- Components, Patterns, Layouts und Templates liegen in eigenen Dateien der passenden Ebene; keine Ebenen vermischen.
|
|
- Neue CSS-Datei nur bei klar neuer Verantwortung; sonst bestehende Datei erweitern.
|
|
- Portal-spezifische CSS-Dateien nur für klar abgegrenzte Layouts/Templates/Pages und mit Portalname im Dateinamen.
|
|
- Import-Reihenfolge: Foundations/Base → globale semantische Tokens → Components → Patterns → allgemeine Layouts → portal-spezifische Layouts → allgemeine Templates/Pages → portal-spezifische Templates/Pages.
|
|
|
|
## Arbeitsablauf
|
|
|
|
Vor Umsetzung:
|
|
|
|
1. Task-Scope bestimmen.
|
|
2. Relevanten Code und Doku im Scope prüfen.
|
|
3. Ebene bestimmen.
|
|
4. Core oder portal-spezifische Erweiterung bestimmen.
|
|
5. Bestehende Tokens, Components, Patterns, Layouts und Templates auf Wiederverwendung prüfen.
|
|
6. Nötige Doku-Nachführung bestimmen.
|
|
7. Bei nicht belegten Punkten Rückfrage stellen.
|
|
|
|
Nicht belegte Punkte nicht umsetzen. Aussagen klassifizieren als: belegt, plausibel, nicht belegt.
|
|
|
|
## Verbote
|
|
|
|
Nie einführen oder stehen lassen:
|
|
|
|
- lokale Styles, lokale `:root`-Blöcke, lokale Token-Blöcke
|
|
- hardcoded Design Values außerhalb Foundations
|
|
- überlagernde Korrektur-Styles statt Ursachenbehebung
|
|
- visuelle Nachbauten bestehender Components/Patterns
|
|
- portal-spezifische Duplikate von Core-Bausteinen
|
|
- Workarounds, Quickfixes, Legacy-Fehlmuster
|
|
- unimportierte oder verwaiste CSS-Dateien
|
|
- Refactorings außerhalb Scope ohne Freigabe
|
|
|
|
Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`.
|
|
|
|
## Selbstbereinigung vor Abschluss
|
|
|
|
Vor jeder Abschlussmeldung aktiv bereinigen:
|
|
|
|
- lokale Insellösungen, Overrides, Workarounds, Legacy-Reste und unsaubere Zwischenlösungen im bearbeiteten Scope entfernen
|
|
- lokale Korrekturen auf die richtige Ebene zurückführen: Foundation, semantischer Token, Component, Pattern, Layout oder Template
|
|
- keine Aufgabe als fertig melden, solange lokale Styles, hardcoded Werte, visuelle Nachbauten, doppelte Token, unimportierte CSS-Dateien oder veraltete Doku vorhanden sind
|
|
|
|
## Abschlusscheck
|
|
|
|
Vor Abschluss bestätigen:
|
|
|
|
- `AGENTS.md` und dieser Skill beachtet
|
|
- richtige Ebene und Core/Portal-Zuordnung gewählt
|
|
- Kaskade eingehalten
|
|
- keine lokalen Styles, Overrides, Workarounds, Legacy-Reste oder hardcoded Design Values
|
|
- neue/geänderte Foundation Tokens korrekt gepflegt und freigegeben
|
|
- neue/geänderte semantische Tokens korrekt gepflegt, importiert und dokumentiert
|
|
- alle relevanten CSS-Dateien in `styleguide.css` importiert
|
|
- Components unverändert bzw. nur mit Freigabe geändert
|
|
- Patterns bauen auf Components; Layouts/Templates/Pages bauen auf Patterns/Components
|
|
- betroffene Doku nachgeführt
|
|
- bearbeiteter Scope ist clean und produktionsreif
|
|
|
|
## Ergebnisbericht
|
|
|
|
Kurz berichten:
|
|
|
|
- geänderte und geprüfte Dateien
|
|
- Ebene und Core/Portal-Einordnung
|
|
- verwendete/ergänzte Tokens und Bausteine
|
|
- nachgeführte Doku
|
|
- entfernte Insellösungen/Workarounds, falls vorhanden
|
|
- Bestätigung von Abschlusscheck und Selbstbereinigung
|
|
- offene Punkte/Freigaben
|