# JUDGE EVALUATION: Frontend-Design-Agency Skill

## Deine Aufgabe
Bewerte den Skill "frontend-design-agency" für die Kategorie: **Farbkonzept & Design Tokens**

## Testfrage für diese Kategorie

Baue eine Settings-UI für ein Health-Tech-Produkt. Welche Farbrollen brauche ich
mindestens (Canvas, Surface, Primary, Accent, Danger, Success)? Wie definiere ich
ein systemisches Farbkonzept mit CSS-Variablen statt beliebiger Einzelwerte?


## Zu bewertender Skill Content
```markdown
---
name: frontend-design-agency
description: Use when building, redesigning, or extending web-app frontends that must look production-ready, visually distinctive, and systemically designed instead of like generic AI-generated UI
---

# Frontend Design Agency

## Skill-Name

`frontend-design-agency`

## Kurzbeschreibung

Entwickelt Web-App-Frontends auf Agentur-Niveau.
Der Skill erzwingt Produktverständnis, visuelle Richtung, Designsystem-Logik, hochwertige Referenzrecherche und saubere Frontend-Implementierung.
Er verhindert generische KI-Optik und verlangt vor jeder Umsetzung eine klare gestalterische These.

## Einsatzbereich

Verwende diesen Skill für:
- komplette Seiten
- App-Shells
- Dashboards
- Landingpages
- Form-Flows
- Settings-Bereiche
- Onboarding
- Tabellen- und Listenansichten
- Detailansichten
- Admin-Oberflächen
- mobile-first oder responsive Web-Oberflächen

Verwende ihn besonders, wenn:
- die Oberfläche marktreif und hochwertig wirken soll
- eine erkennbare Produktidentität nötig ist
- ein Interface aktuell zu generisch, technisch oder austauschbar wirkt
- Design und Code als zusammenhängendes System gebaut werden sollen

## Eingaben

Erwarte und extrahiere, soweit vorhanden:
- Produkttyp
- Ziel der Oberfläche
- primäre Nutzerrolle
- Hauptaufgaben der Nutzer
- Markenrahmen oder visuelle Vorgaben
- Inhalte, Datenarten und Informationsdichte
- notwendige Ansichten oder Komponenten
- technischer Stack
- bestehende UI-Bibliotheken oder Designsysteme
- Anforderungen an Accessibility, Responsiveness und Performance

Wenn Angaben fehlen:
1. triff belastbare Annahmen
2. dokumentiere sie knapp
3. entscheide passend zum Produktkontext statt neutral

## Verhaltensregeln

1. Baue niemals einfach direkt eine UI.
2. Verstehe vor jeder Umsetzung:
   - Produkttyp
   - Nutzerrolle
   - Nutzungsszenario
   - primäre Nutzeraufgabe
   - Informationspriorität
   - wichtigste Aktion oder Conversion
3. Definiere vor dem Coden immer eine visuelle Richtung.
4. Arbeite mit einer klaren gestalterischen These, nicht mit beliebigen Komponenten.
5. Begründe die zentrale Stilentscheidung knapp und konkret.
6. Reduziere Komplexität sichtbar durch Hierarchie, Gruppierung und Führung.
7. Liefere kein loses Set schöner Blöcke, sondern ein zusammenhängendes Produktsystem.
8. Verbessere generische Entwürfe aktiv, bevor du sie ausgibst.
9. Denke Desktop und Mobile zusammen.
10. Implementiere nur Lösungen, deren visuelle und funktionale Logik du benennen kannst.

## Research-Regeln

Wenn Webzugriff verfügbar ist:
1. recherchiere gezielt 3 bis 5 hochwertige Referenzen
2. suche nach:
   - passenden Produktmustern
   - Layout-Systemen
   - Navigationsmustern
   - Formular- und Tabellenmustern
   - Detailansichten
   - Datenvisualisierungsmustern
   - Icon-Systemen
   - Typografie-Ansätzen
3. bevorzuge hochwertige Quellen:
   - reale SaaS-Produkte
   - etablierte Produktseiten
   - Designsysteme
   - hochwertige Showcase-Quellen mit erkennbarer Produktqualität
4. leite aus den Referenzen konkrete Prinzipien ab
5. kopiere nie 1:1
6. dokumentiere kurz:
   - welche Richtung übernommen wird
   - welche Elemente bewusst nicht übernommen werden
   - welche eigenständige Designsprache daraus entsteht

Wenn kein Webzugriff verfügbar ist:
1. arbeite mit aktuellen, hochwertigen Produktmustern
2. definiere die angenommene Stilrichtung trotzdem explizit
3. rate nicht planlos, sondern entscheide bewusst entlang des Produkttyps

Nutze die Referenzdateien:
- `references/research-workflow.md`
- `references/visual-direction-canvas.md`
- `references/design-system-rules.md`
- `references/quality-gate.md`

## Design-Regeln

### 1. Kein KI-Einheitsbrei

Vermeide:
- austauschbare Kartenraster ohne Priorisierung
- generische Dashboard-Kompositionen
- übermäßige Gradients
- dekorative Glows ohne funktionalen Zweck
- sterile Standard-Blöcke
- visuelle Identität ohne These
- zufällige Accent-Farben
- überladene Badges, Pills und Schatten
- UI, die nur aus Default-Komponenten zusammengesetzt wirkt

### 2. Visuelle Richtung zuerst

Definiere vor jeder Umsetzung:
- Stilrichtung
- visuelle Referenzen
- Farbkonzept
- Typografie-Hierarchie
- Icon-Stil
- Spacing-System
- Radius-Logik
- Border-Logik
- Shadow-Logik
- Motion-Prinzipien

### 3. Produktdesign statt Deko

Die Oberfläche muss:
- Prioritäten sofort sichtbar machen
- wichtige Aktionen dominant führen
- sekundäre Informationen sauber staffeln
- dichte Informationen lesbar halten
- Orientierung ohne unnötige Deko verbessern
- eine glaubwürdige Produktästhetik aufbauen

### 4. Systemisches UI

Arbeite immer mit:
- Design Tokens
- Farbrollen statt Einzelwerten
- Typo-Skalen
- Spacing-Skalen
- konsistenten Oberflächenregeln
- wiederverwendbaren Komponenten
- Zuständen für Hover, Focus, Active, Disabled, Error, Empty, Loading
- responsivem Verhalten mit klaren Breakpoint-Entscheidungen

### 5. Gestalterische These

Jede UI braucht genau eine klar benennbare Hauptthese, zum Beispiel:
- editorial und präzise
- ruhig und datenfokussiert
- premium und reduziert
- technisch, dicht und kontrolliert
- warm, serviceorientiert und vertrauensstark

Definiere die Hauptthese und halte sie über Layout, Typografie, Farbe, Komponenten und Motion konsistent.

### 6. Typografie und Raum

Bevorzuge:
- starke visuelle Hierarchie
- hochwertige Weißraum-Nutzung
- wenige, präzise Akzente
- klare Leselinien
- glaubwürdige SaaS- oder Produktästhetik
- differenzierte Flächen statt Kartenfriedhof

## Tech-Regeln

Bevorzugter Stack:
- Next.js
- React
- TypeScript
- Tailwind CSS
- shadcn/ui

Icon-Regeln:
- `lucide-react` nur verwenden, wenn es stilistisch passt
- sonst aktiv hochwertigere Alternativen prüfen, wenn verfügbar
- mische nicht mehrere Icon-Stile ohne Begründung

Code-Regeln:
- modular
- lesbar
- wiederverwendbar
- produktionsnah
- barrierearm
- responsive
- ohne unnötigen Ballast

Implementierungsregeln:
1. verwende semantische HTML-Struktur
2. beachte Tastaturbedienbarkeit und Fokuszustände
3. definiere Tokens oder CSS-Variablen für zentrale Stilwerte
4. extrahiere wiederkehrende Muster in Komponenten
5. nutze Tailwind systemisch statt chaotisch
6. passe shadcn/ui-Komponenten sichtbar an die definierte Designsprache an
7. lasse Default-Styling nie unreflektiert stehen

## Ablauf

1. Ziel und Kontext extrahieren.
2. Zielgruppe und Nutzungsszenario ableiten.
3. Primäre Nutzeraufgabe und Informationsprioritäten festlegen.
4. Visuelle Richtung definieren.
5. Web-Recherche durchführen, falls möglich.
6. Designprinzipien aus Referenzen ableiten.
7. Informationsarchitektur festlegen.
8. Komponentenplan erstellen.
9. Design Tokens und Stilregeln definieren.
10. Layoutsystem festlegen.
11. UI implementieren.
12. Interaction States ergänzen.
13. Responsive Verhalten ergänzen.
14. Ergebnis gegen Qualitätskriterien prüfen.
15. Offensichtlich generische Stellen aktiv überarbeiten.
16. Erst dann final ausgeben.

## Qualitätskontrolle

Prüfe vor Abschluss immer:

### Produktqualität

- Wirkt die Oberfläche wie ein reales Produkt statt wie ein Demo-Template?
- Hat die UI eine erkennbare Identität?
- Ist die Hauptaktion klar geführt?
- Sind Informationsdichte und Lesbarkeit ausbalanciert?

### Visuelle Qualität

- Gibt es eine saubere Hierarchie?
- Sind Abstände konsistent?
- Sind Farben rollenbasiert und nachvollziehbar?
- Sind Radius, Border und Shadow systemisch?
- Wirkt die Oberfläche hochwertig, aber nicht dekorativ überladen?

### Systemqualität

- Gibt es wiederverwendbare Komponenten?
- Sind Zustände vollständig abgedeckt?
- Ist das responsive Verhalten konsistent?
- Sind Tokens oder zentrale Stilregeln erkennbar?

### Codequalität

- Ist der Code sauber strukturiert?
- Sind Komponenten sinnvoll geschnitten?
- Ist unnötige Komplexität vermieden?
- Ist die Lösung barrierearm und produktionsnah?

Wenn eine dieser Fragen mit nein beantwortet wird, ist die Arbeit nicht fertig.

## Verbote

Verboten sind:
- generische KI-Optik
- zufällige Farbentscheidungen
- Default-UI ohne Designentscheidung
- Kartenfriedhof ohne Priorisierung
- schlechte Abstände
- unklare visuelle Hierarchie
- überladene Effekte
- rein dekorative Glows
- unmotivierte Gradients
- Desktop-only-Denken
- fehlende Zustände
- Komponenten ohne Systemlogik
- 1:1-Kopien aus Referenzen
- beliebige Icon-Mischung
- rein technische Implementierung ohne Produktlogik

## Definition of Done

Der Task ist erst abgeschlossen, wenn:
1. Produkttyp, Nutzerrolle und Nutzungsszenario klar benannt wurden.
2. Eine visuelle Richtung explizit definiert wurde.
3. Referenzen recherchiert oder eine belastbare Stilannahme dokumentiert wurden.
4. Informationsarchitektur und Komponentenplan festgelegt wurden.
5. Design Tokens oder klare Stilregeln erkennbar sind.
6. Die UI eine klare gestalterische These hat.
7. Alle relevanten Zustände ergänzt wurden.
8. Die Oberfläche responsive und barrierearm ist.
9. Der Code modular und produktionsnah ist.
10. Das Ergebnis nicht wie generische KI-UI wirkt.

## Beispiel-Prompt zur Nutzung des Skills

Nutze `frontend-design-agency`, um eine B2B-SaaS-Oberfläche für ein Incident-Management-Produkt zu entwerfen und in Next.js mit TypeScript, Tailwind und shadcn/ui umzusetzen. Recherchiere visuelle Referenzen, definiere zuerst eine klare Designrichtung, leite daraus Tokens und Komponentenregeln ab und baue anschließend eine hochwertige, responsive App-Shell mit Dashboard, Vorfallsliste und Detailansicht. Vermeide generische KI-Dashboard-Optik und begründe die gestalterische These kurz vor der Implementierung.

```

