Was die Skill tatsächlich verändert
Eine Skill ist ein Paket aus Anweisungen, das nur dann geladen wird, wenn es relevant ist, und nicht bei jeder Anfrage – sie ist der On-Demand-Teil des Agent-File-Stacks. Die Frontend-Design-Skill wird geladen, wenn UI-Arbeiten angefordert werden, und lenkt das Modell hin zu stärkeren Defaults.
In der Praxis sind dies die Unterschiede, die am konsistentesten auftreten, und sie sind substanziell statt nur kosmetisch:
- Spacing erhält einen Rhythmus. Werte basieren auf einer Skala, statt pro Element individuell gewählt zu werden, sodass der vertikale Rhythmus über eine Seite hinweg erhalten bleibt.
- Hierarchie wird bewusst gestaltet. Größe, Gewicht und Farbe werden gemeinsam genutzt, um Ebenen zu trennen, anstatt sich nur auf die Größe zu verlassen.
- Weniger Standard-Layouts. Das reflexive Grid aus drei gleich großen Karten erscheint seltener, wenn der Inhalt nicht tatsächlich drei gleichwertige Elemente suggeriert.
- Zustände werden berücksichtigt. Hover, Focus, Disabled und Error erscheinen ohne explizite Aufforderung – genau dort, wo die meisten generierten Komponenten lückenhaft sind.
Das ist eine signifikante Verbesserung und der Grund, warum es sich lohnt, die Skill zu installieren. Gleichzeitig ist dies jedoch ihr gesamter Umfang.
Die Lücke: Geschmack ist nicht dasselbe wie Werte
Eine Skill definiert, *wie entschieden wird*. Sie definiert nicht, *was entschieden wurde*. Diese Unterscheidung klingt akademisch, bis man zwei Sessions nebeneinander betrachtet.
Die Skill wird dem Modell zuverlässig vermitteln, dass eine primäre Aktion einen ausreichenden Kontrast zum Hintergrund benötigt und nicht mit einer sekundären Aktion konkurrieren sollte. Sie hat jedoch keine Möglichkeit zu wissen, dass Ihre Primärfarbe oklch(0.55 0.19 45) ist – da Sie es ihr nie mitgeteilt haben und es innerhalb einer Skill keinen Ort für solche Informationen gibt. Daher wählt sie eine vertretbare Farbe. In der nächsten Session wählt sie eine andere vertretbare Farbe.
Zwei Sessions, zwei gute Buttons, zwei verschiedene Blautöne. Keiner davon ist ein Fehler. Zusammen ergeben sie jedoch ein Markenproblem.
| Design-Skill | DESIGN.md + Design-Tokens | |
|---|---|---|
| Liefert | Urteilsvermögen – wie entschieden wird | Werte – was entschieden wurde |
| Spacing | Nutzt eine Skala | Definiert, welche Skala |
| Farbe | Wählt eine Farbe mit gutem Kontrast | Benen Sie Ihre exakte Steigung |
| Ü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 blindes Vertrauen – 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 wirklich neue Session
Keine neue Nachricht – eine neue Session, sodass nichts übertragen 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 (Diff)
Vergleichen Sie die Primärfarbe, den Border-Radius, die Basisschriftgröße und den vertikalen Abstand zwischen Label und Steuerelement.
- 5
Werten Sie das Ergebnis objektiv aus
Beide werden kompetent aussehen. In unseren Durchläufen wichen drei oder vier dieser vier Werte voneinander ab – und jeder für sich genommen war eine vertretbare Wahl.
Wenn Ihre beiden Ausgaben eng beieinander liegen, prüfen Sie, ob etwas anderes Konstanten liefert – eine bestehende Theme-Datei, eine bereits im Repo vorhandene Komponentenbibliothek oder eine lang laufende Session. Das ist der entscheidende Punkt: Übereinstimmende Ausgaben bedeuten, dass die Werte aus einer dauerhaften Quelle stammten 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 Agent zu Beginn jeder Session liest.
Sobald beides implementiert ist, ist die Arbeitsteilung klar. Die Datei beantwortet, *welches* Blau, *welcher* Radius, *welche* Typografie-Skala. Der Skill beantwortet, wie diese zu einem gut lesbaren Screen komponiert 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 erstellt die DESIGN.md sowie die Token-Dateien, die Ihr Coding-Agent ausliest.
npx --yes identityforge@latest install --client claude-code - 2
Das gewünschte Kit anwenden
Kostenlose Kits benötigen kein Konto.
identityforge apply ambient-sage - 3
Point AGENTS.md at it
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 Design-Tokens und die DESIGN.md, die der Design-Skill nicht eigenständig übertragen kann. Während der Skill die handwerkliche Umsetzung liefert, definiert die Datei die Markenidentität.
Wird sie eine bestehende Codebasis und ein Theme respektieren oder ihr eigenes Ding machen?
Das ist die Frage, die tatsächlich im Zusammenhang mit Design-Skills gestellt wird, und fast nichts, was darüber geschrieben wurde, beantwortet sie. Die ehrliche Antwort: Eine Skill respektiert Ihr Theme nur in dem Maße, in dem Ihr Theme als für sie lesbare Werte existiert. Eine Skill besteht aus Anweisungen zur Arbeitsweise. Sie ist keine Quelle für Ihre Werte.
Diese Unterscheidung entscheidet über das Ergebnis in einer bestehenden Codebasis:
| Das Theme existiert als Design-Tokens + DESIGN.md | Theme existiert in Figma und in den Köpfen der Beteiligten | |
|---|---|---|
| Was die Skill liest | Ihre tatsächlichen Werte | Nichts – es gibt keine Quelle |
| Was sie produziert | Komponenten Ihres Systems | Plausible Komponenten basierend auf Library-Defaults |
| Über mehrere Sitzungen hinweg | Stabil – wird jedes Mal neu gelesen | Divergiert und driftet immer weiter auseinander |
| Was zuerst behoben werden muss | Nichts | Die fehlenden Werte, nicht die Skill |
Eine Skill kann keine Werte liefern, die ihr nie gegeben wurden
Wenn eine Skill in einer themed Codebasis Ergebnisse liefert, die nicht zum Brand passen, ist die übliche Ursache, dass das Theme im Repository nicht lesbar ist. Eine bessere Skill zu implementieren, 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 Farbrollennamen verwenden – sie listen Hex-Codes auf oder benennen Farben nach ihrem Farbton. Eine Skill, der --primary übergeben wird, kann Ihr System auf eine Komponente anwenden, die niemand beschrieben hat. Eine Skill, der eine Tabelle mit Hex-Codes übergeben wird, kann nur kopieren, und beim Kopieren beginnt sie zu raten.
- 1
Prüfen Sie, ob Ihr Theme überhaupt lesbar ist
Suchen Sie im Root-Verzeichnis des Repositories nach einer DESIGN.md oder einer Token-Datei. Wenn Figma die einzige Quelle ist, fehlen dem Skill die notwendigen Grundlagen.
- 2
Machen Sie die Werte semantisch
Rollen statt Farbtöne, damit die 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
Führen Sie denselben Build in einer neuen Sitzung erneut aus
Gleiches Primary, gleicher Radius bedeutet, dass gelesen wird. Geringfügige Abweichungen bedeuten, dass erinnert wird – und Erinnerungen verblassen.
Skill, Plugin oder ein Eintrag in einem Marketplace?
Die meisten Texte hierzu sind Zusammenfassungen, und diese verwenden die drei Begriffe synonym. 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 | |
|---|---|---|
| Eine Skill | Ein Verzeichnis mit einer SKILL.md – eine Beschreibung plus Anweisungen | Das Modell lädt es, wenn die Beschreibung mit der Anfrage übereinstimmt |
| Ein Plugin | Ein Paket, das Skills, Befehle, Subagenten 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 handelt sich um 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 Designaufgabe formuliert ist. Fragen Sie nach „einer Einstellungsseite“, und der Skill wird aktiviert. Bitten Sie darum, „das Padding in Zeile 40 zu korrigieren“, und dies geschieht möglicherweise nicht, da dies eher wie eine Bearbeitung als wie eine Designaufgabe wirkt – und Sie erhalten 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 Designaufgabe formuliert und einmal als mechanische Bearbeitung. Wenn sich die Ergebnisse in Bezug auf Spacing-Rhythmus und State-Coverage unterscheiden und nicht nur in der Wortwahl, beobachten Sie das Ein- und Ausschalten des Skills. Genau 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, und sie ist die entscheidende, sobald beides vorhanden ist. Sie stehen im Konflikt, da sie von verschiedenen Personen für unterschiedliche Zwecke geschrieben wurden. In Ihrer Datei steht, dass die Primärfarbe oklch(0.55 0.19 45) ist. Die Einschätzung des Skills besagt, dass eine Primärfarbe einen Kontrastschwellenwert gegenüber der Oberfläche erreichen muss, auf der sie liegt. Auf einer hellen Card stimmen diese Ansichten überein. Auf einer dunklen, erhöhten 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 Lösung schriftlich fixiert und nicht vorausgesetzt werden:
- Werte sind nicht verhandelbar; die Komposition hingegen schon. Formulieren Sie dies so in der
AGENTS.md. Hex-Werte, Radien und die Typografie-Skala kommen aus der Datei. Wie diese auf einem Bildschirm angeordnet werden, liegt im Ermessen des Skills. - Geben Sie der Datei das Ventil, das der Skill benötigt. Der oben beschriebene Konflikt existiert nur, weil das System eine einzige 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 Spacing-Werten.
# 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 beachtet wurden. Jeder Treffer ist eine Stelle, an der eine subjektive Einschätzung stillschweigend eine bereits getroffene Entscheidung ersetzt hat – das ist 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 ist kostenlos auszuprobieren. 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-Leitplanken, 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 erhalten bleiben soll, muss daher 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 permanent. 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.