uix-skill

Was macht uix-skill?

Erstelle UI, die gestaltet aussieht, nicht generiert. Lege das Aussehen einmal fest (DESIGN.md), baue daraus und überprüfe das Ergebnis mit Skripten.

Pfade: Alle references/-, data/- und scripts/-Pfade unten sind relativ zu dem Ordner, der diese SKILL.md enthält. Führe Skripte aus dem Benutzerprojektstammverzeichnis aus als node <dieser Ordner>/scripts/<name>.mjs. Skripte benötigen Node 22.

Befehle

Befehl	Aufgabe
/uix init	Projekt einlesen, 3 Fragen stellen, 3 Richtungen anbieten, DESIGN.md schreiben und linten.
/uix build	Seite, Bildschirm oder Komponente aus DESIGN.md bauen, prüfen, korrigieren. Standard.
/uix audit	Prüfungen ausführen und Bericht erstellen. Nichts bearbeiten.
/uix polish	Die wichtigsten Audit-Probleme beheben. Logik, Routen und Textbedeutung erhalten.
/uix motion	Bewegung prüfen oder hinzufügen, nach den 4 Fragen.

Das Verb kann als /uix-skill <verb>, als uix <verb> oder als einfache Aufforderung („Erstelle die Einstellungsseite“, „Prüfe diesen Bildschirm“) eingehen. Ordne eine einfache Aufforderung dem nächstgelegenen Verb zu. Keine klare Übereinstimmung: build.

Harte Regeln

1. DESIGN.md existiert: Lies sie zuerst und baue daraus. Überspringe die Aufnahme und Richtungen. Erfinde niemals Farben, Schriftarten oder Radien, die sie nicht definiert.
2. Melde niemals „fertig“, bevor scripts/rules.mjs und, für Web-Stacks, scripts/check.mjs ausgeführt wurden. Kann eine Prüfung nicht ausgeführt werden (siehe Prüfungen), melde unverified: <Grund>.
3. Maximal 2 Reparaturrunden nach einer Prüfung. Melde dann, was übrig bleibt.
4. Bilder: Projekt-Assets, dann Openverse/Wikimedia mit Quellenangabe, dann CSS/SVG-Kunst. Niemals einen leeren Platzhalter.
5. Nur kostenlose Werkzeuge. Keine kostenpflichtigen APIs, keine Keys.
6. Bearbeite keine Dateien außerhalb des UI-Umfangs der Anfrage. /uix audit bearbeitet nichts.
7. Lade nur die Dateien, die die folgenden Tabellen nennen. Lade eine Stack-Datei, außer bei shadcn und nuxt-ui: Lade diesen Leitfaden plus den Leitfaden des Host-Frameworks.

Ausführungsreihenfolge

1. Projekt einlesen: package.json, Konfiguration, vorhandene Styles, DESIGN.md, public/ oder assets/.
2. Stack erkennen (Tabelle unten). Seinen Leitfaden laden.
3. Aufnahme. Stelle 3 Fragen zusammen in einer Nachricht: Zielgruppe, Aufgabe des Bildschirms, Tonfall. Mobile Stacks: Tonfall fragt auch „ruhige oder lebhafte Bewegung?“; notiere die Antwort als Bewegungsebene in DESIGN.md (references/design-md.md). Überspringe alles, was der Benutzer oder das Projekt bereits beantwortet hat.
4. Biete 3 Richtungen aus references/directions.md an, die sich deutlich in Tonfall, Dichte und Farbtemperatur unterscheiden. Warte auf die Auswahl. Eine Richtung, die der Eigentümer bereits vorab gewählt hat, überspringt das Angebot.
5. Schreibe DESIGN.md (references/design-md.md) und führe den Linter aus. Behebe jeden Lint-Fehler.
6. Wähle eine Struktur aus references/layouts-web.md (Marketing, Inhalt) oder references/layouts-app.md (eingeloggte Bildschirme).
7. Baue den ersten Abschnitt. Echte Texte, echte Bilder, alle Komponentenzustände.
8. Prüfen (siehe unten). Behebe Fehler, dann Warnungen. Maximal 2 Runden.
9. Bericht.

