OpenDesign: Open Design: eine lokale Design-Engine auf Basis Ihrer Coding-Agenten

Eine Open-Source-Antwort auf einen geschlossenen Design-Loop

Open Design ist ein TypeScript-Projekt, das das Repository als Open-Source-Alternative zu Anthropics Claude Design beschreibt. Es ist als lokale, native Desktop-App für macOS und Windows positioniert, die die bereits auf einem Rechner vorhandenen Coding-Agenten in eine Design-Engine verwandelt. Das Projekt liefert keinen eigenen Agenten mit, sondern setzt auf Claude Code, Codex, Cursor, Copilot und etwa zwei Dutzend weitere CLI-Executables oder auf jeden OpenAI-kompatiblen Endpunkt über einen Bring-Your-Own-Key-Proxy. Das README fasst den Unterschied so: Ein geschlossener, nur in der Cloud laufender Loop wird ersetzt durch ein Dateisystem aus Skills, Design-Templates, Design-Systemen und Plugins, das diese Agenten lesen, schreiben und neu mischen können.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 1 betrifft dabei genau diese Projektfunktion.

Was das Studio erzeugt

Im Studio eines Projekts speist ein Design-System mehrere Artefakttypen. Prototypen sind einseitige HTML-Dateien, die in einem Sandbox-iframe gerendert und als Quelle heruntergeladen werden können. Live-Dashboards und Decision Rooms bieten ein Tweaks-Panel, und der Agent erzeugt ein Manifest, sodass der iframe ohne Neuladen neu rendert. Decks blättern wie eine Präsentation und exportieren als PPTX oder PDF. Bilder werden in hoher Auflösung erzeugt, und Video kommt über HyperFrames, beschrieben als Heygens Open-Source-Framework für agenten-native Arbeit, das HTML, CSS und GSAP über Headless Chrome und FFmpeg in ein deterministisches MP4 rendert. Das README nennt HTML, PDF, PPTX, MP4, ZIP und Markdown als Exportpfade, mit einer Beispielspezifikation von 1920 mal 1080 bei 30 Bildern pro Sekunde für HyperFrames.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 2 betrifft dabei genau diese Projektfunktion.

Installation in einen Coding-Agenten

Der dokumentierte Weg in einen Coding-Agenten ist ein einzelner Befehl: od mcp install <agent>, der einen stdio-MCP-Server in die Konfiguration des Zielagenten einklinkt. Die Kompatibilitätstabelle listet 17 unterstützte Agenten auf, von Claude Code und Codex über Cursor, Copilot, OpenClaw, Kimi bis Mistral Vibe, dazu ein --print-Flag für den Probelauf und ein --uninstall-Flag. Unter macOS kann das Systemprogramm od, ein Oktal-Dump-Dienstprogramm, die Open-Design-Binärdatei überdecken, daher verweist das README Desktop-App-Nutzer auf einen Snippet im Einstellungsbereich, der absolute Pfade verwendet. Auf open-design.ai gibt es außerdem ein gehostetes Installationsskript für curl-basierte Setups, beschrieben als dünner Wrapper um denselben Befehl.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 3 betrifft dabei genau diese Projektfunktion.

DESIGN.md als Markenvertrag

Die Design-System-Idee baut auf DESIGN.md auf, einem Markdown-Vertrag, den jeder Renderlauf als Markenspezifikation liest. Das Repository enthält 151 Design-System-Pakete: Ältere können nur diese Datei enthalten, neuere können manifest.json, kompiliertes tokens.css, Komponenten-Fixtures, Assets und Herkunftsnachweise ergänzen. Das README beschreibt einen Workflow, in dem ein Designer einen Screenshot oder eine URL ablegt und der Agent ein wiederverwendbares DESIGN.md kodifiziert, das dann alle Ausgaben prägt. Der Katalog ist nach Kategorien organisiert: AI- und LLM-Tools, Entwicklerwerkzeuge, Fintech, E-Commerce, Medien und Automobilmarken. Wechselt man das System, verwendet der nächste Renderlauf die neuen Tokens.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 4 betrifft dabei genau diese Projektfunktion.

Plugins, Skills und Templates

