← Zurück zum Journal

Warum wir Open Design als Skill-Schicht gebaut haben, nicht als Produkt

Die meisten KI-Design-Tools versuchen, den Agenten zu ersetzen, der bereits auf deinem Laptop läuft. Open Design setzt auf das Gegenteil: eine dünne Schicht aus Skills, Systemen und Adaptern ausliefern, die jeden Coding-Agenten in eine Design-Engine verwandelt — ohne dich in eine neue App zu sperren.

Warum wir Open Design als Skill-Schicht gebaut haben, nicht als Produkt

Der stärkste Coding-Agent auf deinem Laptop ist gerade Claude, Codex, Cursor, Gemini, OpenCode oder Qwen. Wir glauben nicht, dass du noch einen weiteren brauchst. Was fehlt, ist nicht rohe Intelligenz — es sind Geschmack, Struktur und ein Workflow, der Design als Handwerk respektiert.

Open Design ist unser Versuch, genau diese fehlende Schicht zu liefern. Es ist kein Chat-Produkt. Es ist kein Design-Tool, das „unter der Haube KI nutzt“. Es ist eine dünne Skill-Schicht — ein Ordner mit SKILL.md-Dateien, eine portable Bibliothek von Design-Systemen und ein daemon, der deine vorhandenen CLI-Agenten automatisch erkennt und miteinander verdrahtet.

Dieser Beitrag erklärt, warum wir diese Entscheidung getroffen haben, was sie dafür bedeutet, wie du Open Design nutzen wirst, und warum „Schicht, nicht Produkt“ eine Wette auf Langlebigkeit ist statt einer Abkürzung.

Ein Produkt hätte die falsche Form

Der erste Impuls, wenn man 2026 ein KI-Design-Projekt startet, ist es, eine neue App zu bauen: ein Chat-Interface, eine Canvas, ein Abrechnungssystem, eine Modellrechnung, die linear mit der Nutzerzahl wächst. Wir haben diesen Weg erwogen und ihn aus drei Gründen verworfen.

Das Chat-Interface ist eine Massenware

Jeder Nutzer hat bereits einen leistungsfähigen Agenten und ein Chatfenster, dem er vertraut. Ein schlechteres hinzuzufügen — verpackt in unsere Marke, ohne das Muskelgedächtnis, das sie aufgebaut haben — hilft niemandem. Das Interface ist nicht der Ort, an dem der Wert liegt. Der Wert liegt in dem, was der Agent tut, nachdem du Enter gedrückt hast: ob er ein Deck erzeugt, das gestaltet aussieht, oder eine Wand aus Divs.

Die Modellrechnung ist eine Steuer auf Kreativität

Bündelt man die Inferenz ins Produkt, zwingt einen die Ökonomie zum Handeln. Du musst die Tokens mit Aufschlag verkaufen, lange Sitzungen drosseln und den Zugang zu den neuesten Modellen rationieren, damit deine Marge überlebt. Jeder dieser Schritte bestraft genau das Verhalten, das ein Design-Tool belohnen sollte: iterieren, erkunden und den Agenten erneut laufen lassen, weil die dritte Fassung der Punkt ist, an dem die Arbeit gut wird.

Lock-in ist die falsche Voreinstellung

Designer sollten gehen können, ohne dass ihre Dateien, ihre Systeme und ihre Skills Schaden nehmen. Ein Produkt verpackt alles in proprietären Zustand — exportiere es, und du erhältst einen flachgedrückten Schatten des Originals. Eine Skill-Schicht hat nichts zu verpacken, denn die Artefakte sind die Dateien. Das Gehen kostet nichts, und genau deshalb bedeutet das Bleiben etwas.

Also haben wir stattdessen die Schicht gebaut. Lege einen Ordner ab, starte den daemon neu, der Skill erscheint. Nimm den Ordner mit, lege ihn in einen anderen Agenten — und der Skill funktioniert auch dort.

Was ein Skill tatsächlich ist

Ein Skill in Open Design ist eine SKILL.md-Datei plus optionale unterstützende Assets im selben Ordner. Die Markdown-Datei beschreibt:

  • Was der Skill tut — ein Absatz, in klarer Sprache
  • Wann er aufzurufen ist — die Auslösebedingungen, so geschrieben, dass der Agent korrekt routen kann
  • Die Form der Ausgabe — HTML, PDF, Folien, ein Markdown-Briefing
  • Die Vorgaben — Palette in OKLch, Font-Stack, Layout-Haltung, Markenvokabular

Der Agent liest die Datei, entscheidet, ob er sie aufruft, und schreibt die Ausgabe auf die Festplatte. Es gibt kein Plugin-System, keine API-Oberfläche, keine Versions-Kompatibilitätsmatrix. Wenn du Markdown schreiben kannst, kannst du einen Skill ausliefern.

Anatomie eines Skills

Konkret ist ein Skill ein Verzeichnis, das der daemon beim Start entdeckt:

skills/
  magazine-poster/
    SKILL.md          # the contract: trigger, output shape, constraints
    examples/
      launch.html     # a known-good artifact the agent can pattern-match

