Installation: zwei Befehle
Anthropic liefert die Frontend-Design-Skill innerhalb des frontend-design Plugins aus, das über den offiziellen Claude Code Plugin Marketplace vertrieben wird (von Anthropic verifiziert, über eine Million Installationen). Die Bezeichnungen führen hier zu Verwirrung: Das *Plugin* ist die Installationseinheit, die *Skill* ist der Inhalt und das, was bei UI-Arbeiten aktiviert wird. Die Installation erfolgt über zwei Slash-Befehle innerhalb einer Claude Code Session:
- 1
Offiziellen Marketplace hinzufügen
Einmalige Einrichtung; registriert den Plugin-Katalog von Anthropic.
/plugin marketplace add anthropics/claude-code - 2
Plugin installieren
Von diesem Zeitpunkt an wird die Skill automatisch geladen, wann immer Ihre Anfrage Frontend-Arbeit betrifft; es ist kein manueller Aufruf nötig.
/plugin install frontend-design@claude-code-plugins
Was Sie erhalten, sind keine Skripte oder Komponenten: Der gesamte Payload des Plugins ist eine 55-zeilige SKILL.md im öffentlichen Repo von Anthropic. Wir haben diese analysiert, sodass der Rest dieser Seite die tatsächliche Datei beschreibt und nicht die Marketing-Zusammenfassung.
Was die Skill tatsächlich verändert
Eine Skill ist ein Bündel von Instruktionen, das geladen wird, wenn es relevant ist, statt bei jeder Anfrage: die On-Demand-Hälfte des Agent-File-Stacks. Diese hier wird geladen, wenn Ihre Anfrage UI-Arbeit betrifft (die Beschreibung umfasst „das Erstellen neuer UIs oder das Umgestalten bestehender“), und versetzt das Modell in eine spezifische Rolle: ein Design Lead in einem kleinen Studio, dessen Kunde bereits template-basierte Vorschläge abgelehnt hat. Die folgenden Anweisungen sind ungewöhnlich konkret:
- Sie benennt KI-Defaults und verbietet sie. Die Datei beschreibt die drei Looks, um die sich KI-Designs „clustern“: warmes Creme nahe
#F4F1EAmit einer Serif-Display-Schrift und Terrakotta-Akzent, Fast-Schwarz mit einem acid-grünen oder zinnoberroten Akzent sowie ein an Broadsheets erinnerndes Layout mit Haarlinien und Null-Radius. Dem Modell wird gesagt, diese als Defaults und nicht als Optionen zu behandeln. Damit bestätigt das Team von Anthropic selbst, warum KI-Websites gleich aussehen. - Sie erzwingt einen Plan vor dem Code. Zwei Durchgänge: Zuerst ein kompaktes Token-System brainstormen (4 bis 6 benannte Hex-Werte, zwei oder mehr Typografie-Rollen, ein Layout-Konzept, ein „Signature-Element“, durch das die Seite im Gedächtnis bleibt), dann diesen Plan anhand des Briefings kritisieren und prüfen, ob dasselbe Ergebnis bei jedem ähnlichen Prompt erscheinen würde – erst danach erfolgt die Umsetzung.
- Sie behandelt Typografie und Struktur als Bedeutungsträger. Die Schriftkombination soll die Persönlichkeit der Seite transportieren, und strukturelle Elemente wie eine 01 / 02 / 03 Nummerierung sind nur erlaubt, wenn der Inhalt tatsächlich eine Sequenz ist.
- Sie setzt eine Qualitätsuntergrenze. Responsive bis hin zu Mobile, sichtbarer Tastatur-Fokus, Beachtung von reduced motion sowie ein ganzer Abschnitt zum Interface-Copywriting (aktive Sprache, „Änderungen speichern“ statt „Absenden“, Fehlermeldungen, die erklären, was passiert ist).
Das ist ein wirklich gutes Design-Briefing und der Grund, warum sich die Installation des Plugins lohnt. Beachten Sie jedoch, was dieser Prozess erzeugt: ein frisches Token-System, das pro Briefing erfunden wird. Das ist die Grenze des Anwendungsbereichs, und die Datei selbst deutet darauf hin: „Menschliche Schöpfer haben ein Gedächtnis und versuchen immer, etwas Neues zu schaffen.“ Die Skill hat kein Gedächtnis. Ihres muss an anderer Stelle gespeichert werden.
Die Lücke: Geschmack ist nicht dasselbe wie Werte
Eine Skill transportiert das *Wie der Entscheidung*. Sie transportiert nicht, *was entschieden wurde*. Diese Unterscheidung klingt akademisch, bis man zwei Sessions nebeneinander betrachtet.
Betrachten Sie den Zwei-Durchgang-Prozess erneut: Die Skill weist das Modell an, für jedes Briefing ein Token-System aus 4 bis 6 Farben und ein Signature-Element zu *erfinden* und jeden Plan abzulehnen, der dem gleicht, was bei einem ähnlichen Prompt entstehen würde. Pro Session ist das genau die richtige Anweisung; sie macht einzelne Screens unverwechselbar. Über mehrere Sessions hinweg wirkt sie jedoch wie eine Divergenz-Maschine: Die Skill hat keine Möglichkeit zu wissen, dass Ihre Primärfarbe oklch(0.55 0.19 45) ist, da Sie es ihr nie gesagt haben und es in der Datei keinen Ort gibt, an dem dies stehen könnte. Ihr eigener Prozess drängt jede neue Session hin zu einem frischen, vertretbaren, aber anderen System.
Zwei Sessions, zwei gute Buttons, zwei verschiedene Blautöne. Keiner davon ist ein Fehler. Zusammen sind sie ein Markenproblem.
| Design-Skill | DESIGN.md + Tokens | |
|---|---|---|
| Bereitstellung | Urteilsvermögen: Wie entschieden wird | Werte: Was entschieden wurde |
| Abstände | Verwendet eine Skala | Definiert, welche Skala |
| Farbe | Wählt eine Farbe mit gutem Kontrast | Benennt die exakte Farbabstufung |
| Übersteht eine neue Session | Ja, als Verhalten | Ja, als identische Werte |
| Zwei Screens passen zusammen | Nur durch Zufall | Systembedingt |
Selbst reproduzieren
Verlassen Sie sich nicht auf diese Aussage. Der Test ist kurz und das Ergebnis eindeutig.
- 1
Fordern Sie in einer neuen Session eine Pricing-Card an
Mit aktivem Skill und ohne vorhandenes Designsystem. Speichern Sie die Ausgabe.
- 2
Starten Sie eine komplett neue Session
Keine neue Nachricht, sondern eine neue Session, damit nichts übernommen wird.
claude - 3
Fordern Sie ein Einstellungsmenü für dasselbe Produkt an
Gleiche Produktbeschreibung, kein Bezug auf die erste Komponente.
- 4
Vergleichen Sie die beiden Ergebnisse (Diff)
Vergleichen Sie die Primärfarbe, den Border-Radius, die Basis-Schriftgröße und den vertikalen Abstand zwischen Label und Steuerelement.
- 5
Werten Sie das Ergebnis objektiv aus
Beide werden kompetent aussehen. In unseren Tests weichen drei oder vier dieser vier Werte voneinander ab, wobei jede Wahl für sich genommen plausibel ist.
Falls Ihre beiden Ausgaben eng übereinstimmen, prüfen Sie, ob andere Quellen Konstanten liefern: eine bestehende Theme-Datei, eine bereits im Repo vorhandene Komponentenbibliothek oder eine lang laufende Session. Das ist der entscheidende Punkt: Übereinstimmende Ergebnisse bedeuten, dass die Werte aus einer dauerhaften Quelle stammen und nicht vom Skill.
Die Lücke schließen
Behalten Sie den Skill. Er erledigt eine Aufgabe, die sonst nichts übernimmt. Fügen Sie die Ebene hinzu, die er nicht enthalten kann: einen Token-Satz plus eine DESIGN.md im Repo, die der Coding-Agent zu Beginn jeder Session liest.
Sobald beides implementiert ist, ist die Arbeitsteilung klar. Die Datei beantwortet die Fragen: *Welches* Blau, *welcher* Radius, *welche* Typografie-Skala. Der Skill beantwortet, wie diese zu einem gut lesbaren Screen zusammengesetzt werden. Keines ersetzt das andere; der häufige Fehler besteht in der Annahme, der Skill mache die Datei überflüssig.
- 1
Ein Kit im Repo installieren
Dies schreibt die DESIGN.md sowie die Token-Dateien, die Ihr Coding-Agent lesen wird.
npx --yes identityforge@latest install --client claude-code - 2
Das gewünschte Kit anwenden
Für kostenlose Kits ist kein Konto erforderlich.
identityforge apply ambient-sage - 3
In der AGENTS.md darauf verweisen
Eine einzige Zeile, damit der Design-Vertrag auffindbar und nicht zufällig ist.
Never hardcode theme colors. Use the semantic tokens in DESIGN.md. - 4
Den Zwei-Session-Test wiederholen
Gleiches Vorgehen wie oben. Die Werte sollten nun exakt übereinstimmen, da sie gelesen und nicht neu entschieden werden.
Dem Skill eine Grundlage für Konsistenz geben
Ein Kit installiert die Tokens und die DESIGN.md, die der Design-Skill nicht eigenständig mitführen kann. Der Skill liefert das handwerkliche Geschick; die Datei liefert die Markenidentität.
Wird er eine bestehende Codebasis und ein Theme respektieren oder sein eigenes Ding machen?
Dies ist die Frage, die tatsächlich im Zusammenhang mit Design-Skills gestellt wird, und fast nichts in der Literatur beantwortet sie. Die ehrliche Antwort: Ein Skill respektiert Ihr Theme nur in dem Maße, in dem Ihr Theme als für ihn lesbare Werte existiert. Ein Skill besteht aus Anweisungen zur Arbeitsweise. Er ist keine Quelle für Ihre Design-Werte.
Diese Unterscheidung entscheidet über das Ergebnis in einer bestehenden Codebasis:
| Theme existiert als Tokens + DESIGN.md | Theme existiert in Figma und in den Köpfen der Beteiligten | |
|---|---|---|
| Was der Skill liest | Ihre tatsächlichen Werte | Nichts. Es gibt keine Quelle |
| Was er produziert | Komponenten basierend auf Ihrem System | Plausible Komponenten basierend auf Library-Defaults |
| Über mehrere Sessions hinweg | Stabil: wird jedes Mal neu gelesen | Divergiert und driftet immer weiter weg |
| Was zuerst behoben werden muss | Nichts | Die fehlenden Werte, nicht der Skill |
Ein Skill kann keine Werte liefern, die ihm nie gegeben wurden
Wenn ein Skill in einer themed Codebasis Ergebnisse liefert, die nicht zur Marke passen, ist die übliche Ursache, dass das Theme im Repository nicht lesbar ist. Ein besserer Skill behebt dies nicht. Das Hinzufügen der Werte hingegen schon.
Dafür gibt es eine messbare Version. Wir haben 299 öffentliche DESIGN.md-Dateien analysiert und festgestellt, dass von den 72, die ein visuelles System beschreiben, 86 % keine semantischen Farbrollen-Namen verwenden: Sie listen Hex-Werte auf oder benennen Farben nach ihrem Farbton. Ein Skill, dem --primary übergeben wird, kann Ihr System auf eine Komponente anwenden, die niemand beschrieben hat. Ein Skill, dem eine Tabelle mit Hex-Werten gegeben wird, kann nur kopieren – und beim Kopieren beginnt er zu raten.
- 1
Prüfen Sie, ob Ihr Theme überhaupt lesbar ist
Suchen Sie im Root des Repositories nach einer DESIGN.md oder einer Token-Datei. Wenn die einzige Quelle Figma ist, hat der Skill keine Grundlage zum Arbeiten.
- 2
Werte semantisch gestalten
Rollen statt Farbtöne, damit der Skill diese auch in Fällen korrekt platzieren kann, die Sie nie schriftlich fixiert haben.
- 3
In der AGENTS.md als Verbot darauf verweisen
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Denselben Build in einer neuen Session erneut ausführen
Gleiche Primärfarbe, gleicher Radius bedeutet, dass die Werte gelesen werden. Geringfügige Abweichungen bedeuten, dass das Modell sich erinnert – und Erinnerungen verblassen.
Skill, Plugin oder ein Eintrag in einem Marketplace?
Die meisten Texte hierzu sind Zusammenfassungen, und in diesen werden die drei Begriffe synonym verwendet. Sie sind jedoch nicht dasselbe, und der Unterschied entscheidet darüber, ob das installierte Element überhaupt geladen werden kann.
| Was es ist | Wie es das Modell erreicht | |
|---|---|---|
| Ein Skill | Ein Verzeichnis mit einer SKILL.md: eine Beschreibung plus Anweisungen | Das Modell lädt diesen, wenn die Beschreibung mit der Anfrage übereinstimmt |
| Ein Plugin | Ein Paket, das Skills, Befehle, Subagents und Hooks bündeln kann | Es wird einmal installiert; alles darin gebündelte wird verfügbar |
| Ein Marketplace-Eintrag | Ein Indexeintrag, der auf ein veröffentlichtes Plugin verweist | Über einen Eintrag wird nichts geladen. Es ist eine Katalogseite |
Die praktische Konsequenz ist die Ladebedingung. Ein Skill wird vom Modell anhand seiner Beschreibung ausgewählt und greift daher nur ein, wenn die Anfrage wie eine Design-Aufgabe klingt. Fordern Sie „eine Einstellungsseite“ an, und er wird aktiviert. Fordern Sie an, „das Padding in Zeile 40 zu korrigieren“, tut er dies möglicherweise nicht, da dies eher wie eine Bearbeitung als eine Design-Aufgabe wirkt. Sie erhalten dann eine gewöhnliche Änderung ohne die handwerkliche Qualität, für die Sie den Skill installiert haben.
Einfacher Weg, um zu prüfen, ob der Skill aktiv war
Führen Sie dieselbe Anfrage zweimal in neuen Sessions aus – einmal als Design-Aufgabe formuliert und einmal als mechanische Korrektur. Wenn sich die Ergebnisse in der Rhythmik der Abstände und der Abdeckung von Zuständen unterscheiden und nicht nur in der Wortwahl, sehen Sie, wie der Skill ein- und ausgeschaltet wird. Das ist der Fehler, den Nutzer als „funktioniert manchmal“ beschreiben.
Wenn der Skill und die DESIGN.md widersprüchlich sind
Dies ist die Frage, die Vergleichstests komplett auslassen, aber sie ist die entscheidende, sobald beides vorhanden ist. Sie stehen im Konflikt, da sie von verschiedenen Personen für verschiedene Zwecke geschrieben wurden. Ihre Datei besagt, dass die Primärfarbe oklch(0.55 0.19 45) ist. Das Urteil des Skills besagt, dass eine Primärfarbe einen Kontrastschwellenwert gegenüber der Oberfläche erreichen muss, auf der sie liegt. Auf einer hellen Karte stimmen diese Ansichten überein. Auf Ihrer dunklen, hervorgehobenen Oberfläche möglicherweise nicht.
Keine der beiden Ebenen ist falsch, und es gibt keinen integrierten Schiedsrichter: Das Modell löst den Konflikt auf, und standardmäßig entscheidet es sich für die Anweisung, die spezifischer ist und zuletzt gelesen wurde. Deshalb muss die Auflösung schriftlich fixiert und nicht vorausgesetzt werden:
- Werte sind nicht verhandelbar; die Komposition schon. Formulieren Sie dies so in der
AGENTS.md. Hex-Werte, Radien und die Typografie-Skala kommen aus der Datei. Wie sie auf einem Bildschirm angeordnet werden, liegt im Ermessen des Skills. - Geben Sie der Datei den Ausweg, den der Skill benötigt. Der oben genannte Konflikt existiert nur, weil das System nur eine Primärfarbe hat. Definieren Sie eine Primärfarbe, die auch auf dunklen Oberflächen lesbar ist, oder ein dokumentiertes Paar, und die Unstimmigkeit verschwindet, anstatt in jeder Session neu verhandelt zu werden.
- Schreiben Sie Verbote, keine Präferenzen. „Bevorzuge semantische Tokens“ verliert gegen ein spezifisches Kontrastargument. „Hardcode niemals Theme-Farben“ hingegen nicht, da es keinen Spielraum für Abwägungen lässt.
- Erwarten Sie bei Konflikten kein Feedback. Das Modell wird Sie nicht darauf hinweisen, dass es Ihren Token überschrieben hat. Die einzige zuverlässige Erkennung ist das Greppen des Diffs nach expliziten Farb- und Abstandswerten.
# the only conflict detector that actually fires: literals in the diff
git diff | grep -nE '#[0-9a-fA-F]{3,8}|oklch\(|rgb\(|[0-9]+px'Führen Sie dies bei jedem vom Agenten erstellten Diff aus. Ein sauberes Ergebnis bedeutet, dass die Werte gelesen wurden. Jedes Ergebnis ist eine Stelle, an der ein subjektives Urteil stillschweigend eine bereits getroffene Entscheidung ersetzt hat – derselbe Drift wie beim Zwei-Session-Test, nur über einen anderen Weg.
Lohnt sich die Installation des Skills überhaupt?
Ja. Er verbessert die handwerkliche Qualität einzelner Screens messbar und kostet nichts im Ausprobieren. Das Argument hier richtet sich gegen die Betrachtung als Komplettlösung, nicht gegen den Skill selbst.
Macht ein Designsystem den Skill redundant?
Nein, und das ist der symmetrische Fehler. Tokens sagen einem Agenten, welche Werte zu verwenden sind; sie sagen nichts darüber aus, wie man einen Screen so komponiert, dass er gut wirkt. Projekte mit einem starken System, aber ohne Design-Leitfaden, produzieren markenkonforme Layouts mit schwacher Hierarchie.
Hilft ein längerer Prompt gegen die Inkonsistenz zwischen den Sessions?
Nur innerhalb einer Session, und mit abnehmender Wirkung, je länger diese wird. Eine neue Session beginnt bei Null; alles, was dauerhaft bestehen bleiben soll, muss in einer Datei stehen.
Wenn ich mich entscheiden muss: Der Design-Skill oder eine DESIGN.md?
Die Datei, ohne Zweifel. Ohne sie entscheidet jede Session Ihre Marke neu und das Ergebnis divergiert dauerhaft. Ohne den Skill erhalten Sie markenkonforme Screens mit schwächerer Hierarchie – das ist eine Qualitätsgrenze, aber kein kumulatives Problem. Beheben Sie zuerst das kumulative Problem.
Gilt dies auch für Cursor und andere Agenten?
Der spezifische Skill gehört zu Claude Code, aber die Art der Lücke ist universell. Jeder Mechanismus, der Design-Urteilskraft ohne Design-Werte transportiert, erzeugt dieselbe Inkonsistenz zwischen den Sessions.