uxskill
Star on GitHub
Language
English 简体中文 繁體中文 日本語 한국어 हिन्दी Bahasa Indonesia Tiếng Việt ไทย العربية Español Français Deutsch Português Русский Türkçe Italiano
Release · v3.0.0 · 2026-05-28

# ux-skill v3.0 · wir haben The Brain veröffentlicht. Brand-Specs sind jetzt Trainingsdaten, keine Templates.

v2 hat aus dem Katalog ausgewählt. v3 destilliert aus ihm. Dieselben 160 Brand-Specs, eine vollkommen andere Rolle. Der bisherige Recommender hat 1.182 Einträge bewertet und das ähnlichste Match zurückgegeben. Der Synthesizer liest diese Einträge nun als Vokabular und kompiliert aus einem Brief eine neue Designsprache. Jeder Aufruf liefert ein System, das es vor dem Aufruf nicht gegeben hat.

Vom ux-skill Team · 12 Min. Lesezeit · MIT-lizenzierte Open Source

EN JA ZH-CN AR ES DE FR
Brand-Specs sind Trainingsdaten,
keine Templates.

## Die Verschiebung in einem Absatz

v2 war ein Recommender. Du gabst einen Brief hinein und bekamst das nächstgelegene Match aus einem kuratierten Katalog, 84 Styles, 176 Paletten, 160 Brand-Specs, 70 Type-Pairs. Die Ausgabe war immer eine Zeile aus der Datenbank. v3 behält den gesamten Katalog, kehrt aber dessen Zweck um: Diese 1.182 Einträge sind jetzt das Vokabular, aus dem die Engine destilliert. Ein Brief zieht keine Zeile mehr heraus, er wird in sieben Achsenwerte kompiliert, und diese Werte synthetisieren frische Tokens. Der Katalog bringt der Engine bei, wie etwas Luftig-Korporatives aussieht; die Engine erzeugt ein neues luftig-korporatives System, das es so noch nie gegeben hat. Dieselben Daten. Eine völlig andere Rolle.

## Was in v2 kaputt war und v3 behebt

Drei echte Bugs und ein Designloch. Die Bugs waren nicht laut, sie waren die leise Sorte, bei der die Engine weiterhin plausible Ergebnisse zurückgegeben hat und wir sie weiterhin ausgeliefert haben. Wir haben sie erst entdeckt, als wir uns hingesetzt haben, um die Upgrade-Spezifikation zu schreiben, und ein externes Review uns gezwungen hat, ehrlich hinzuschauen.

### 1. Pseudo-Determinismus durch Tie-Breaks in Dateisystem-Reihenfolge

Mehrere Sortierungen innerhalb der Recommender-Pipeline haben Kandidaten nach Ähnlichkeit bewertet und Gleichstände mit der Reihenfolge aufgelöst, die Pythons `os.listdir` zurückgab. Auf macOS war das alphabetisch. Auf Linux war es die Einfügereihenfolge im Dateisystem-Journal. Zwischen einem frischen Clone und einem alten Clone konnte der Tie-Break kippen. Wir haben uns selbst erzählt, die Engine sei deterministisch. Sie war deterministisch bis zum Gleichstand. Nach dem Gleichstand war sie das, woran sich das Betriebssystem zufällig erinnerte.

v3 verstärkt jede Sortierung mit einem expliziten alphabetischen Tie-Break über `brand_id`. Gleicher Brief, gleiche Achsen, gleiche Ausgabe, über Maschinen, Dateisysteme und Python-Versionen hinweg. Es gibt einen Test, der den Synthesizer 200-mal in drei Temp-Verzeichnissen laufen lässt und byte-identische Ausgabe behauptet.

### 2. Achsenkonflikte, die per Zufall aufgelöst wurden

Wenn ein Brief in v2 zwei Tags hatte, die in entgegengesetzte Richtungen zogen, etwa dense und corporate, gewichtete der Scorer des Recommenders einen davon stärker durch irgendeinen versteckten Koeffizienten, und das Ergebnis lehnte sich an den Tag an, den der Koeffizient gerade bevorzugte. Es gab keine dokumentierte Regel. Wir konnten das Ergebnis hinterher erklären. Wir konnten es vorher nicht vorhersagen.