Das SKILL.md-Front-Matter benennt den Skill und seine Trigger; der Textkörper ist Anleitung, die der Agent wie ein Briefing liest. Nichts registriert den Skill außer seiner Präsenz auf der Festplatte — kein Manifest, das man hochzählen muss, kein Build-Schritt, keine Review-Warteschlange.

Warum Dateien Plugins schlagen

Das ist Absicht. Wir haben fünfzehn Jahre lang zugesehen, wie Plugin-Ökosysteme verfallen — jedes ein Kompromiss zwischen Ausdrucksstärke und Langlebigkeit, bei dem keine von beiden gewinnt. Ein Plugin ist eine Momentaufnahme der API von jemandem in einem bestimmten Jahr; die Laufzeit bewegt sich, die API bricht, und der Workflow, auf den du angewiesen warst, ist weg. Dateien brechen nicht. Eine heute geschriebene SKILL.md liest sich für einen Agenten in zwei Jahren exakt gleich — und für einen Menschen ganz ohne Werkzeuge ebenso.

Ein einzelnes Markdown-Dokumentblatt mit einfachen Textzeilen, ausgewählt in einem grünen Rahmen auf einem fast weißen redaktionellen Grund
Ein Skill ist einfach nur eine Datei — schlichtes Markdown, das ein Agent liest, kein Feature, das in einem Produkt eingeschlossen ist.

Warum auch Systeme Markdown sind

Open Design liefert Dutzende von Design-Systemen aus — Linear, Vercel, Stripe, Apple, Cursor, Figma und mehr — als DESIGN.md-Dateien. Dieselbe Idee: portabel, lesbar, für Agenten verarbeitbar.

Ein Design-System ist in diesem Kontext keine Figma-Bibliothek. Es ist ein Vertrag:

## 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.

Der Agent liest den Vertrag und produziert Arbeit, die ihn respektiert — Farben in OKLch, damit sie wahrnehmungsmäßig gleichmäßig bleiben, eine Typo-Rampe, von der er nicht abweicht, eine Layout-Haltung, die zehn generierte Screens wie ein einziges Produkt wirken lässt.

Mischen, forken und besitzen

Weil ein System einfach nur Text ist, kannst du eines forken und an Ort und Stelle bearbeiten, eine Variante ausliefern oder in dreißig Minuten dein eigenes von Grund auf schreiben. Du kannst Systeme sogar mitten im Projekt mischen — die Typografie von Linear ziehen, die Farblogik von Vercel, das Layout aus einer eigenen internen Spezifikation — denn es steht kein Binärformat zwischen dir und den Regeln. Die vollständige Mechanik, wie Skills und Systeme sich zusammensetzen, behandelt 31 skills, 72 systems: how the Open Design library works.

BYOK ist das einzig ehrliche Modell

Open Design läuft nach dem Prinzip bring-your-own-key. Du fügst eine Basis-URL und einen API-Schlüssel für einen beliebigen OpenAI-kompatiblen Endpunkt ein — DeepSeek, Groq, OpenRouter, dein eigenes selbst gehostetes vLLM — und fertig:

OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…

Wir betreiben keine Inferenz. Wir nehmen keine Marge auf Tokens. Wir haben keine Abrechnungsbeziehung mit dir. Das ist kein Nachhaltigkeitsproblem — es ist die einzig ehrliche Antwort auf die Frage „Wer zahlt, wenn der Agent läuft?“

Datenschutz ergibt sich aus derselben Entscheidung

Weil der daemon den Anbieter direkt von deiner Maschine aus aufruft, durchlaufen deine Prompts niemals unsere Server. Es gibt keinen Proxy, der sie protokolliert, keine Analyse-Pipeline, die im Stillen deine unveröffentlichte Arbeit aufbewahrt. Für Agenturarbeit oder alles unter NDA wird aus „Wo läuft das?“ keine Beschaffungsdiskussion mehr, sondern eine Einstellung. Die tiefer liegenden Abwägungen — und die rauen Kanten, die es noch gibt — stehen im BYOK Reality Check.

Die Antwort auf die Frage, wer zahlt, lautet: du, direkt, an den Modellanbieter, den du gewählt hast. Wir gehen aus dem Weg.

Was das für dich bedeutet

Wenn du ein poliertes SaaS mit einem hübschen Chatfenster und einem einzigen Abonnement willst, sind wir nicht das richtige Tool. Es gibt gute Produkte dieser Form — nutze sie.

Wenn du einen Workflow willst, in dem:

  • der Agent, dem du bereits vertraust, die Arbeit erledigt,
  • die Skills Dateien sind, die du lesen und bearbeiten kannst,
  • die Design-Systeme über Projekte und Agenten hinweg portabel sind,
  • und die Rechnung an den Modellanbieter geht, nicht an uns —

dann ist Open Design für dich gebaut. Spring ins GitHub-Repo, führe pnpm tools-dev aus, richte deinen Agenten auf einen Skill und liefere aus.

Die Skill-Schicht gewinnt, weil sie nicht mit dem Agenten auf deinem Laptop konkurriert. Sie erweitert ihn.

Weiterführende Lektüre


← Zurück zum Journal GitHub · Quelle ↗