Codex Frontend Design Skill mit echten Komponenten

Du hast einen Codex Frontend Design Skill installiert, nach einer Pricing-Seite gefragt und eine schönere Seite bekommen als vorher: bessere Typografie, weniger lila Verläufe. Dann hast du nach dem Settings-Screen gefragt, und Codex hat eine zweite Button-Komponente geschrieben, mit anderem Radius und einem Spinner, den es sich spontan ausgedacht hat. Genau das macht ein Geschmacks-Skill, wenn er allein steht. Dieser Beitrag erklärt, was ein Frontend Design Skill ist, aus welchen Ordnern Codex Skills lädt, welche du auf GitHub findest und wie du einen mit einer echten Komponenten-Registry, einem MCP-Server und einem AGENTS.md-Block kombinierst, damit Codex aus Komponenten baut, die dir gehören.

Jeden Pfad und jede Einstellung unten haben wir am 6. November 2026 mit der Doku Build skills (opens in a new tab) von OpenAI (die alte Adresse developers.openai.com/codex/skills leitet dorthin weiter) und der Skills-Doku (opens in a new tab) von Cursor abgeglichen. Beide ändern sich oft. Liest du das Monate später, prüf sie noch einmal.

Was ist ein Codex Frontend Design Skill?

Ein Skill ist ein Ordner mit einer Datei SKILL.md. Die Datei beginnt mit YAML-Frontmatter, das name und description enthalten muss, danach folgen Anweisungen in Markdown. Optionale Ordner enthalten scripts/, references/ und assets/, und eine optionale Datei agents/openai.yaml legt UI-Metadaten, die Aufrufregel und Tool-Abhängigkeiten fest. Codex Skills folgen der offenen Agent-Skills-Spezifikation (opens in a new tab), derselbe Ordner funktioniert also auch in anderen Agenten, die das Format lesen.

Ein Frontend Design Skill ist einer, dessen Anweisungen sich um UI drehen: wie man eine visuelle Richtung wählt, welche Schriften und Farben man meidet, wie man einen Hero anlegt, was man prüft, bevor ein Screen fertig ist. Am Format selbst ist nichts speziell für Frontend. Es ist ein Prompt, den Codex im richtigen Moment lädt.

So nutzt Codex ihn laut Doku:

• Beim Start liest Codex von jedem Skill nur Name, Beschreibung und Dateipfad. Diese Liste belegt standardmäßig höchstens 2% des Kontextfensters des Modells (8.000 Zeichen, wenn das Fenster unbekannt ist), und mit skills.max_context_tokens hebst du das auf bis zu 10.000 Tokens an.
• Expliziter Aufruf: Tipp $, um einen Skill im Prompt zu erwähnen, oder führ /skills in Codex CLI oder in der IDE-Erweiterung aus.
• Impliziter Aufruf: Codex wählt einen Skill selbst, wenn deine Aufgabe zu seiner description passt. Dann liest es die komplette SKILL.md.

Damit ist die Beschreibung die wichtigste Zeile der Datei. OpenAI rät, den Hauptanwendungsfall und die Auslösewörter an den Anfang zu stellen, denn Codex kürzt Beschreibungen, wenn viele Skills installiert sind.

Aus welchen Ordnern lädt Codex Skills?

Aus vier Ebenen. Das ist die Tabelle aus der OpenAI-Doku, gekürzt:

Codex folgt Skill-Ordnern, die als Symlink angelegt sind, und erkennt Änderungen von selbst; taucht ein neuer Skill nicht auf, starte Codex neu. Manche Community-READMEs auf GitHub sagen noch, du sollst Skills nach ~/.codex/skills kopieren, was ältere Codex-Builds lesen. Die aktuelle Doku nennt nur die .agents/skills-Ordner oben, also nimm die.

Um einen Skill abzuschalten, ohne ihn zu löschen, ergänz einen Eintrag in ~/.codex/config.toml:

[[skills.config]]
path = "/Users/you/.agents/skills/frontend-design/SKILL.md"
enabled = false

Dieselben Ordner zählen, wenn du auch Cursor nutzt. Laut Doku lädt Cursor .agents/skills und ~/.agents/skills, zur Kompatibilität außerdem .codex/skills und .claude/skills. Ein Cursor Frontend Design Skill und einer für Codex können derselbe Ordner sein.

Welche Frontend Design Skills gibt es auf GitHub?

Bei zwei Quellen lohnt sich ein Blick ins Original: Anthropics Skill frontend-design, der in Codex unverändert funktioniert, und die kuratierten Codex Skills von OpenAI, unter denen kein allgemeiner Frontend Design Skill ist. Die meisten Community-Listen, die du findest, wenn du einen Frontend Design Skill auf GitHub suchst, verweisen auf den ersten. Was wir am 6. November 2026 gefunden haben:

• Anthropics frontend-design, im Repository anthropics/skills (opens in a new tab). Seine Beschreibung verspricht Anleitung für ein unverwechselbares, bewusst gewähltes visuelles Design, wenn du UI baust oder umbaust. Der Text bittet das Modell, das Design im Thema des Produkts zu verankern, eine ästhetische Richtung zu wählen und die Defaults zu meiden, durch die generierte Seiten alle gleich aussehen. Er ist für Claude geschrieben und funktioniert in Codex unverändert, weil das Format dasselbe ist.
• Die kuratierten Skills von OpenAI, in openai/skills (opens in a new tab). Der Ordner enthält 39 Skills. Acht sind für Figma (figma-implement-design, figma-create-design-system-rules und weitere), zwei für Playwright, und keiner ist ein allgemeiner Frontend Design Skill. Das Repository bezeichnet sich inzwischen als veraltet und verweist auf openai/plugins (opens in a new tab).
• Community-Pakete mit UI Design Skills für Codex, oft gebündelt mit Skills für Deployment, Tests und Doku. Lies jeden davon, bevor du ihn installierst: Ein Skill besteht aus Anweisungen, denen dein Agent folgt, und ein Skill mit scripts/ kann Code ausführen.

Welcher besser passt, hängt vom Job ab. Für eine einzelne Landingpage ohne Designsystem dahinter ist Anthropics Skill eine gute Wahl, weil er das Modell vom generischen Look wegschiebt. Für eine App mit fünfzig Screens zieht er in die falsche Richtung: Ein Skill, der auf jedem Screen eine unverwechselbare Entscheidung verlangt, bringt dir fünfzig unverwechselbare Screens.

Warum erfindet ein Design Skill allein trotzdem Komponenten?

Weil ein Skill Text ist. Er kann sagen „nutz eine Akzentfarbe“ oder „prüf die Seite bei 390px“, aber er kann Codex nicht sagen, dass dein Projekt schon einen Button mit loading-Prop hat, eine Card mit auswählbarem Modus oder einen Anmelde-Screen mit Code-Ansicht. Ohne etwas, aus dem es wählen kann, macht Codex, was es immer macht: Es schreibt eine Komponente aus dem Gedächtnis, und auf dem nächsten Screen schreibt es sie noch einmal, ein bisschen anders.

Drei Teile schließen diese Lücke, und jedes hat genau eine Aufgabe:

Der Skill legt die Reihenfolge fest: zuerst die Registry durchsuchen, die Props lesen, mit der CLI installieren, dann die Geschmacksregeln auf Layout und Texte anwenden. Der Guide zu MCP für Komponentenbibliotheken erklärt die Server-Seite dazu für jeden Agenten.

Wie kombiniere ich in Codex einen Design Skill mit einer Registry?

In drei Schritten: MCP-Server und Regeldatei der Registry verbinden, den Skill der Bibliothek ergänzen und dann deine Geschmacksregeln als zweiten Skill schreiben, der Codex zuerst zur Registry schickt. Das Beispiel nutzt unsere Bibliothek Wingo UI, weil ihre CLI die Codex-Config für dich schreibt; mit jeder Registry, die einen MCP-Server hat, funktionieren dieselben Schritte.

Schritt 1: MCP-Server und AGENTS.md-Block verbinden

npx wingo-ui@latest login
npx wingo-ui@latest agents install codex

login speichert einen API-Key (für ein kostenloses Konto reicht eine E-Mail-Adresse). agents install codex schreibt eine Tabelle [mcp_servers.wingo-ui] in ~/.codex/config.toml und einen markierten Regelblock in ~/.codex/AGENTS.md. Die Regeln sagen Codex, dass es search_components, get_component und get_block aufrufen soll, bevor es UI schreibt, mit npx wingo-ui@latest add <slug...> installieren und semantische Tokens nutzen soll. Die komplette Anleitung mit der HTTP- und der stdio-Variante und den Vertrauensregeln für Projekt-Configs steht in unserem Guide zum Einrichten von Codex MCP.

Schritt 2: Den Skill der Bibliothek ergänzen

Für Codex schreibt die CLI die Config und den AGENTS.md-Block, aber keinen Skill. Die Skill-Datei ist ein öffentlicher Download, also kopier sie in deinen User-Skills-Ordner:

mkdir -p ~/.agents/skills/wingo-ui
curl -fsSL https://wingo-ui.com/agents/SKILL.md -o ~/.agents/skills/wingo-ui/SKILL.md