v3 hebt das auf eine Achsen-Interaktionsmatrix. Jeder dokumentierte Konflikt hat eine explizite Auflösung und eine Begründung. Dichte und Formalität streiten um den Spacing-Wert, Dichte gewinnt für dichte Briefs (Bloomberg-Schule), Formalität gewinnt für luftige Briefs (Luxury). Die Matrix ist getestet. Sie ist lesbar. Sie ist eingecheckt.

### 3. Der Evaluator hat die Hausaufgaben des Synthesizers benotet

Das war das peinlichste, und wir haben es bemerkt, weil ChatGPT es im externen Review der v2.1-Spezifikation markiert hat, was es als self-referential drift bezeichnete. Der Flow sah sauber aus: Der Synthesizer kompiliert ein System aus dem Brief, dann bewertet `score_tone_match`, wie gut das System zum Ton des Briefs passt. Das Problem war, dass `score_tone_match` Achsenwerte aus dem Brief mit derselben Logik wie der Synthesizer ableitete und dann die Achsen des Synthesizers mit seinen eigenen abgeleiteten Achsen verglich. Beide Seiten des Vergleichs liefen durch dieselbe Funktion. Natürlich war die Note gut. Der Synthesizer hat sich mit seiner eigenen Rubrik selbst benotet.

v3 entkoppelt das. `score_tone_match` vergleicht die Synthesizer-Ausgabe nun mit den rohen Tone-Tags des Briefs, den Strings `warm`, `bold`, `minimal` usw., über ein unabhängiges Mapping, das die Achsenlogik des Synthesizers nicht berührt. Die beiden Pfade können nicht mehr voneinander abschreiben. Diese Beobachtung verdanken wir dem externen Review, und wir halten das hier ausdrücklich fest.

### 4. Das Decisions-Log war write-only, nie konsumiert

v2 hat nach jeder Empfehlung einen Eintrag in `.ux/decisions.jsonl` geschrieben, aber nichts hat ihn zurückgelesen. Es war eine Log-Datei für unser eigenes Debugging, kein Feedback-Signal. Der Recommender lief beim Aufruf 1 und beim Aufruf 1.000 identisch. Es gab kein Lernen. Das Repo hatte ein Gedächtnis, und die Engine ignorierte es.

v3 schließt diesen Kreis. Das Ledger hat ein gesperrtes Schema (`_v: 1`), der Recommender re-rankt Kandidaten anhand vergangener Erfolge im selben `(industry, ui_type)`-Bucket, und nur Entscheidungen, die gut bewertet wurden und die der Benutzer tatsächlich ausgeliefert hat, zählen für das Re-Rank. Das Gehirn hat jetzt Augen auf die eigene Geschichte. Abschnitt 6 ist der vollständige Durchgang.

## Der 7-Achsen-Synthesizer

Im Zentrum von v3 steht eine deterministische Funktion, die einen Brief auf sieben numerische Achsen mappt, und diese sieben Achsen auf ein vollständiges Designsystem. Die Achsen sind keine Magie: Jede ist ein normalisierter Skalar mit einem dokumentierten Wertebereich, und jede zeigt auf ein bestimmtes Token-Bündel. Der Sinn, über Achsen zu arbeiten (statt eine Zeile aus dem Katalog zu wählen), ist, dass jede Kombination erreichbar wird, auch Kombinationen, die keine reale Marke im Katalog verwendet. Der Katalog definiert die Form des Raums; der Synthesizer kann überall darin landen.

Achse | Was sie misst | Mappt auf
--- | --- | ---
warmth | Farbtemperatur der Palette: kühles Charcoal bis warmes Sienna | Palette-Farbtonfamilie, Sättigungskurve des Akzents
contrast | Visuelle Lautstärke: quiet/balanced/loud | Type-Scale-Ratio (1.200 / 1.250 / 1.333), Schattentiefe, Akzent-Intensität
density | Informationsdichte pro Viewport: airy bis dense | Spacing-Scale-Basis (4/8/12/16px), Line-Height-Multiplikatoren
geometry | Kanten-Persönlichkeit: sharp/balanced/soft | Radius-Skala (2/8/18px), Eck-Topologie, Border-Stärken
formality | Tonregister: playful/balanced/corporate | Typografie-Gewichtskurven, Tracking, Caption-zu-Hero-Spreizung
motion | Animations-Budget: restrained/balanced/cinematic | Dauer-Rampen (120/240/420ms), Easing-Familie, Scroll-Verhalten
type_personality | Typografische Stimme: humanist/neutral/geometric/expressive | Display-Face-Familie, Gewichtsleiter, Kursiv-Strategie