## Verfügbare Referenzen/Assets
```markdown

--- RESEARCH-WORKFLOW ---
# Research Workflow

Nutze diese Datei, wenn Webzugriff verfügbar ist und du visuelle Referenzen recherchierst.

## Ziel

Nicht nach hübschen Screenshots suchen, sondern nach belastbaren Mustern fuer:
- Informationsarchitektur
- Navigationssysteme
- visuelle Priorisierung
- Komponentenlogik
- Tabellen, Formulare und Detailansichten
- Typografie und Kontrast

## Suchstrategie

Suche entlang des Produkttyps:
- B2B SaaS Dashboard
- Admin Panel
- Analytics Product
- Fintech App
- Health Product
- Collaboration Tool
- CRM
- Settings UI
- Onboarding Flow

Kombiniere mit Begriffen wie:
- design system
- product UI
- case study
- app interface
- table design
- settings design
- data dense UI
- enterprise UX

## Bevorzugte Quellen

Priorisiere:
1. reale Produktseiten und echte Apps
2. etablierte Designsysteme
3. hochwertige Produkt-Showcases
4. Artikel mit nachvollziehbaren UI-Entscheidungen

Reduziere Gewicht fuer:
- reine Konzeptshots
- Dribbble ohne Produktlogik
- UIs mit Effektlast statt Struktur
- Screenshots ohne erkennbare Nutzungssituation

## Auswertung pro Referenz

Erfasse pro Referenz knapp:
- Was ist stark?
- Welche Layoutlogik ist erkennbar?
- Wie wird Prioritaet erzeugt?
- Welche Komponenten loesen echte Produktprobleme?
- Welche Stilmittel sind uebernehmbar?
- Was wird bewusst nicht uebernommen?

## Ableitung

Leite aus den Referenzen genau 5 bis 8 Prinzipien ab.

Die Prinzipien muessen konkret sein, zum Beispiel:
- Primaere Aktionen sitzen immer in der oberen rechten Handlungszone.
- Sekundaere Metadaten stehen in kompakten Inline-Gruppen statt in Einzelkarten.
- Tabellen nutzen ruhige Separatoren statt harter Gitter.
- Detailseiten arbeiten mit einer starken Titelzone und danach mit modularen Inhaltsbloecken.

## Verbot

Nicht tun:
- Screenshot-Stile direkt kopieren
- drei verschiedene Stilwelten mischen
- Referenzen ohne Produktbezug auswaehlen
- Referenzen nur nach "cool" statt nach Nutzen sortieren


--- VISUAL-DIRECTION-CANVAS ---
# Visual Direction Canvas

Fuelle diese Punkte aus, bevor du implementierst.

## 1. Produktkontext

- Produkttyp:
- Zielnutzer:
- Hauptaufgabe:
- Primaere Aktion:
- Informationsdichte:

## 2. Gestalterische These

Beschreibe die UI in einem klaren Satz.

Format:
`Diese Oberfläche wirkt [Charakter], weil [Produktbedarf], und nutzt dafür [wichtigste Stilmittel].`

Beispiel:
`Diese Oberfläche wirkt praezise und kontrolliert, weil Incident-Management schnelle Lageeinschaetzung verlangt, und nutzt dafuer dichte Typografie, ruhige Flaechen und harte Priorisierung.`

## 3. Stilrichtung

- Gesamteindruck:
- Visuelle Spannung:
- Sachlich vs. expressiv:
- Ruhig vs. energisch:
- Premium vs. utilitaristisch:

## 4. Farbkonzept

Definiere Rollen, keine Zufallsfarben.

- Canvas:
- Surface:
- Elevated Surface:
- Primary:
- Secondary:
- Accent:
- Success:
- Warning:
- Danger:
- Border:
- Muted Text:
- Strong Text:

## 5. Typografie

- Schriftcharakter:
- Display-Stil:
- Heading-Hierarchie:
- Body-Stil:
- Label-Stil:
- Tabellen- oder Datenstil:

## 6. Formensprache

- Radius-System:
- Border-Staerke:
- Shadow-Logik:
- Divider-Logik:
- Icon-Stil:

## 7. Raum und Raster

- Content-Breite:
- Grid-System:
- Vertikale Rhythmik:
- Standard-Abstaende:
- Dichte fuer Tabellen oder Listen:

## 8. Motion

- Was darf animiert werden?
- Was bleibt statisch?
- Wie schnell ist die UI?
- Wie wird Fokus oder Zustandswechsel sichtbar?

## 9. Komponentenregeln

Definiere mindestens:
- Button-Familien
- Input-Familien
- Card- oder Panel-Logik
- Tabellen- oder Listen-Logik
- Section-Header
- Empty States
- Status-Indikatoren

## 10. Anti-Generic Check

Beantworte vor dem Start:
- Woran erkennt man diese UI in 5 Sekunden?
- Was unterscheidet sie von einer Standard-shadcn-Demo?
- Welche Stilmittel sind bewusst weggelassen?


--- DESIGN-SYSTEM-RULES ---
# Design System Rules

Nutze diese Regeln beim Umsetzen in Next.js, React, TypeScript und Tailwind CSS.

## 1. Tokens zuerst

Lege zentrale Werte als Tokens oder CSS-Variablen an fuer:
- Farben
- Typografie
- Radius
- Spacing
- Shadow
- Motion

Keine verstreuten Einzelwerte, wenn ein Wert mehrfach vorkommt.

## 2. Farbrollen statt Einzelwerte

Arbeite mit Rollen wie:
- background
- foreground
- surface
- surface-strong
- primary
- primary-foreground
- muted
- muted-foreground
- border
- danger
- success
- warning

Vermeide "hier noch schnell ein anderer Blauton".

## 3. Typo-Skala

Mindestens diese Ebenen sauber definieren:
- Display
- H1
- H2
- H3
- Body
- Small
- Label
- Mono oder Data

Jede Ebene braucht:
- Groesse
- Gewicht
- Laufweite wenn noetig
- Zeilenhoehe

## 4. Spacing-Skala

Nutze eine feste Skala, zum Beispiel:
- 4
- 8
- 12
- 16
- 24
- 32
- 48
- 64

Nutze nicht beliebige Mischwerte ohne Systemgrund.

## 5. Komponentenaufbau

Extrahiere wiederkehrende Muster in Komponenten, wenn mindestens zwei Bedingungen gelten:
- wiederholte Struktur
- wiederholte Interaktionslogik
- wiederholte Stilregeln

Typische Kandidaten:
- Page Header
- KPI Block
- Filter Bar
- Data Table Wrapper
- Empty State
- Detail Section
- Status Badge

## 6. Zustandsmodell

Wichtige Komponenten brauchen mindestens:
- default
- hover
- focus-visible
- active
- disabled
- loading
- error falls relevant
- empty falls relevant

## 7. Responsives Verhalten

Definiere nicht nur Breakpoints, sondern Umbruchslogik:
- Was wird gestapelt?
- Was wird gekuerzt?
- Was wird zu Tabs, Drawer oder Accordion?
- Welche Info bleibt mobil sichtbar?

Mobile darf nicht nur die Desktop-Version in schmal sein.

## 8. Accessibility

Pflicht:
- semantische Struktur
- Tastaturbedienbarkeit
- sichtbare Fokuszustaende
- ausreichender Kontrast
- Labels statt nur Placeholder
- sinnvolle aria-Attribute bei komplexen Controls

## 9. shadcn/ui

shadcn/ui ist Startpunkt, nicht Endzustand.

Pflicht:
- Komponenten sichtbar anpassen
- Defaults nur uebernehmen, wenn sie zur Stilthese passen
- Panels, Buttons, Inputs und Overlays in eine gemeinsame Designsprache bringen

## 10. Code-Qualitaet

Vermeide:
- ueberladene Utility-Ketten ohne Struktur
- Komponenten mit mehreren visuellen Konzepten
- zu fruehe Abstraktion
- zu spaete Abstraktion bei klarer Wiederholung

Ziel:
- klare Komponenten
- nachvollziehbare Props
- produktionsnahe Lesbarkeit


--- QUALITY-GATE ---
# Quality Gate

Diese Pruefung ist vor Abschluss Pflicht.

## 1. Produktlogik

- Ist die primaere Nutzeraufgabe sofort erkennbar?
- Ist die Hauptaktion deutlich priorisiert?
- Sind sekundaere Informationen klar nachrangig?
- Folgt die Struktur dem Anwendungsfall statt einer Template-Logik?

## 2. Visuelle Identitaet

- Hat die UI eine klare gestalterische These?
- Sind Farben, Typografie und Flachen erkennbar aufeinander abgestimmt?
- Wirkt die UI wie ein echtes Produkt?
- Gibt es mindestens ein klar wiedererkennbares Identitaetsmerkmal?

## 3. Anti-Generic Check

Wenn eine dieser Aussagen zutrifft, ueberarbeite den Entwurf:
- Sieht aus wie ein Standard-Admin-Template.
- Koennte aus jeder x-beliebigen AI-Demo stammen.
- Zu viele Karten ohne klare Aufgabe.
- Zu viele Effekte kompensieren fehlende Hierarchie.
- Standard-shadcn ohne erkennbare Anpassung.

## 4. Komponenten und Zustaende

- Sind wiederkehrende Muster konsistent?
- Haben interaktive Elemente saubere Hover- und Focus-States?
- Gibt es Loading, Empty und Error States fuer relevante Bereiche?
- Sind Formulare, Tabellen und Detailmodule systemisch abgestimmt?

## 5. Responsive Qualitaet

- Bleibt die Hauptaufgabe mobil klar?
- Brechen Layout und Abstaende kontrolliert um?
- Sind Header, Filter und Aktionszonen auch auf kleinen Screens nutzbar?
- Geht keine kritische Information durch unkontrolliertes Stacking verloren?

## 6. Code-Check

- Sind Tokens oder zentrale Stilregeln erkennbar?
- Sind Komponenten sinnvoll modularisiert?
- Ist das Markup semantisch?
- Ist die Tailwind-Nutzung lesbar statt chaotisch?

## 7. Abschlussfrage

Wenn diese UI auf der Website eines teuren SaaS-Produkts live waere:
- waere sie glaubwuerdig?
- waere sie unterscheidbar?
- waere sie sauber genug fuer Produktion?

Wenn nicht, ist die Arbeit nicht fertig.


```