Seine Beschreibung nennt die Screens und Komponenten, die er abdeckt (Anmeldung, Settings, Pricing, Tabellen, Dialoge, OTP Input), damit Codex ihn selbst einer UI-Aufgabe zuordnen kann. Der Text ist der Ablauf: auf Updates prüfen, erst suchen und dann schreiben, ganze Screens mit einem Block beginnen, über Props konfigurieren, 390px und 1440px in Light und Dark prüfen. npx wingo-ui@latest agents update frischt den AGENTS.md-Block auf; für diese kopierte Datei führst du die curl-Zeile einfach noch einmal aus.

Schritt 3: Den Geschmacksteil als eigenen Skill schreiben

Pack deine Geschmacksregeln in einen eigenen, kleinen Skill, der die Registry kennt. Dieser hier liegt im Repository, also bekommt dein Team ihn mit dem Code:

---
name: frontend-design
description: Visuelle Richtung für neue Screens und Redesigns in dieser App (Seiten, Dashboards, Formulare, Marketing-Abschnitte). Zusammen mit dem Skill wingo-ui nutzen. Nicht für Backend- oder Test-Änderungen.
---

# Frontend-Design für diese App

1. Zuerst aus der Bibliothek bauen. Ruf search_components für jedes Teil auf; schreib nie einen Button, eine Card, einen Dialog, ein Feld oder ein Menü von Hand.
2. Den Look über Props ändern (variant, tone, size, radius, Labels), nicht mit neuem CSS. Überall der neutrale Tone, der Brand-Tone nur für die eine Hauptaktion pro Screen.
3. Im Layout passiert das Design: ein klarer Blickfang pro Screen, großzügige Abstände, echte Texte aus dem Produkt, kein Lorem Ipsum.
4. Den Hintergrund auf jeder Ebene abstufen: Seite, dann bg-surface, dann Kacheln mit bg-foreground/5. Nie eine Card auf einer Fläche im selben Farbton.
5. Bevor du fertig bist: 390px und 1440px, Light und Dark, nur Tastatur. Liste jeden Handler auf, der noch auf Beispieldaten läuft.

Speicher ihn als .agents/skills/frontend-design/SKILL.md im Stamm des Repositorys. Regel 1 ist die Zeile, die ein eigenständiger Geschmacks-Skill nie hat, und sie macht aus „mach es schön“ ein „mach es schön, mit dem, was wir haben“. Hast du Anthropics Skill ebenfalls installiert, heißt der auch frontend-design: Benenn deinen um (zum Beispiel app-design, dann erwähnst du $app-design), denn Codex führt zwei Skills mit demselben Namen nicht zusammen und listet beide auf.

Was baut Codex, wenn das Paar eingerichtet ist?

Es baut Screens aus den Komponenten der Bibliothek, mit der CLI installiert, statt für jeden Screen eine neue Card und einen neuen Button zu schreiben. Nenn den Skill und die Komponenten im Prompt, damit Skill und Server beide zum Einsatz kommen:

$frontend-design Bau /pricing für Harbor mit zwei Plan-Cards aus der Bibliothek
wingo-ui. Ruf zuerst get_component für card und button auf. Der Team-Plan ist
ausgewählt. Installier alles mit der CLI und zeig mir den Diff.

Nach get_component weiß Codex, dass die Card eine einfache API hat (title, description, footer, children als Inhalt) und einen selected-Ring, und dass der Button tone und fullWidth annimmt. Ein guter Lauf installiert beide mit npx wingo-ui@latest add card button und schreibt etwas in dieser Art:

import { Button } from "@/components/ui/button";
import { Card } from "@/components/ui/card";

export function PlanCards() {
  return (
    <div className="grid gap-4 sm:grid-cols-2">
      <Card
        variant="outline"
        title="Starter"
        description="$0 pro Monat, ein Projekt"
        footer={<Button variant="outline" fullWidth>Starter wählen</Button>}
      >
        Bis zu 3 Teammitglieder und 1 GB Speicher.
      </Card>
      <Card
        variant="outline"
        tone="brand"
        selected
        title="Team"
        description="$24 pro Monat, unbegrenzt viele Projekte"
        footer={<Button tone="brand" fullWidth>Team wählen</Button>}
      >
        Unbegrenzt viele Teammitglieder, 100 GB Speicher und Priority Support.
      </Card>
    </div>
  );
}

Der Brand-Tone taucht genau einmal auf, bei dem Plan, den die Leute wählen sollen: Das ist Regel 2 des Skills bei der Arbeit. Die Demo unten ist dieselbe Card mit der Outline-Variante, dem Brand-Tone und dem selected-Ring, nur auf einem Inserat statt auf einem Plan.