Der Python-Einstiegspunkt ist klein genug für ein einziges Beispiel. Du übergibst einen Brief und bekommst ein synthetisiertes System zurück, mit Achsenwerten, gewählter Palette, Type-Konfiguration, Spacing-Skala, Radius-Skala und Motion-Presets.

    # vom Brief zum System in einem Aufruf
    from engine.synthesizer import synthesize

    brief = Brief(
      industry="fintech-payments",
      tone=["bold", "serious"],
      audience=["merchants", "developers"],
    )

    sys = synthesize(brief)
    # sys.mode == "pure_synthesis"
    # sys.axes == {warmth: 0.32, contrast: 0.72, density: 0.58, ...}
    # sys.palette, sys.type, sys.spacing, sys.radius, sys.motion

Gleicher Brief rein, gleiche Achsen raus, gleiche Tokens raus. Immer. Der Synthesizer hat keinen Random-Seed, weil es keine Zufälligkeit zu seeden gibt.

## Drei Modi, eine Entscheidungslogik

Der Synthesizer dispatcht je nach Briefinhalt automatisch zwischen drei Modi. Für die meisten Anwendungen gibt es kein Flag, um den Modus von Hand zu wählen, die Form des Briefs entscheidet. Die Logik ist absichtlich einfach: Das Vorhandensein einer Referenzmarke und ein Strict-Flag bestimmen den Pfad.

strict_brand · am schnellsten

#### 100% die genannte Marke

`reference_brands=[stripe]` mit `strict=True` liefert die Stripe-Spezifikation wortgetreu. Keine Interpretation, kein Mischen, keine Synthese. Nützlich, wenn die Marke existiert, die Spezifikation autoritativ ist und der Brief nur die Tokens will. Das ist der Pfad, wenn du eine Figma-Datei und ein dokumentiertes System hast und Code brauchst, der nicht improvisiert.

brand_anchor · 70 / 30

#### An die Marke verankert, per Achsen auf den Brief angepasst

`reference_brands=[stripe]` ohne `strict=True` liefert 70% Stripe-Tokens, fusioniert mit 30% achsenabgeleiteten Deltas aus vier Geschwister-Marken, die per Achsen-Nähe ausgewählt wurden. Die Ausgabe bleibt unmissverständlich Stripe, beugt sich aber zum Ton des Briefs, ein verspielteres Stripe für ein Consumer-Feature, ein formaleres Stripe für ein Enterprise-Dashboard. Die Anker-Marke überlebt jeden Konflikt.

pure_synthesis · Unendlichkeitsraum

#### Keine Marke genannt, bei jedem Aufruf eine neue Sprache

Keine `reference_brands` im Brief. Der Synthesizer bewertet die sieben Achsen aus dem Brief, findet die acht nächsten Exemplare im Katalog per Achsen-Distanz, destilliert deren gemeinsame Struktur und gibt ein frisches Bündel aus Palette, Type, Spacing, Radius und Motion aus. Unterschiedliche Briefs landen in unterschiedlichen Regionen desselben Raums; jede Ausgabe ist intern konsistent und als sie selbst erkennbar.

Auf der CLI sehen die drei Pfade so aus:

    # strict: 100% diese Marke
    $ uxskill synthesize --brand stripe --strict

    # anchor: 70/30
    $ uxskill synthesize --brand stripe

    # pure synthesis: ohne Marke
    $ uxskill synthesize --industry fintech-payments --tone bold

Ein Synthesizer, eine Entscheidungslogik, drei Ausgabepersönlichkeiten. Der Benutzer wechselt keine Implementierung, der Brief routet sich selbst.