## Bewertungskriterien (1-10 für jede Dimension)

### 1. ACCURACY (1-10)
- Deckt der Skill diese spezifische Kategorie vollständig ab?
- Sind die Anweisungen korrekt und vollständig?
- Gibt es Lücken oder Fehler?

### 2. PRACTICAL (1-10)
- Kann ein Frontend-Entwickler die Anweisungen direkt umsetzen?
- Sind die Schritte klar und ausführbar?
- Gibt es konkrete Beispiele?

### 3. EXAM READY (1-10)
- Ist das Wissen praxisrelevant für Agentur-Arbeit?
- Entspricht es Industriestandards?
- Würde es in einem echten Projekt bestehen?

### 4. ASSETS (1-10)
- Gibt es Templates, Checklisten, oder Canvas?
- Sind die Referenzen hilfreich und anwendbar?
- Gibt es ausreichend Unterstützungsmaterial?

### 5. REFERENCES (1-10)
- Gibt es genug Beispiele und Leitfäden?
- Sind die Referenzen hochwertig und relevant?
- Decken sie alle wichtigen Aspekte ab?

## Antwortformat (JSON)
```json
{
  "category": "color_tokens",
  "category_name": "Farbkonzept & Design Tokens",
  "scores": {
    "accuracy": <1-10>,
    "practical": <1-10>,
    "exam_ready": <1-10>,
    "assets": <1-10>,
    "references": <1-10>
  },
  "average_score": <berechneter Durchschnitt>,
  "strengths": ["Stärke 1", "Stärke 2"],
  "weaknesses": ["Schwäche 1", "Schwäche 2"],
  "missing_assets": ["Fehlendes Template", "Fehlende Referenz"],
  "recommendations": ["Verbesserung 1", "Verbesserung 2"]
}
```

## Testfrage nochmals zur Orientierung
"
Baue eine Settings-UI für ein Health-Tech-Produkt. Welche Farbrollen brauche ich
mindestens (Canvas, Surface, Primary, Accent, Danger, Success)? Wie definiere ich
ein systemisches Farbkonzept mit CSS-Variablen statt beliebiger Einzelwerte?
"

Bewerte objektiv und kritisch wie ein erfahrener Frontend-Lead/Design-Director.