Die Schritte 3 bis 5 gehören zu init. build verwendet eine vorhandene DESIGN.md; wenn keine vorhanden ist, führe zuerst init aus.

Vorhandene Designsysteme gewinnen

• DESIGN.md existiert: Lies sie, führe den Linter aus, baue daraus.
• Keine DESIGN.md, aber das Projekt hat eigene Tokens oder ein Theme (Tailwind-Konfiguration, CSS-Variablen, Theme-Datei): /uix init schreibt eine DESIGN.md (im Projektstammverzeichnis) aus diesen Tokens. Biete keine neuen Richtungen an, es sei denn, der Benutzer wünscht ein neues Aussehen.
• Weder noch: vollständiges init.
• Eigene Tokens bedeutet Farben, Schriftarten oder Abstände, die über die Standard-Standardwerte des Frameworks hinausgehen, in einem Tailwind v4 @theme-Block, einer Tailwind-Konfiguration, CSS-Custom-Properties oder einer Plattform-Theme-Datei. Die Standardwerte --background/--foreground von create-next-app zählen nicht.

Was zu laden ist

Lade nichts anderes, bis es benötigt wird.

Wann	Laden
Jeder Build, Polish oder Audit	references/anti-slop.md, references/components-a11y.md
init, oder jeder Schreibvorgang von DESIGN.md	references/design-md.md
init (Anbieten von Richtungen)	references/directions.md, dann die ausgewählten Zeilen von data/fonts.csv, data/palettes.csv, data/styles.csv
Marketing-, Inhalts-, Katalogseite	references/layouts-web.md
Dashboard, Tabelle, Formular, Einstellungen, Auth	references/layouts-app.md
Jede Bewegung, oder /uix motion	references/motion.md
Mobiler Build, Polish oder Audit	references/mobile-foundations.md, references/mobile-patterns.md
Mobile Bewegung	references/mobile-motion.md anstelle von references/motion.md
Mobil: App sicher ansehen, Expo Go vs. Dev-Build, Tap- und Swipe-Prüfungen	references/mobile-testing.md
init für eine mobile App	data/mobile-styles.csv anstelle von data/styles.csv (die ausgewählten Zeilen)
Jeder Bildplatz	references/images.md
Beispielhafte DESIGN.md-Form	data/examples/ledger.md, field-notes.md oder harbor.md. Nur eine.
Jede Aufgabe	Eine references/stacks/<id>.md. Für shadcn oder nuxt-ui auch den Host-Leitfaden (siehe Stack-Erkennung).

Stack-Erkennung

Erste Übereinstimmung gewinnt, von oben nach unten. Nichts passt: html-tailwind. Übereinstimmung mit exakten Abhängigkeitsnamen (next, nicht next-themes).

Signal	Stack-ID
@nuxt/ui in package.json	nuxt-ui
components.json mit shadcn, oder @/components/ui	shadcn
artisan-Datei oder laravel/framework in composer.json	laravel
nuxt in package.json	nuxtjs
next in package.json	nextjs
@angular/core oder angular.json	angular
astro in package.json oder astro.config.*	astro
svelte oder @sveltejs/kit	svelte
vue in package.json	vue
three in package.json	threejs
react-native oder expo in package.json	react-native
react in package.json	react
pubspec.yaml	flutter
build.gradle(.kts) mit Compose (androidx.compose)	jetpack-compose
*.xcodeproj oder Package.swift mit SwiftUI	swiftui
*.csproj mit Avalonia	avalonia
*.csproj mit Uno. oder Uno.WinUI	uno
*.csproj mit Microsoft.WindowsAppSDK	winui
*.csproj mit <UseWPF>true</UseWPF>	wpf
*.csproj mit TargetPlatformIdentifier UAP oder Microsoft.NETCore.UniversalWindowsPlatform	uwp
pom.xml oder build.gradle mit javafx	javafx
Keine der obigen	html-tailwind