## Die Achsen-Interaktionsmatrix

Achsen ziehen an denselben Tokens. Dichte will enges Spacing; Formalität will großzügiges Spacing für ein Luxus-Register. Geometrie will scharfe Ecken für ein redaktionelles Gefühl; Formalität will sanfte Ecken für ein Finanz-Dashboard. In v2 wurden diese Konflikte über den im Scorer gerade größeren Koeffizienten aufgelöst. In v3 hat jeder dokumentierte Konflikt ein erklärtes Ergebnis und eine Designschule, auf die er zeigt, benannt, sodass du es lesen und widersprechen kannst.

Vier repräsentative Fälle, alle als Test-Fixtures eingecheckt:

dense + corporate
Spacing-Scale-Basis: 4px

Dichte gewinnt. Die Bloomberg-Antwort. Informationsdichte ist die höchste Tugend, wenn der Brief dichte Daten-Dashboards in einem korporativen Register verlangt, Formalität verbeugt sich vor der Lesbarkeit unter Dichte.

airy + corporate
Spacing-Scale-Basis: 12px

Formalität gewinnt. Die Luxury-Finance-Antwort. Airy + corporate ist der Brief für Premium-Banking, Private Wealth, Executive-Dashboards, der Raum um jedes Element ist die Botschaft von Ernsthaftigkeit.

sharp + corporate
Radius-Skala: 2px

Geometrie gewinnt. Die NYT-Antwort. Sharp + corporate ist der redaktionelle Brief, rechte Winkel und 2px-Mikro-Radien lesen sich als institutionell, durchdacht, im Broadsheet-Format.

soft + playful
Radius-Skala: 18px

Beide Achsen ziehen in dieselbe Richtung. Die Glossier-Antwort. Weiche Geometrie und ein verspieltes Register kollabieren auf großzügige Rundungen, 18px ist die Schwelle, an der Rechtecke beginnen, wie Kieselsteine zu wirken.

Warum das wichtig ist: In v2 konnte derselbe Brief je nachdem, welcher Koeffizient diesen Monat den Scorer gewann, auf 4px oder 12px landen. In v3 ist `dense + corporate` immer 4px. `airy + corporate` ist immer 12px. Die Regeln sind lesbar, testbar und diskutierbar. Wenn du mit einer Auflösung nicht einverstanden bist, kannst du gegen die Matrix ein Issue eröffnen, und die Diskussion geht um Geschmack, nicht um eine versteckte Konstante.

## Das Gehirn lernt

Das ist der Teil von v3, der für das Projekt wirklich neu ist: Die Engine lernt jetzt aus deinen lokalen Entscheidungen. Der Mechanismus ist klein, deterministisch und komplett offline. Keine Telemetrie, kein Account, kein Cloud-Sync. Deine Installation lernt aus deiner Installation. Unterschiedliche Repos bauen unterschiedliche Gehirne.

### Das Ledger

Jeder Aufruf von `/ux-recommend` und `/ux-synthesize` schreibt eine einzelne Zeile in `.ux/decisions.jsonl`. Das Schema ist auf `_v: 1` festgenagelt:

    {
      "_v": 1,
      "ts": "2026-05-28T14:22:09Z",
      "frame": { "industry": "fintech-payments", "ui_type": "dashboard", ... },
      "system": { "style_id": "editorial-calm-dark", "palette_id": "charcoal-amber", ... },
      "axes": { "warmth": 0.31, "contrast": 0.72, ... },
      "lint_score": 88,
      "user_accepted": true
    }

### Das Re-Rank

Beim nächsten Aufruf gruppiert der Recommender die vergangenen Einträge nach `(industry, ui_type)`. Jeder Kandidat erhält einen +5-Bump, wenn er einem Vorgänger im selben Bucket entspricht. Nur Vorgänger mit `lint_score >= 80` UND `user_accepted = true` zählen, aus abgelehnten Ergebnissen lernen wir nicht. Der Bucket braucht mindestens drei qualifizierende Vorgänger, bevor überhaupt ein Re-Rank greift. Darunter läuft die Engine im Cold-Start und verhält sich identisch zu einer frischen Installation.