Beim Button driftet handgeschriebene UI meist zuerst auseinander: Jeder Screen bekommt seinen eigenen Spinner und seinen eigenen Disabled-Zustand. Die Version der Bibliothek regelt beides über loading und loadingText, also hat Codex keinen Grund, selbst einen zu schreiben.

Für einen ganzen Screen schickt der Schritt „mit einem Block beginnen“ aus dem Skill Codex zu get_block. Ein Anmelde-Prompt wie „Bau /login aus dem Block login-page, Card-Layout, Passwort und E-Mail-Code, keine Social-Buttons“ sollte in einer Login Page mit layout="card", methods={["password", "otp"]} und showProviders={false} enden, dazu deine eigenen onSignIn, onSendCode und onVerifyCode. Lass dir die Handler auflisten, die noch auf ihren Defaults stehen: Ohne onVerifyCode akzeptiert die Code-Ansicht 123456 von jedem.

Wie prüfe ich, ob Codex Skill und Server nutzt?

Vier Befehle sagen es dir, und die Tool-Aufrufe in einem Lauf bestätigen es:

• Führ /skills in Codex aus. Dort sollten wingo-ui und frontend-design stehen; fehlt einer, prüf den Ordnernamen und das Frontmatter und starte Codex neu.
• Führ codex mcp list im Projektordner aus. Der Server wingo-ui sollte als enabled erscheinen.
• Führ npx wingo-ui@latest agents status aus, um zu sehen, welche Regeldateien vorhanden sind.
• Stell Codex eine Frage, die nur der Server beantworten kann, etwa „Ruf get_account_status auf dem Server wingo-ui auf“. Antwortet es mit deinem Plan, ist der Key beim Server angekommen.

Schreibt Codex trotzdem eine Komponente von Hand, sieh dir seine Tool-Aufrufe an. Kein Aufruf von search_components heißt: Der Skill wurde nicht geladen, oder der Prompt hat ihn nicht genannt. Beginn den Prompt mit $frontend-design und versuch es noch einmal.

Womit fange ich an?

Richte zuerst die kostenlosen Teile ein: npx wingo-ui@latest login, npx wingo-ui@latest agents install codex, die beiden Skill-Dateien oben, dann den Prompt für die Plan-Cards. Button und Card sind kostenlos, zusammen mit 73 weiteren Items. Die Login Page gehört zu Wingo UI Pro ($8 im Monat, $80 im Jahr oder einmalig $150, siehe die Preisseite), und ganze Seiten findest du in der Vorlagen-Galerie. Die Doku zu Coding-Agenten listet jede Datei, die die CLI für jeden Agenten schreibt, und weitere Setups wie dieses stehen unter UI mit KI-Agenten bauen, darunter AGENTS.md vs CLAUDE.md für die Regeldatei und der Guide zu Cursor und shadcn MCP für denselben Job in Cursor.

Häufige Fragen

Wo sucht Codex nach Skills?

In .agents/skills in dem Ordner, in dem du Codex startest, und in jedem übergeordneten Ordner bis zum Stamm des Repositorys, in ~/.agents/skills für deinen Benutzer, in /etc/codex/skills für den ganzen Rechner und in den Skills, die Codex mitbringt. So steht es mit Stand 6. November 2026 in der Skills-Doku von OpenAI.

Kann ich Anthropics Skill frontend-design in Codex nutzen?

Ja. Es ist eine einfache SKILL.md mit Name und Beschreibung, im selben offenen Format, das Codex liest. Es reicht also, den Ordner nach .agents/skills oder ~/.agents/skills zu kopieren. Geschrieben wurde er für Claude: Lies ihn einmal durch und streich die Zeilen, die nicht zu deinem Projekt passen.

Liefert OpenAI einen Frontend Design Skill für Codex?

Nicht im kuratierten Ordner des Repositorys openai/skills, Stand 6. November 2026: Er enthält 39 Skills, davon acht für Figma, und keinen für allgemeines Frontend-Design. Das Repository bezeichnet sich inzwischen als veraltet und verweist auf openai/plugins.

Funktioniert ein Frontend Design Skill auch in Cursor?

Ja. Laut Cursor-Doku lädt Cursor Skills aus .agents/skills und ~/.agents/skills, zur Kompatibilität außerdem aus .codex/skills und .claude/skills. Ein Skill-Ordner kann also Codex und Cursor gleichzeitig bedienen.

Warum schreibt Codex trotz Design Skill eigene Komponenten?

Ein Skill ist Text: Er kann Geschmack und einen Ablauf beschreiben, aber er kann nicht die Komponenten auflisten, die du hast, samt ihren Props. Verbinde eine Komponentenbibliothek per MCP und lass den Skill Codex anweisen, sie zuerst zu durchsuchen. Dann hat Codex etwas Echtes, aus dem es wählen kann.