Web-IDs: angular, astro, html-tailwind, laravel, nextjs, nuxt-ui, nuxtjs, react, shadcn, svelte, threejs, vue. Der Rest sind native. „Mobiler Stack“ bedeutet react-native, flutter, swiftui oder jetpack-compose. Deren Anfragen laden auch die mobilen Zeilen von „Was zu laden ist“. Der spezifischere Stack gewinnt: nextjs über react, react-native über react, laravel über sein JS-Frontend. Komponentenschicht-Stacks laden zwei Leitfäden: shadcn plus den Host-Leitfaden (nextjs, react, astro, laravel, ... erkannt durch diese Tabelle mit übersprungener shadcn-Zeile), und nuxt-ui plus nuxtjs. Jedes andere Projekt lädt einen.

Prüfungen

Aus dem Benutzerprojektstammverzeichnis. Ersetze <skill> durch den Ordner, der diese SKILL.md enthält.

node <skill>/scripts/rules.mjs [--design DESIGN.md] <pfad...>
node <skill>/scripts/check.mjs <url|datei> [--widths 375,768,1280] [--out .uix/shots] [--themes attr=v1,v2]
node <skill>/scripts/images.mjs "<abfrage>" [--count 6]

• Alle drei geben JSON aus. rules.mjs gibt {findings, skipped} aus: minifizierte, über 1 MB große oder nicht lesbare Dateien landen in skipped mit einem Grund und sind kein Fehler. check.mjs gibt {shots, findings, notes} aus; lies notes (z. B. ein zu früh abgefragtes Lade-Timeout oder ein fehlgeschlagener Screenshot). Exit 0: sauber. Exit 1: Fehler (Findings) (rules.mjs, check.mjs). Exit 2: Verwendungs- oder Umgebungsproblem (alle drei). images.mjs beendet sich nur mit 0 oder 2.
• Exit 2 ist niemals ein sauberes Ergebnis und zählt nicht als Reparaturrunde. Wenn check.mjs die Seite nicht erreichen kann und das Projekt ein offensichtliches Dev-Skript hat (npm run dev usw.), starte es einmal im Hintergrund und versuche es erneut. Andernfalls frage den Benutzer. Nenne, was fehlt (Chrome, Node 22, ein nicht laufender Server).
• Wenn die Prüfung immer noch nicht ausgeführt werden kann, sagt der Bericht unverified: <Grund>.
• Web-Stacks: Führe rules.mjs auf dem Quellcode aus, dann check.mjs auf der Dev-Server-URL oder der Build-Datei. Breiten sind 375, 768 und 1280. Screenshots landen in .uix/shots: <w>.png ist die gesamte Seite, und <w>-<n>.png sind Kacheln von maximal 1600 px. Betrachte die Kacheln, nicht das gesamte Bild; dieses wird auf unlesbare Größe verkleinert. check.mjs scrollt die Seite zuerst, damit Inhalte, die beim Scrollen erscheinen, sichtbar sind.
• Wenn das Projekt mehrere Themes definiert ([data-theme], [data-skin], .dark), übergib sie mit --themes, z. B. --themes data-skin=oatmeal,rose oder --themes class=dark. Jedes Theme wird bei der letzten Breite geprüft; seine Findings enthalten theme.
• Kontrast-Fundstücke werden pro Farbpaar gruppiert (count, sample, selectors). Korrigiere das Token, nicht jedes Element.
• React Native (Expo): Führe rules.mjs aus, dann node <skill>/scripts/check-mobile.mjs --app exp://127.0.0.1:<port> gegen einen laufenden Metro-Server; füge --platform android für Android-Emulatoren hinzu (Flags und die Routen-Datei befinden sich im Stack-Leitfaden). Es gibt {shots, findings, notes} aus und beendet sich mit 0, 1 oder 2 wie check.mjs. Ein Hinweis, der mit maestro missing: beginnt, bedeutet, dass Hierarchie und Fluss nicht ausgeführt wurden; melde es als unverified: <Grund>, nicht als erfolgreichen Lauf. Aufnahmen landen in .uix/mobile-shots. Ein Fundstück route-not-navigated ist ein Fehler und niemals ein sauberes Ergebnis: Der Screenshot zeigt einen anderen Bildschirm. Reparaturschleife: Überprüfe erneut mit --only <routen> und einem --devices-Eintrag, nicht der gesamten Matrix.
• Andere mobile Stacks: Führe rules.mjs aus. Native iOS-Apps (SwiftUI) verwenden dann check-mobile.mjs --native (Flags im Stack-Leitfaden); bei einem Audit übergib --out "$(mktemp -d)". Andere verwenden das manuelle Screenshot-Rezept in der Stack-Datei unter „How to check“ (hell, dunkel, xxxl-Text). Kein Simulator verfügbar: unverified: <Grund>. Die 2-Runden-Begrenzung gilt.
• Andere native Stacks: Führe rules.mjs aus, dann die manuelle Checkliste in der Stack-Datei unter „How to check“. Es gibt keine Browser-Prüfung.
• Behebe error-Fundstücke vor warn. Eine Warnung, die du behältst, benötigt einen einzeiligen Grund.
• Reparaturschleife: Prüfen, korrigieren, erneut prüfen. Maximal 2 Runden. Dann anhalten und berichten.
• Regel-IDs und ihre Korrekturen befinden sich in references/anti-slop.md. Es listet auch Beurteilungsregeln auf, die kein Skript abfängt; überprüfe diese selbst.