### Die Garantien

Die Garantien, die wir dazu geben, sind eng und es lohnt, sie laut auszusprechen. Determinismus bleibt erhalten. Gleicher Brief plus gleiches Ledger erzeugen immer dieselbe Ausgabe. Der +5-Bump wird vor jedem Tie-Break angewendet, und die Regel der alphabetischen Reihenfolge nach `brand_id` gewinnt die Gleichstände darunter weiterhin. Cold-Start ist sicher. Ein neues Repo verhält sich wie jedes andere neue Repo. Das Lernen ist lokal. Deine Entscheidungen verlassen deine Maschine nicht.

Du kannst jederzeit prüfen, was deine Installation gelernt hat:

    $ uxskill stats --html
    [OK] Wrote .ux/stats.html
    [OK] Open in browser to see your install's learned priors

Das HTML-Dashboard zeigt die Anzahl der Entscheidungen pro Bucket, den durchschnittlichen Lint-Score, die häufigsten Paletten, die Achsen-Verteilungen. Das ist der sichtbare Beweis des Selbstlernens, du siehst das Geschmacksprofil deiner Installation über die Zeit dichter werden, während du weiter ausspielst. Nichts davon liegt auf einem Server. Es liegt in deinem Repo, in Klartext-JSONL plus einer generierten HTML-Ansicht.

## /ux-evolve Auto-Loop

Das neue Kommando in v3 ist `/ux-evolve`. Bisher war der Polish-Loop manuell: Lint laufen lassen, Findings lesen, beheben, neu linten, wiederholen. Evolve schließt diesen Loop. Du übergibst ein Artefakt und einen Zielscore; das System läuft Lint, wendet sechs idempotente Polish-Pässe an, lintet erneut und stoppt entweder beim Ziel, auf einem Plateau oder beim Cap von fünf Runden.

Die Form einer Runde:

1. Lint: 145 deterministische Regex-Regeln über A11y, Inhalt, Qualität, Typografie. Liefert einen Score von 0 bis 100 und eine Findings-Liste.
2. Polish: sechs Pässe, die zuerst die Findings höchster Severity beheben. Idempotent: Einen Pass auf bereits polierten Ausgaben erneut anzuwenden ist ein No-Op.
3. Re-Lint: bewertet das polierte Artefakt.
4. Entscheiden: ist der neue Score ≥ 90, stopp. Ist das Delta zur Vorrunde unter 5 (Plateau), stopp. Sind wir in Runde 5, stopp. Sonst weiterloopen.

Das Quality-Gate steht fest bei 65. Liegt der finale Score unter 65, weigert sich die Engine, das Artefakt zu liefern, sofern nicht `--force` übergeben wird. Die Begründung: Eine 65-oder-darunter-Ausgabe ist erkennbarer AI-Slop, und wir lassen unsere eigene Engine nicht still Slop ausstoßen. Der Benutzer kann das Gate übersteuern, aber das Override ist explizit und taucht im Decisions-Ledger auf.

Ein konkreter Lauf: Ein Fintech-Dashboard-Scaffold lag im ersten Lint bei 72, meist fehlende Focus-States, ein paar kontrastschwache Labels, ein Finding zu Inter in Display-Größe. Runde 1 polierte die Focus-States auf 81. Runde 2 korrigierte den Kontrast auf 86. Runde 3 tauschte Inter gegen die im Brief tatsächlich vorgesehene Display-Schrift und rebalancierte die Caption-Größe, 91, Ziel erreicht, Loop beendet. Drei Runden, keine Ablehnungen, ausgeliefert.

## Was wir nicht gebaut haben (und warum)

Die maximalistische v2.1-Spezifikation schlug einige Dinge vor, die es nicht in v3 geschafft haben. Zu sagen, welche und warum, ist der einzige ehrliche Weg, über Scope zu reden.

### Kein LLM im Loop

