Figma Design System mit Custom Skills: Mein 3-Skill-Paket für Make

Figma Design System: Warum der Build trotzdem nicht markenkonform war

Der Review-Build war fast richtig. Genau das machte ihn gefährlich. Die Schaltflächen hatten einen Radius von 12px, obwohl das System seit dem Rebranding auf 8px festgelegt ist. Als Primärakzent erschien ungefähr #18C5DA – optisch nah am #06B6D4 des Kunden, doch beim Einfügen in die Figma-Farbauswahl war die Abweichung sofort sichtbar. Nach drei Frames nutzte die Typografieskala bereits 18px für Fließtext, obwohl das System 16px vorschreibt.

Der Prompt von diesem Morgen war nicht das Problem. Entscheidend war der Prompt von sechs Eingaben zuvor. Figma Make behält den Kontext über eine Sitzung hinweg, doch Designsystemregeln verlieren an Gewicht, je weiter ihre Eingabe zurückliegt. Spätestens bei der dritten Hero-Variante begann das Modell deshalb, plausibel wirkende Tokenwerte zu improvisieren. Die Release Notes vom Mai 2026 benennen genau diese Lücke als Zweck von Custom Skills: ein gebündelter, aufrufbarer Anweisungssatz, der sich ohne erneutes Einfügen in jeden Prompt einklinkt. (Figma Release Notes im Überblick, Mai 2026)

Nach dem Aufbau des folgenden Skill-Pakets ließ ich dasselbe Briefing noch einmal durch Make laufen. Schaltflächenradius: 8px. Akzent: #06B6D4. Fließtext: 16px. Der Skill machte Make nicht intelligenter – er sorgte dafür, dass die Regeln nicht mehr in Vergessenheit gerieten.

Das Briefing – was das Designsystem des Kunden tatsächlich verlangt

Der hier verwendete Entwurf basiert auf dem System eines realen Kunden. Die Tokens wurden bereinigt:

• Farbe: Hintergrund #0A0E14, Vordergrund #E6EDF3, ein einziger Akzent #06B6D4. Kein zweiter Akzent. Keine Verläufe.
• Abstände: 8px als Basis. Zulässige Skala: 8 / 16 / 24 / 40. Keine Zwischenwerte und nichts außerhalb dieser Skala.
• Typografieskala: 14 / 16 / 20 / 32 / 48. Fließtext hat 16. Keine 18.
• Radius: 8px auf jeder interaktiven Fläche. 0 auf Karten. Ohne Ausnahme.
• Schaltfläche: eine Komponente mit drei Zuständen – Standard, Hover, deaktiviert. Der Akzent füllt den Standardzustand; deaktiviert erscheint die Vordergrundfarbe mit 30% Deckkraft.

Ein allgemeiner Prompt wie „follow our brand“ scheitert an jeder dieser Vorgaben, weil Adjektive Interpretationsspielraum lassen. „Cool, minimal, single-accent“ könnte tausend Systeme beschreiben. Das Modell braucht kein Moodboard, sondern die Tabelle. Ziel ist, jeden Make-Build für diesen Kunden gegen diese Tabelle zu prüfen, ohne sie in jeder Sitzung erneut eingeben zu müssen.

Das 3-Skill-Paket – die tatsächlichen .md-Dateien

Custom Skills in Figma Make sind einzelne Markdown-Dateien nach der Agent Skills Specification. Der Frontmatter-Wert name wird zum Slash-Befehl. Die Skills werden pro Account installiert, bleiben in allen eigenen Make-Dateien verfügbar und müssen – wichtig – vollständig eigenständig sein: keine Verzeichnisse namens scripts/, references/ oder assets/. Alles, was das Modell benötigt, steht direkt in den Anweisungen. (Custom Skills für Figma Make, Figma-Hilfe)

Drei Skills decken 90% dessen ab, was ich zuvor immer wieder neu eingegeben habe.

/follow-ds-guidelines

Die wörtliche Token-Tabelle als Anweisung. Keine Interpretation, keine Adjektive.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

Der Review-Skill. Make prüft den aktuellen Frame gegen die Token-Tabelle und liefert eine Pass/Fail-Liste, in der problematische Hex- und Pixelwerte explizit genannt werden.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

Der Beispieldaten-Skill fügt ausschließlich vom Kunden freigegebene Platzhaltertexte ein. Damit landen weder Lorem ipsum noch vom Modell erfundene Firmennamen in Review-Builds, die später von der Rechtsabteilung beanstandet werden. (Release Notes im Überblick, Mai 2026)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

Drei Dateien. Jede ersetzt einen Inhalt, den ich früher immer wieder neu eingefügt habe.

Den Notion-Connector anbinden, damit der Skill das aktuelle System liest

Der Ansatz mit statischen Tokens in /follow-ds-guidelines funktioniert bei einem eingefrorenen System. Sobald der Kunde ein Token ändert – und das wird passieren –, veraltet die eingebettete Tabelle. Die Lösung ist ein Connector, über den Make die aktuelle Quelle abruft. (Connectors in Figma Make, Figma-Hilfe)

In der Datei dieses Kunden liegt das Designsystem auf einer einzigen Notion-Seite mit denselben Überschriften wie der Skill: Color, Spacing, Type ramp, Radius, Button. Skill und Connector werden im selben Prompt aufgerufen.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

Auf dieselbe Weise kann derselbe Prompt ein PRD aus Drive laden – @Drive "Halcyon pricing PRD" – und Make führt Designsystem- und Spezifikationskontext in einem Schritt zusammen. (Release Notes im Überblick, Mai 2026)

Meine Abwägung je Kunde: Inline-Tokens für Systeme, die sich seit einem Quartal nicht verändert haben; Connector-Daten für Systeme, die noch in Bewegung sind. Die Skill-Datei .md bleibt in beiden Fällen gleich – nur der Prompt ändert sich. Das ist Absicht. Statt eines ausufernden eigenen Skills für jeden Kunden soll ein einziger Skill gezielte Überschreibungen verstehen.

Zur Einordnung: Der Skill /prototype-to-figma des Figma MCP Servers gehört zu einer anderen Oberfläche. Er ist für Code-to-Canvas-Rundläufe vorinstalliert und wird nicht selbst erstellt. Custom Make Skills funktionieren umgekehrt: Sie werden selbst geschrieben, leben in Make und berühren die MCP-Ebene nicht.

Wo es hakte – Nichtdeterminismus und der Preis des Teilens

Drei Dinge ließ die Ankündigung aus.

Die Modellabdeckung ist enger, als die Dokumentation vermuten lässt. Custom Skills laufen derzeit nur mit dem Standardmodell von Figma Make und Claude Opus 4.7. Hat ein Team in Make ein anderes Modell als Standard festgelegt, wird der Skill nicht angewendet. Eine deutliche Fehlermeldung gibt es nicht – die Durchsetzung bleibt einfach unbemerkt aus. (Custom Skills für Figma Make, Figma-Hilfe) Bei einem Team-Build ist das mein erster Prüfpunkt, noch bevor die Fehlersuche rund um „why is the radius wrong again.“ beginnt.

Die Ergebnisse sind „very often“ konsistent, aber nicht identisch. Genau so formuliert es Figma in der eigenen Dokumentation. Weil das Modell nicht deterministisch arbeitet, übersieht /design-crit bei einem komplexen Frame gelegentlich eine Abweichung oder markiert eine bewusste Ausnahme. (Custom Skills für Figma Make, Figma-Hilfe) Für mich ist der Crit-Skill deshalb ein schneller erster Durchlauf, keine Freigabe.

Der Aufwand beim Teilen ist das eigentliche Betriebsproblem. Custom Skills sind derzeit an einzelne Accounts gebunden. Um das Paket an Teammitglieder weiterzugeben, werden die .md-Dateien exportiert und anschließend in deren jeweilige Accounts hochgeladen. Eine Veröffentlichung auf Organisationsebene gibt es nicht. (Custom Skills für Figma Make, Figma-Hilfe) Für ein Studio mit mehreren Kundensystemen erzeugt das echte Reibung: Jedes neue Teammitglied muss jeden aktiven Skill manuell installieren, und jedes Update erfordert einen neuen Export. Die Gegenmaßnahme ist unspektakulär, funktioniert aber: Die .md-Dateien im Kunden-Repository versionieren – bei uns liegen sie im selben Monorepo direkt neben den Design-Tokens –, Releases taggen und den Upload aus einer eindeutigen Quelle statt aus einer Slack-Nachricht speisen.

Für Designer, die auf Plattformen mit solchen Mehrkosten pro Arbeitsplatz arbeiten, gilt dieselbe Studio-Ops-Perspektive wie bei meiner Analyse zur Kalkulation der Webflow-Premiumtarife: Die Tools berechnen die sichtbare Oberfläche, bezahlt wird die Integrationsreibung darunter.

Das Fazit – was in einen Skill gehört und was menschlich bleibt

Nach einigen Wochen damit bei DVNC.studio gilt für mich eine einfache Regel: Alles, was ich mehr als zweimal neu eingegeben habe, gehört in einen Skill. Token-Tabellen, Crit-Checklisten, Konventionen für Beispieldaten, Standardtexte für Barrierefreiheitsannotationen. Nichts davon ist kreativ. Alles davon war Zusatzaufwand.

Menschlich bleibt die Entscheidung. /design-crit markiert einen systemfremden Wert, entscheidet aber nicht, ob es sich um einen Fehler oder eine bewusste Ausnahme für eine einmalige Marketingfläche handelt. Der Skill beherrscht „this radius is 12, expected 8.“ Er beherrscht nicht „this radius is 12 because the campaign concept needed a softer card and we agreed it on Tuesday.“ Genau dieses Urteil ist die eigentliche Arbeit.

Der konkrete Schritt für nächsten Dienstag: das meistgenutzte Kundensystem auswählen, eine .md-Datei öffnen und die Token-Tabelle so einfügen wie oben bei Halcyon. Als follow-ds-guidelines.md speichern, als Custom Skill hochladen, einen echten Build damit ausführen und anschließend /design-crit auf das Ergebnis anwenden. Danach das Resultat von Hand mit der Token-Tabelle vergleichen. Erkennt der Skill dieselben Fehler wie die manuelle Prüfung, spart er pro Kunde und Woche eine Stunde wiederholtes Prompting. Übersieht er etwas Offensichtliches, liegt die Korrektur in der .md-Datei – nicht im Prompt-Verlauf.