Befehlsverträge

init

1. Projekt einlesen, Stack erkennen, seinen Leitfaden laden.
2. Vorhandene Tokens oder DESIGN.md: Siehe „Vorhandene Designsysteme gewinnen“.
3. Andernfalls die 3 Fragen stellen, 3 klar unterschiedliche Richtungen anbieten, warten. Jeder Stack: Erkenne die Inhaltssprache (lang, i18n-Dateien, Text) und wähle nur data/fonts.csv-Zeilen aus, deren scripts-Spalte sie abdeckt.
4. DESIGN.md schreiben. Linten: npx --yes @google/[email protected] lint DESIGN.md. Fehler beheben.
5. Berichte die gewählte Richtung, die geschriebenen Dateien und das Lint-Ergebnis.

build

1. DESIGN.md, den Stack-Leitfaden und die Layout-Datei lesen.
2. Eine Struktur auswählen. Sage in einer Zeile, welche und warum.
3. Den ersten Abschnitt vollständig bauen. Dann den Rest.
4. Die Prüfungen ausführen. In maximal 2 Runden korrigieren.
5. Berichten.

audit

1. Stack erkennen und seinen Leitfaden laden.
2. Die Prüfungen ausführen. Die Beurteilungsregeln überprüfen. Übergib --out "$(mktemp -d)" an check.mjs und auch an check-mobile.mjs, damit Audit nichts in das Projekt schreibt.
3. Eine Tabelle ausgeben. Nichts bearbeiten.

Vorher	Nachher	Grund
was jetzt da ist	was sein sollte	die Regel-ID oder Begründung

polish

1. Stack erkennen und seinen Leitfaden laden.
2. Zuerst ein Audit ausführen.
3. Die wichtigsten Probleme beheben, zuerst Fehler. Logik, Routen und Textbedeutung nicht ändern.
4. Die Prüfungen erneut ausführen. Maximal 2 Runden. Berichten.

motion

1. Lade references/motion.md (Mobile Stacks: references/mobile-motion.md). Beantworte seine 4 Fragen schriftlich für jede Animation: benötigt, was sie kommuniziert, welche Beschleunigung, wie lange.
2. Entferne jede Animation ohne klare Antwort. Füge prefers-reduced-motion-Behandlung hinzu (der Stack-Leitfaden nennt das native Äquivalent).
3. Gib eine Tabelle Vorher / Nachher / Grund aus. Wende die Änderung nur an, wenn der Benutzer darum gebeten hat, Bewegung hinzuzufügen oder zu korrigieren, nicht zur Überprüfung.

Bericht

Beende jede Ausführung mit:

• Was sich geändert hat (Dateien).
• Fundstücke, die verbleiben, jeweils mit Regel-ID und Grund.
• Screenshot- und Kachelpfade in .uix/shots (Web), Aufnahmepfade in .uix/mobile-shots (Mobil) oder die durchgeführten manuellen Prüfungen (andere native).
• Hinzugefügte Bildquellenangaben.