Der maximalistische Vorschlag enthielt eine LLM-beurteilte, subjektive Ästhetik-Achse, "frag ein Modell, ob sich das redaktionell anfühlt". Wir haben das aus Prinzip abgelehnt. Der gesamte Sinn der Engine ist Determinismus: gleicher Brief, gleiche Ausgabe, morgen früh keine Überraschungen. Ein LLM im Synthesizer würde jeden Aufruf unreproduzierbar machen. v3 ruft null LLMs. Der Synthesizer ist reines Python über JSON; der Linter ist Regex; der Evaluator ist regelbasiert.

### Keine genetische Mutation mit mehreren Kandidaten

Der Vorschlag hatte außerdem einen Schritt mit genetischem Algorithmus, N Kandidaten pro Aufruf ausgeben, mutieren, bewerten, den fittesten zurückgeben. Wir haben es in einem Branch versucht. Die Ausgabe wurde schlechter, nicht besser, weil Mutation Rauschen einführte, das der Polish-Loop danach wieder rausnehmen musste. v3 liefert Single-Artifact-Synthese plus Polish-Loop. Ein Kandidat. Sechs idempotente Pässe. Bessere Ergebnisse, kleinere Codeoberfläche.

### Keine umbenannten Kommandos

Der Vorschlag benannte `/ux-recommend` in `/generate:ui` um und `/ux-polish` in `/mutate:ui`. Wir haben alle 22 existierenden Kommandos unter ihren existierenden Namen behalten und `/ux-evolve` als 23. hinzugefügt. Wir wollten nicht, dass ein v2-zu-v3-Update jemandem das Muskelgedächtnis oder die Shell-Aliasse zerschießt.

### Kein "Katalog für unendlichen Raum verbrennen"

Die maximalistischste Version des Vorschlags meinte, der Katalog sei eine Last, der Synthesizer könne den gesamten Design-Raum aus eigener Kraft erreichen, also sollten die 1.182 Einträge weg. Wir haben jeden Eintrag behalten. Der Katalog ist, was dem Synthesizer die Form des Raums beibringt, ohne Exemplare haben die Achsen keine Anker, und die Ausgabe driftet weg. v3 liest den Katalog als Vokabular; v3 braucht das Vokabular.

Das sind Geschmacksentscheidungen. Menschen mit anderen Prioritäten werden widersprechen, und das ist in Ordnung. Wir schulden es dem Projekt zu sagen, was wir nicht getan haben und warum, aktenkundig.

## Die Zahlen bei v3

23
Kommandos
18
MCP-Tools
1.182
Einträge
145
Anti-patterns
160
Brand-Specs
17
IDEs
17
Sprachen
223
Tests OK

Die 22 Slash-Kommandos behalten ihre Namen, plus `/ux-evolve` als 23. Die 15 MCP-Tools bleiben, plus drei neue, `ux_synthesize`, `ux_decisions_query`, `ux_decisions_stats`, für Agenten, die den Synthesizer steuern oder abfragen wollen, was das Gehirn gelernt hat. Katalog und Linter sind unberührt. Der 17-IDE-Installer ist unberührt. Die 17 lokalisierten Homepages und READMEs sind unverändert. v3 ist an der Oberfläche additiv und im Kern neu geschrieben.

> v2 war ein Recommender, der aus einem Katalog ausgewählt hat. v3 ist ein Compiler, der aus einem destilliert. Dieselben Daten machen den entgegengesetzten Job.

## Installation in 60 Sekunden

v3 wird über dieselben drei Wege ausgeliefert wie v2, pip, npm und die IDE-Plugin-Marketplaces. Der `init`-Schritt erkennt deine IDE automatisch und schreibt die richtige Config-Datei an die richtige Stelle. Der `synthesize`-Schritt nimmt einen Brief oder ein Paar aus Industry + Tone und liefert ein vollständiges Designsystem nach `.ux/last-system.json` im aktuellen Repo.

    $ pip install uxskill
    $ uxskill init                     # erkennt deine IDE automatisch
    $ uxskill synthesize --industry fintech-payments --tone bold

    [OK] Mode: pure_synthesis
    [OK] Axes: warmth=0.31, contrast=0.74, density=0.58, geometry=0.42, ...
    [OK] Wrote .ux/last-system.json (palette, type, spacing, radius, motion)
    [OK] Wrote .ux/decisions.jsonl (1 entry, schema _v: 1)