Die Erweiterbarkeit ist in vier Ebenen gegliedert: Plugins tragen ausführbare Workflows, funktionale Skills tragen Agentenverhalten, Design-Templates tragen Rendering-Blaupausen und Design-Systeme tragen die Marke. Das README zählt über 100 funktionale Skills im Skills-Verzeichnis, einen eigenen Rendering-Template-Katalog mit den Modi prototype und deck als Anker sowie 277 offizielle Plugins und 183 remixbare Referenzbeispiele im Plugins-Verzeichnis. Ein Plugin ist ein portables Verzeichnis, das durch ein open-design.json-Manifest verankert ist; für Agent-Skill- und Szenario-Einträge ist SKILL.md erforderlich. Das README dokumentiert Scaffold- und Validierungsbefehle und beschreibt einen Veröffentlichungsfluss für Community-Ordner und externe Registries.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 5 betrifft dabei genau diese Projektfunktion.

Sicherheitsmodell und SSRF-Schutz

Das README beschreibt ein Sicherheitsmodell, in dem der Daemon standardmäßig schreibgeschützt ist, an 127.0.0.1 bindet und Server-Side-Request-Forgery am Proxy-Rand blockiert. LAN-Exposition erfordert einen expliziten Bind-Host und eine Allowed-Origins-Variable; Connector-Anmeldedaten und Live-Artefakt-Vorschaurouten bleiben stets Loopback-only. Intern gehostete Model-Endpunkte wie LiteLLM oder Ollama auf einer privaten Adresse können über eine Umgebungsvariable auf eine Allowlist gesetzt werden, die nackte Hostnamen oder IPs akzeptiert; die Liste ist strikt, hostgenau und standardmäßig leer. Ein fehlerhafter Eintrag wird mit einer Warnung verworfen, und der Schutz für Download-URLs in Upstream-Antworten bleibt blockiert, selbst wenn ein Provider-Host auf der Liste steht.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 6 betrifft dabei genau diese Projektfunktion.

Architektur und Roadmap-Stand

Das Architekturdiagramm zeigt ein Next.js-16-Browser-Frontend oder eine Electron-Shell, die mit einem lokalen Express-Daemon auf SQLite-Basis kommuniziert, mit einem Proxy-Pfad für OpenAI-kompatible Endpunkte und einem MCP-stdio-Server. Der Daemon startet Coding-Agenten-CLIs in einem verwalteten Projektarbeitsverzeichnis. Die Roadmap markiert die Versionen 0.8.0 bis 0.13.0 als veröffentlicht, darunter Plugin-Marktplatz, offizieller Cloud-Modellservice, ein All-in-One-Design-Workspace, ein Community-Marktplatz, markengestützte Design-Systeme und Sitzungswiederaufnahme. Chirurgische Bearbeitungen im Kommentarmodus sind teilweise veröffentlicht; die Tweaks-Panel-UX, ein npx-od-init-Scaffold und eine Plugin-SDK-CLI fehlen noch. Das Repository ist unter Apache-2.0 lizenziert; der Lizenzauszug gewährt Urheber- und Patentrechte für Nutzung, Vervielfältigung und Verbreitung, sagt aber nichts zu Gewährleistung, Support oder Sicherheitsgarantien.

Bei OpenDesign ist dieser Abschnitt mit dem konkreten Prüfpunkt DESIGN.md verbunden. Für eine erste lokale Prüfung eignet sich npm install; dabei sollte genau beobachtet werden, ob die im README beschriebene Ausgabe und der erwartete Dateipfad zusammenpassen. Das README belegt keine weitergehenden Leistungswerte, daher bleiben Durchsatz, Ressourcenbedarf und Verhalten unter eigener Last offene Fragen. Die Entscheidung sollte an diesem Projektmerkmal hängen und nicht an einer allgemeinen Versprechensliste. Abschnitt 7 betrifft dabei genau diese Projektfunktion.

Redaktionelles Fazit

OpenDesign passt zu Teams und Einzelpersonen, deren Arbeitsablauf genau auf die dokumentierten Eingaben, Ausgaben und Plattformen zugeschnitten ist. Nicht geeignet ist es für Erwartungen, die das README nicht belegt. Prüfe zuerst npm install, kontrolliere DESIGN.md und entscheide anhand des tatsächlichen Ergebnisses, der Abhängigkeiten und der Wartung im eigenen Umfeld.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes