31 Skills, 72 Systeme: So funktioniert die Open Design Bibliothek

Open Design besteht mechanisch betrachtet aus vier Primitiven, die übereinander gestapelt sind:

1. Skills — was der Agent tun soll
2. Systeme — wie das Ergebnis aussehen soll
3. Adapter — welcher Agent die Arbeit erledigt
4. Der daemon — die Schleife, die sie miteinander verbindet

Jedes Primitiv ist ein Ordner mit Dateien. Keines von ihnen erfordert eine Datenbank, eine Plugin-Runtime oder einen gehosteten Dienst. Das ist die ganze Bibliothek — es gibt kein fünftes Konzept, das sich hinter einer Login-Hürde versteckt. Dieser Beitrag geht jedes der Primitive der Reihe nach durch und zeigt, was passiert, wenn man seinen Agenten auf ein echtes Briefing ansetzt. Wer das Argument dafür sucht, warum wir es so geformt haben, bevor es um das Wie geht, beginnt am besten mit warum wir Open Design als Skill-Schicht gebaut haben, nicht als Produkt.

Skills: die Einheit der Fähigkeit

Ein Skill ist ein Ordner, der eine SKILL.md und null oder mehr unterstützende Dateien enthält. Die Markdown-Datei ist der Vertrag des Agenten — alles andere im Ordner ist dazu da, dem Agenten zu helfen, ihn zu erfüllen.

Anatomie eines Skill-Ordners

Ein typischer Skill sieht so aus:

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md deklariert den Namen des Skills, die Auslösebedingungen, die Form der Eingabe, die Form der Ausgabe und etwaige eingebettete Hinweise für den Agenten. Die Ordner templates/ und examples/ sind optional, leisten aber viel: Beispiele sind als gut bekannte Artefakte, an denen der Agent sich orientieren kann, und das macht den Unterschied zwischen „bau mir ein Deck“, das etwas Kohärentes hervorbringt, und etwas Improvisiertem.

Das Front Matter ist der Teil, den der daemon liest, um den Skill zu registrieren; der Body ist der Teil, den der Agent liest, um ihn auszuführen:

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

Warum die Datei das Register ist

Wenn der daemon startet, scannt er skills/ und registriert jeden Ordner, der eine SKILL.md enthält. Es gibt kein Plugin-Manifest. Es gibt kein Versionsfeld. Es gibt keinen Upload-Schritt, keine Review-Warteschlange, keinen Build. Es gibt die Datei, und die Datei ist die Quelle der Wahrheit. Leg einen neuen Ordner hinein, starte den daemon neu, und der Skill erscheint im Picker. Lösch ihn, und er ist weg — kein verwaister Registereintrag, der auf Code zeigt, der nicht mehr existiert.

Wir liefern derzeit 31 Skills aus. Manche sind Deck-Generatoren, manche erzeugen Mobile-Mockups, manche bauen redaktionelle Seiten, manche schreiben Office-Dokumente (Word, Excel, PowerPoint). Jeder davon ist ein Ordner, den du forken, bearbeiten oder ersetzen kannst. Weil der Vertrag reiner Text ist, sind „einen Skill schreiben“ und „einen Skill lesen, um zu verstehen, was er tut“ ein und dieselbe Tätigkeit — du prüfst ihn, indem du ihn öffnest.

Systeme: die Einheit des Geschmacks

Wenn ein Skill beschreibt, was zu erstellen ist, beschreibt ein System, wie es aussehen soll. Ein System ist eine DESIGN.md-Datei plus optionale Referenz-Assets. Es beschreibt eine visuelle Identität in maschinenlesbarer Form:

• Farbe — OKLch-Werte für Vordergrund, Hintergrund, Akzent, Fehler und so weiter
• Schrift — Font-Stack, Schriftstärken, die Typo-Skala, Zeilenhöhen-Konventionen
• Raum — Basiseinheit, Abstandsskala, Container-Breiten, Spaltenabstands-Regeln
• Layout-Haltung — Raster-Entscheidungen, Asymmetrie-Regeln, Dichte-Präferenzen
• Stimme — Typografie der Worte: Tonfall, Wortschatz, Satzrhythmus

Eine DESIGN.md ist ein Vertrag, keine Komponentenbibliothek

In der Praxis liest sich eine DESIGN.md wie ein kurzes, dezidiertes Brand-Briefing, das ein Agent nicht missdeuten kann:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

Die Farben sind in OKLch, damit sie über helle und dunkle Flächen hinweg wahrnehmungsmäßig gleichmäßig bleiben; die Typo-Skala ist eine Leiter, von der der Agent nicht abdriftet; die Haltungsregeln machen den Unterschied zwischen zehn generierten Screens, die sich wie ein Produkt anfühlen, und zehn, die sich wie zehn verschiedene Praktikanten anfühlen. Der Agent liest dies einmal und respektiert es für den gesamten Auftrag.

Ein System ist keine Figma-Bibliothek. Es gibt keine Komponenten, keine Varianten, keine verschachtelten Instanzen, kein Binärformat, das zwischen dir und den Regeln steht. Es ist ein Vertrag, den jeder Agent lesen und jeder Mensch prüfen kann. Wir liefern 72 Systeme ab Werk aus, darunter portable Versionen von Linear, Vercel, Stripe, Apple, Cursor, Figma und einen langen Schwanz redaktioneller und Marken-Systeme.

Mischen, forken, besitzen

Weil ein System nur Text ist, kannst du eines forken und an Ort und Stelle bearbeiten, eine Variante ausliefern oder in etwa 30 Minuten konzentrierter Arbeit dein eigenes von Grund auf schreiben. Du kannst Systeme sogar mitten im Projekt mischen — Typografie von Linear, Farblogik von Vercel, Layout aus einer hauseigenen Spezifikation — weil nichts in ein proprietäres Binärformat eingeschlossen ist. Die Trennung zwischen den Ordnern skills/ und design-systems/ ist gewollt: Fähigkeit und Geschmack sind orthogonal, also kann jeder Skill unter jedem System laufen, und jedes System kann jeden Skill antreiben.

Adapter: die Einheit des Agenten

Skills und Systeme sind inerter Text. Adapter sind die kleine Menge Code, die sie mit dem Agenten verbindet, der die Arbeit tatsächlich erledigt. Ein Adapter ist eine kurze TypeScript-Datei in adapters/, die weiß, wie man:

• erkennt, ob der Agent im $PATH des Nutzers installiert ist
• eine Sitzung mit diesem Agenten startet
• einen Skill-Aufruf hineinleitet
• die Ausgabe wieder einsammelt

Wir liefern heute Adapter für 12 Agenten aus: Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. Der daemon erkennt automatisch, welche vorhanden sind, und bietet sie beim ersten Start als Dropdown an — du konfigurierst nichts, du siehst einfach die Agenten, die du bereits hast.

Primitiv	Lebt in	Datei	Quelle der Wahrheit
Skill	skills/	SKILL.md	die Datei auf der Festplatte
System	design-systems/	DESIGN.md	die Datei auf der Festplatte
Adapter	adapters/	eine .ts-Datei	ein register()-Aufruf

Wenn du einen neuen Adapter hinzufügen willst, ist die Datei rund 80 Zeilen TypeScript und ein einziger register()-Aufruf. Kein SDK zu lernen, keine Berechtigung anzufordern, kein zentrales Register, an das man veröffentlichen muss. Derselbe Agent, dem du auf deinem Laptop bereits vertraust, wird zur Engine — Open Design ersetzt ihn nie. (Der Begleitbeitrag BYOK Design-Workflow zeigt, wie man einen Adapter auf den eigenen Schlüssel richtet.)

Der daemon: die Schleife, die alles zusammenbindet

Der daemon ist der einzige laufende Prozess im System. Es ist ein kleiner Node-Prozess, den du mit pnpm tools-dev startest, und er tut nacheinander vier Dinge:

1. Erkennen — scannt beim Start den $PATH nach installierten Agenten und skills/ nach installierten Skills
2. Erkunden — öffnet ein interaktives Frageformular, um Oberfläche, Zielgruppe, Tonfall, Maßstab und Markenkontext für das aktuelle Briefing festzulegen
3. Lenken — präsentiert 5 deterministische visuelle Richtungen (Palette in OKLch, Font-Stack, Layout-Haltungs-Hinweise) und bittet den Nutzer, eine auszuwählen
4. Liefern — ruft den ausgewählten Skill mit dem festgelegten System auf, lässt den Agenten auf die Festplatte schreiben und zeigt die Ausgabe in einem gesandboxten iframe als Vorschau

Die gesamte Schleife passt in rund 1500 Zeilen Code. Sie ist bewusst klein. Die Cleverness steckt in den Skills, nicht in der Runtime — die Aufgabe des daemon ist es, Ordner zu scannen, ein Briefing durch die vier Schritte zu leiten und sich herauszuhalten. Diese Kleinheit ist der Punkt: Es gibt hier sehr wenig, das verrotten kann, und fast nichts, das deine Arbeit als Geisel nehmen kann.

Wie es sich in der Praxis anfühlt

Angenommen, du willst ein Launch-Deck für eine neue Produktfunktion. So sieht der Ablauf aus:

1. Du führst pnpm tools-dev in einem Terminal aus. Der daemon startet auf localhost:7780.
2. Du öffnest die URL. Der daemon zeigt dir, welche Agenten er gefunden hat (z. B. Claude, Cursor, Codex).
3. Du wählst guizang-ppt aus der Skill-Liste.
4. Ein 30-Sekunden-Frageformular erscheint: Wer ist die Zielgruppe, wie ist der Tonfall, wie ist der Markenkontext.
5. Dir werden 5 visuelle Richtungen gezeigt — unterschiedliche Paletten, Schriftpaarungen, Layout-Haltungen. Du wählst eine aus.
6. Der Agent schreibt auf die Festplatte. Ein gesandboxtes iframe zeigt das Ergebnis. Du kannst nach HTML, PDF, PPTX, ZIP oder Markdown exportieren.

Verfolge es durch die Primitive zurück, und das Ganze ist lesbar: Schritt 3 wählte einen Skill, Schritt 5 legte ein System fest, der Agent dahinter kam über einen Adapter, und der daemon ließ die vierstufige Schleife laufen. Die Ausgabe ist echt. Die Dateien gehören dir. Du kannst sie in jedem Editor bearbeiten, sie einem Designer übergeben oder sie wieder in einen anderen Skill einspeisen.

Warum Dateien, keine Datenbank

Jedes Primitiv — Skills, Systeme, Adapter — ist ein Ordner mit Textdateien. Es gibt keine zentrale Datenbank. Es gibt kein „Open Design-Konto“. Es gibt keinen gehosteten Dienst, der weiterlaufen muss, damit deine Arbeit weiterläuft.

Das ist ein bewusster Kompromiss. Wir geben die Fähigkeit auf, clevere nutzerübergreifende Analysen, projektübergreifendes Gedächtnis oder gehostete Zusammenarbeit zu betreiben. Wir bekommen dafür: Portabilität, Langlebigkeit, Prüfbarkeit und die Möglichkeit für jeden, die gesamte Bibliothek zu forken und seine eigene Variante auszuliefern. Eine heute geschriebene SKILL.md liest sich für einen Agenten in zwei Jahren identisch wie für einen Menschen ganz ohne Tooling — dasselbe lässt sich nicht von einem Plugin sagen, das an die API des letzten Jahres gebunden ist.

Wenn du miterlebt hast, wie eine ganze Generation von Design-Tools gestorben ist und deine Dateien mitgenommen hat, wirst du verstehen, warum dieser Kompromiss es wert ist.

Weiterführende Lektüre

• Warum wir Open Design als Skill-Schicht gebaut haben, nicht als Produkt — die Wette hinter den vier Primitiven
• BYOK Design-Workflow: Claude, Codex oder Qwen mit dem eigenen Schlüssel betreiben — wie Adapter sich mit dem Agenten verbinden, für den du bereits zahlst
• Die Layout-Schicht, die die Canvas früher verbarg — warum Haltungsregeln in einer DESIGN.md das Ziehen von Boxen auf einer Canvas schlagen