Derselbe Installationspfad in jeder unterstützten IDE: Claude Code, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Codex, Kiro, Cline, Continue, Aider, Zed, JetBrains AI, Pieces, Tabby, Tabnine, CodeWhisperer, Roo Cline. Der MCP-Stdio-Server ist die einzige Wahrheitsquelle für sie alle.

Ehrlicher Scope

#### v3 ist ein Fundament, kein fertiges Ziel.

Der 7-Achsen-Synthesizer ist die Arbeit, für die wir Belege veröffentlicht haben. Achsen 8 und 9 (`saturation_strategy`, `surface_depth`) sind skizziert, aber nicht ausgeliefert, sie würden die Dark/Light-Trennung und die Gradient-Strategie vertiefen. Das Decisions-Ledger wird heute nur vom Recommender-Re-Rank konsumiert; wir erwarten, dass Evaluator und Lint-Scorer es in v3.1 zu lesen anfangen. Der von uns abgelehnte maximalistische v2.1-Vorschlag ist nicht verschwunden, einige Ideen werden später landen, wenn wir beweisen können, dass sie helfen.

Wenn du einen Brief findest, der unbefriedigende Ausgaben produziert, oder eine Konfliktauflösung in der Matrix, die deinem Geschmack widerspricht, eröffne ein Issue. Die Matrix ist eingecheckt, die Tests sind eingecheckt, das Gehirn liegt in deinem Repo. Die Diskussionen finden jetzt auf einem Substrat statt, das du lesen kannst.

## Was sich für dich ändert

Wenn du auf v2 warst: Nichts geht kaputt. Die 22 Kommandos, die du bereits benutzt, verhalten sich gleich. Der Linter läuft mit derselben Geschwindigkeit. Der MCP-Server exponiert 15 der 18 Tools unter ihren alten Namen, plus drei neue. Wenn du upgradest und nie `/ux-synthesize` oder `/ux-evolve` aufrufst, bewegt sich dein täglicher Workflow überhaupt nicht.

Wenn du darauf gewartet hast, dass die Engine generiert statt empfiehlt: Das ist v3. Der Synthesizer ist das neue Zentrum; `/ux-recommend` funktioniert weiter und re-rankt jetzt aus deinem Ledger; `/ux-evolve` schließt den Polish-Loop. Brand-Specs sind jetzt Trainingsdaten, keine Templates. Dieselben 1.182 Einträge erledigen einen völlig anderen Job.

Wir haben v3 The Brain genannt, weil das das ist, was gebaut wurde, ein eingeschränkter, generativer Design-Compiler mit geschlossenem Feedback-Kreis. Komplett offline. Ruft null LLMs. Gleicher Brief, gleiche Achsen, gleiche Ausgabe. Unterschiedliche Briefs, unterschiedliche Regionen, unendliche Ausgaben. Deine Installation lernt aus deinem Repo. Unterschiedliche Repos bauen unterschiedliche Gehirne. Das Ganze ist MIT, sub-300ms auf einer normalen Maschine, pip-installierbar.

Lass es auf einem Brief laufen, der dir wichtig ist. Schau, was es zurückgibt. Eröffne ein Issue, wenn die Ausgabe deinem Geschmack widerspricht, der Konflikt wandert in die Matrix, die Regel bekommt einen Namen, und die nächste Installation verhält sich besser. So kompounded sich das Gehirn.

Lass es auf deinem Projekt laufen

## Eine Engine. Drei Installationswege.

Der Synthesizer, der v3 antreibt, wird im selben Paket wie Linter und Recommender ausgeliefert. 145 Anti-patterns. 160 Brand-Specs. 1.182 Einträge. 17 IDEs. MIT, keine Telemetrie, kein Account.

$ /plugin marketplace add Laith0003/ux-skill
$ /plugin install ux@ux-skill
· oder ·
$ pip install uxskill
· oder ·
$ npx uxskill@latest init

Quellcode auf GitHub: Laith0003/ux-skill · Deutsches README: README.de.md · npm: uxskill · PyPI: uxskill · Englische Version: English version · Verwandte Lektüre: Brand-Specs als Trainingsdaten, Anti-patterns, Brands