diagram-design für Claude Code: stärkstes Diagramm-Skill

Eine Textbeschreibung wird zu einem hübschen Bild, aber die Beschriftungen stimmen nicht und jede Änderung beginnt von vorn.
Die schnellste Lösung ist diagram-design für Claude Code: Der Skill erzeugt selbstständige HTML-Dateien mit eingebettetem SVG, die Sie im Browser prüfen, im Quelltext ändern und anschließend als SVG oder PNG exportieren können.

Für wen lohnt sich dieser Leitfaden?

Dieser Artikel richtet sich an Entwickler und technische Autoren, die regelmäßig Architekturdiagramme, README-Abbildungen oder redaktionelle Grafiken erstellen. Auch Dokumentationsteams mit einer festen Farb- und Schriftvorgabe finden hier eine belastbare Entscheidungsgrundlage.

Wenn Sie nur gelegentlich eine schnelle Skizze auf einer virtuellen Tafel benötigen, ist diagram-design vermutlich zu technisch. Wenn Sie dagegen wiederverwendbare Diagrammquellen, nachvollziehbare Änderungen und eine einheitliche visuelle Sprache brauchen, ist der Skill deutlich interessanter.

Zuletzt aktualisiert: 14.08.2026. Die Angaben wurden anhand des offiziellen diagram-design-Repositorys, der dort dokumentierten Plugin-Befehle und der aktuellen Claude-Code-Dokumentation geprüft. Da sich Skills und Plugin-Installationen schnell ändern, sollten Sie die Befehle vor einem Rollout nochmals gegen den Standard-Branch kontrollieren.

diagram-design als Claude-Code-Skill

diagram-design ist kein eigenständiger Online-Dienst und kein klassischer Bildgenerator. Es handelt sich um einen Skill beziehungsweise ein Plugin für agentische Entwicklungswerkzeuge. Sie geben eine Beschreibung in natürlicher Sprache ein, etwa:

„Erstellen Sie ein Architekturdiagramm für eine Webanwendung mit Mobile-Client, API-Gateway, Authentifizierung, Hintergrundjobs und PostgreSQL. Zeigen Sie außerdem den Datenfluss und die externe Zahlungsanbindung.“

Claude Code analysiert diese Anforderung, wählt einen passenden Diagrammtyp und legt eine HTML-Datei an. Das Diagramm enthält typischerweise:

• HTML-Struktur für Titel, Legenden und redaktionelle Zusatzinformationen,
• CSS für Farben, Abstände und Typografie,
• ein eingebettetes SVG für Knoten, Pfeile, Beschriftungen und Linien,
• optionale Beschreibungen für Screenreader,
• eine Quelle, die Sie im Repository versionieren können.

Das offizielle Repository beschreibt derzeit 27 visuelle Typen und drei statische Varianten: hell, dunkel und „full-editorial“. Die genaue Zahl ist versionsabhängig und deshalb kein dauerhaftes Qualitätsversprechen. Entscheidend ist die Struktur: diagram-design erzeugt keine flache Bilddatei, sondern eine bearbeitbare Webgrafik. Quelle: README des offiziellen Repositorys

Ansatz	Eingabe	Ergebnis	Änderbarkeit	Typische Schwäche
diagram-design	Text, Quelltext oder bestehende Diagrammquelle	Selbstständiges HTML mit Inline-SVG	Hoch auf Datei- und Elementebene	Fachliche Aussagen müssen geprüft werden
Bildgenerator	Text oder Referenzbild	Rasterbild	Gering	Kleine Textfehler und unklare Geometrie
Mermaid-Syntax	Deklarative Diagrammsprache	Gerendertes Diagramm über Renderer	Gut im Quelltext, begrenzt im Layout	Redaktionelle Gestaltung und freie Positionierung
Freies Whiteboard	Manuelles Zeichnen	Visuelle Arbeitsfläche	Hoch während der Sitzung	Schlechter reproduzierbar und schwerer zu versionieren

Der Unterschied zu einer normalen KI-Bildgenerierung ist damit grundlegend: Bei diagram-design sind Text, Formen und Verbindungen Bestandteile eines Dokuments. Sie können einen Knotennamen in der HTML- oder SVG-Struktur ändern, ohne das gesamte Motiv neu erzeugen zu müssen.

Welche Diagramme passen zu welcher Aufgabe?

Für technische Inhalte ist nicht die größtmögliche Formenbibliothek entscheidend, sondern die passende Abstraktion. Ein Architekturdiagramm beantwortet eine andere Frage als ein Sequenzdiagramm. Wenn Sie den falschen Typ auswählen, kann auch ein sauber gerendertes Ergebnis die falsche Aussage vermitteln.

Aufgabe	Passender Diagrammtyp	Geeignet für	Prüfrisiko
Komponenten und Abhängigkeiten zeigen	Architekturdiagramm	Systemübersichten, Cloud- und Service-Strukturen	Fehlende oder erfundene Abhängigkeit
Schritte und Entscheidungen erklären	Flussdiagramm	Onboarding, Prozesse, Fehlerpfade	Zu viele Verzweigungen
Kommunikation über Zeit darstellen	Sequenzdiagramm	API-Aufrufe, Authentifizierung, Webhooks	Falsche Reihenfolge
Zustände und Übergänge erklären	Zustandsdiagramm	Jobs, Bestellungen, Sitzungen	Unklare Übergangsbedingungen
Datenobjekte verbinden	ER- oder Datenmodell	Tabellen, Entitäten, Beziehungen	Modellannahmen werden als Fakten gelesen
Rollen und Zuständigkeiten zeigen	Swimlane oder Organigramm	Freigaben, Support, interne Abläufe	Verantwortliche fehlen
Prioritäten visualisieren	Quadrant, Radar oder Balkendiagramm	Produktvergleich, Roadmap, Auswahl	Subjektive Werte wirken objektiv
Datenwege darstellen	Datenflussdiagramm	ETL, Agentenketten, Sicherheitsgrenzen	Sensible Datenwege werden übersehen

Die offiziell dokumentierten Typen umfassen unter anderem Architektur, Flowchart, Sequence, State Machine, ER-Modell, Timeline, Swimlane, Quadrant, Tree, Venn, Layers, Pyramid, Loop, Data Flow und Sicherheitsmatrizen. Prüfen Sie die Liste bei jeder größeren Version erneut, weil der Skill seine visuelle Grammatik erweitert. Diagrammtypen im Repository

Für technische Autoren ist besonders nützlich, dass ein Diagramm nicht zwingend an ein bestimmtes Framework gebunden ist. Eine selbstständige HTML-Datei lässt sich lokal öffnen, in eine Dokumentationsseite übernehmen oder als Ausgangspunkt für einen SVG-Export verwenden. Sie benötigen für die statische Vorschau keinen laufenden Diagramm-Renderer und keine externe Bilddatei.

Ausgabe	Geeigneter Einsatz	Vorteil	Vor der Veröffentlichung prüfen
HTML	Blog, README, interne Dokumentation	Selbstständig, browserfähig, leicht versionierbar	Schrift, mobile Breite, externe Font-Abhängigkeiten
SVG	Webseiten, Layoutsysteme, Vektorbearbeitung	Skalierbar und elementweise editierbar	viewBox, Textumbruch, Schriftlizenzen
PNG	Präsentationen, Social Cards, Vorschauen	Einfach weiterzugeben	Auflösung und Lesbarkeit bei kleiner Darstellung
PDF oder Browserdruck	Review, Archiv, Freigabe	Fixiertes Seitenformat	Seitenumbruch und abgeschnittene Elemente

Der Claude-Code-Workflow als eigentlicher Vorteil

Der Mehrwert von diagram-design liegt weniger in „Text zu Bild“ als in der Verbindung zwischen Projektdateien, Skill-Regeln und wiederholbaren Ausgaben. Claude Code kann auf Dateien im Arbeitsverzeichnis zugreifen, sofern Sie die entsprechenden Berechtigungen erteilen. Dadurch kann die Beschreibung eines Diagramms aus einer README, einer API-Spezifikation oder einer Architekturdatei entstehen.

Sie sollten jedoch nicht davon ausgehen, dass jede Anfrage automatisch den gewünschten Typ auslöst. Ein allgemeiner Satz wie „Mach daraus ein Diagramm“ lässt mehrere Interpretationen zu. Besser ist eine kurze, strukturierte Vorgabe:

Erstelle ein Sequenzdiagramm.
Zielgruppe: Backend-Entwickler.
Zeige nur den erfolgreichen Ablauf und den Timeout-Fall.
Beschrifte jede Verbindung mit HTTP-Methode und Zweck.
Ausgabe: selbstständiges HTML, danach SVG exportieren.

Claude Code arbeitet mit Sitzungs- und Dateiberechtigungen. Die offizielle Dokumentation unterscheidet unter anderem zwischen Plan-, manuellen und automatischeren Berechtigungsmodi. Für ein Repository mit vertraulichen Architekturinformationen empfiehlt sich zunächst ein lesender oder bestätigungsbasierter Modus. Berechtigungen und Modi in Claude Code

Erster Schritt: Installation prüfen

Das Repository dokumentiert aktuell zwei relevante Wege für Claude Code.

Plugin-Installation:

/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design

Lokale, editierbare Installation:

git clone git@github.com:cathrynlavery/diagram-design.git ~/code/diagram-design
ln -s ~/code/diagram-design/skills/diagram-design ~/.claude/skills/diagram-design

Die Plugin-Variante ist schneller, wenn Sie den Skill nur testen möchten. Die lokale Variante ist besser, wenn Ihr Team den Stil anpassen, Änderungen kontrollieren und die Installation reproduzierbar dokumentieren will. Nach der Installation sollten Sie Claude Code neu starten beziehungsweise die Plugins neu laden. Die Befehle können sich ändern; verwenden Sie deshalb das Installationskapitel im README als maßgebliche Referenz.

Zweiter Schritt: Projektregeln und Markenstil festlegen

Ein häufiger Fehler besteht darin, sofort ein Diagramm zu erzeugen und erst später über Farben, Schriftgrößen und Kontrast nachzudenken. Für eine einzelne Skizze ist das vertretbar. Für ein Blog- oder Dokumentationsteam führt es schnell zu einer uneinheitlichen Bildsprache.

diagram-design verwendet eine Style-Guide-Datei als zentrale Quelle für Farben und Schriftrollen. Sie können beispielsweise festlegen:

• Hintergrundfarbe für Dokument- und Diagrammfläche,
• Primärfarbe für wichtige Knoten,
• gedämpfte Farbe für Nebeninformationen,
• Schriftfamilie für Titel und Knoten,
• Akzentfarbe für den wichtigsten Pfad,
• Kontrastregeln für kleine Beschriftungen.

Die aktuelle Dokumentation beschreibt außerdem eine Onboarding-Funktion, die Farben und Schriftfamilien aus einer Website ableiten kann. Das ist ein hilfreicher Startpunkt, aber keine Designfreigabe. Eine abgeleitete Farbe kann im Diagramm bei kleiner Schrift anders wirken als auf einer Website mit größerem Text.

Dritter Schritt: Inhalt vor Layout validieren

Lassen Sie Claude Code nicht zuerst gestalten, sondern zuerst die fachliche Grundlage in einer Liste ausgeben. Für ein Architekturdiagramm sollte diese Liste mindestens enthalten:

1. reale Komponenten,
2. reale Kommunikationswege,
3. Datenrichtung,
4. Protokoll oder Schnittstellentyp,
5. externe Abhängigkeiten,
6. bekannte Unsicherheiten,
7. bewusst ausgelassene Details.

Erst danach sollte der Agent die Grafik zeichnen. So erkennen Sie leichter, ob eine Verbindung aus dem Quelltext stammt oder nur eine plausible Modellannahme ist.

Vierter Schritt: Diagramm erzeugen und im Browser öffnen

Bitten Sie Claude Code, die Datei mit einem eindeutigen Namen zu speichern, beispielsweise docs/architecture-auth.html. Öffnen Sie die Datei anschließend lokal im Browser. Prüfen Sie dabei nicht nur, ob sie „schön“ aussieht, sondern ob die Leserführung stimmt:

• Erkennt man den Startpunkt ohne Erklärung?
• Sind Haupt- und Nebenpfade unterscheidbar?
• Bleiben Beschriftungen bei schmalem Fenster lesbar?
• Sind Pfeile nicht unter Knotenflächen verschwunden?
• Ist die Legende kürzer als die eigentliche Aussage?
• Werden technische Abkürzungen erklärt?

Fünfter Schritt: SVG oder PNG exportieren

Für den Export dokumentiert das Repository aktuell Befehle wie:

/diagram-design:export docs/architecture-auth.html
/diagram-design:export docs/architecture-auth.html --svg-only
/diagram-design:export docs/architecture-auth.html --png-only --scale=3

Der SVG-Export extrahiert das SVG-Element aus der HTML-Datei. Für PNG wird laut Dokumentation eine Browser-Automatisierung verwendet; dafür kann eine zusätzliche Chromium-Installation erforderlich sein. Das bedeutet praktisch: HTML eignet sich für die webnahe Quelle, SVG für skalierbare Weiterverarbeitung und PNG für Systeme, die keine Vektorgrafik akzeptieren. Exportdokumentation im Repository

Sechster Schritt: Quelle, Ausgabe und Prüfung gemeinsam versionieren

Speichern Sie nicht nur das finale Bild. Legen Sie mindestens folgende Dateien ab:

docs/diagrams/
├── auth-architecture.html
├── auth-architecture.svg
├── auth-architecture-brief.md
└── review-notes.md

Im Brief sollte stehen, aus welchen Quellen das Diagramm erstellt wurde und welche Vereinfachungen vorgenommen wurden. In den Review-Notizen gehören fachliche Korrekturen, nicht nur Designänderungen. So kann ein späterer Bearbeiter unterscheiden, ob eine Position geändert wurde oder ob sich die Architektur tatsächlich verändert hat.

Für technische Autoren: Wo HTML und SVG besonders stark sind

Ein selbstständiges HTML-Diagramm eignet sich gut, wenn der Inhalt direkt neben erklärendem Text stehen soll. Sie können es in eine Dokumentationsstruktur übernehmen, lokal an Redakteure weitergeben und mit einer normalen Versionskontrolle prüfen. Das ist besonders nützlich für:

• Architekturüberblicke in Blogartikeln,
• Ablaufdarstellungen in API-Dokumentationen,
• interne Runbooks,
• Produktvergleiche mit nachvollziehbaren Kriterien,
• Schulungsunterlagen,
• technische Release-Notizen.

SVG ist sinnvoll, wenn Sie eine skalierbare Abbildung für mehrere Ausgabemedien benötigen. Trotzdem ist „vektoriell“ nicht automatisch „fertig“. Lange Knotenbezeichnungen, schmale Spalten und kleine Nebenbeschriftungen können in einem Desktop-Browser gut aussehen, auf einem Mobilgerät aber unlesbar werden.

Für Barrierefreiheit sollten Sie die SVG-Struktur kontrollieren. Das Repository dokumentiert zugängliche Namen und Beschreibungen mit role="img", aria-labelledby, <title> und <desc>. Diese Elemente sind hilfreich, müssen aber inhaltlich sinnvoll ausgefüllt sein. Ein <desc> wie „Systemdiagramm“ erklärt einer assistiven Technologie kaum etwas. Prüfen Sie daher, ob die Bildbeschreibung die Leserichtung, Hauptkomponenten und zentrale Beziehung nennt. Ergänzende Orientierung bietet die W3C-Dokumentation zu SVG-Barrierefreiheit.

Für Architekten und Engineering-Teams: Die Grenzen liegen beim Inhalt

diagram-design kann aus einer unvollständigen Beschreibung ein plausibles Diagramm erzeugen. Genau darin liegt das größte Risiko. Ein Agent kann eine typische Authentifizierung, eine angenommene Datenbankverbindung oder einen üblichen Queue-Verlauf ergänzen, obwohl diese Elemente in Ihrem System nicht existieren.

Teilen Sie die Prüfung deshalb in drei Ebenen:

Faktenprüfung: Ist jede Komponente real vorhanden? Stimmen Namen, Protokolle, Zuständigkeiten und Datenrichtungen?

Abstraktionsprüfung: Ist die Detailstufe für die Zielgruppe passend? Ein Entwicklerdiagramm darf technische Begriffe enthalten, eine Führungskräfteübersicht benötigt andere Beschriftungen.

Darstellungsprüfung: Unterstützt das Layout die Aussage oder suggeriert es eine falsche Hierarchie? Ein größer gezeichneter Knoten wirkt schnell wichtiger als ein kleiner Knoten, selbst wenn das nicht beabsichtigt war.

Bei bestehenden Mermaid- oder draw.io-Quellen kann diagram-design diese Inhalte neu zeichnen und auf ein anderes Format, eine andere Zielgruppe oder eine andere Detailstufe ausrichten. Das spart Layoutarbeit, bedeutet aber nicht, dass die Quelldatei automatisch korrekt ist. Dokumentation zum Import vorhandener Diagramme

Für Design- und Markenverantwortliche: Einheitlichkeit ist keine Freigabe

Die zentrale Style-Guide-Datei ist für Teams wertvoll, weil Farben und Schriften nicht in jedem Prompt neu erfunden werden müssen. Sie können einen visuellen Standard für mehrere Beiträge oder Produktbereiche definieren und Änderungen über Versionskontrolle nachvollziehen.

Beachten Sie jedoch drei Grenzen:

• Eine automatisch erkannte Schrift kann lizenzrechtlich nicht für jede Exportform freigegeben sein.
• Eine Markenfarbe kann bei kleiner Schrift den erforderlichen Kontrast verfehlen.
• Ein einheitlicher Stil kann eine inhaltlich überladene Grafik nicht retten.

Für veröffentlichte technische Inhalte sollten Sie außerdem klären, ob externe Schriftressourcen geladen werden dürfen. Bei vertraulichen Projekten ist eine vollständig lokale Ausgabe oft besser. Prüfen Sie Netzwerkzugriffe, Datenschutzanforderungen und die Weitergabe von Repository-Inhalten. Hinweise zu den Datenschutzinformationen von Kvmjet finden Sie in der Datenschutzerklärung.

Auswahl zwischen lokaler, entfernter und einmaliger Umgebung

Für einen einzelnen Diagrammversuch genügt häufig Ihr vorhandener Rechner. Eine dauerhaft laufende Umgebung wird interessant, wenn mehrere Autoren dieselben Skill-Dateien, Style-Regeln und Exportwerkzeuge benötigen.

Umgebung	Sinnvoll, wenn	Vorteil	Nachteil
Lokaler Mac	Sie allein arbeiten und vertrauliche Quelldateien lokal halten müssen	Direkter Zugriff, gute Vorschau, keine Übergabe	Abhängigkeit von einem einzelnen Gerät
Dauerhaft erreichbarer Remote-Mac	Mehrere Sitzungen, Teamzugriff oder feste Arbeitsumgebung nötig sind	Wiederholbare Umgebung und zentrale Pflege	Zugangsschutz, Benutzerverwaltung und laufende Kosten
Einmalige Umgebung	Sie nur einen kurzen Proof of Concept oder einen Export durchführen	Kein dauerhafter Betrieb erforderlich	Installation und Übergabe müssen jedes Mal geprüft werden

Bei der Auswahl zählen nicht nur Prozessorleistung oder Speicher. Prüfen Sie ebenso Dateirechte, SSH- oder Browserzugriff, Persistenz des Arbeitsverzeichnisses, Trennung von Projekten und Löschung sensibler Dateien. Für temporäre Aufgaben ist ein lokaler Rechner oft effizienter. Für wiederkehrende redaktionelle Abläufe kann ein dauerhaft erreichbarer Mac die Übergabe zwischen Autoren erleichtern.

Wenn Sie eine solche Umgebung nicht selbst verwalten möchten, vergleichen Sie zunächst die Anforderungen in der Übersicht zum Hilfe-Zentrum und klären Sie vorab, welche Zugriffs- und Löschregeln gelten. Für konkrete Umgebungsfragen können Sie außerdem den Kontakt zu Kvmjet nutzen.

FAQ zu diagram-design und Claude Code

Welche Diagramme kann diagram-design erzeugen?

diagram-design deckt mehr als einfache Kästchen-und-Pfeile-Grafiken ab. Je nach Projekt können Sie Architektur-, Flowchart-, Sequenz-, Zustands-, Datenmodell-, Zeitachsen-, Swimlane-, Quadranten-, Baum-, Ebenen-, Balken-, Linien-, Datenfluss- und Sicherheitsdiagramme anfordern. Die Auswahl hängt von der Aussage und nicht nur vom gewünschten Aussehen ab.

Wie verwendet man diagram-design in Claude Code?

Installieren Sie das Plugin über den dokumentierten Marktplatz oder verknüpfen Sie den Skill lokal mit ~/.claude/skills/diagram-design. Starten Sie danach eine neue Claude-Code-Sitzung und geben Sie Zielgruppe, Diagrammtyp, Datenquelle, Detailgrad und Ausgabeformat an. Für reproduzierbare Teamarbeit sollten Installationsweg und Version im Projekt dokumentiert werden.

Kann man die erzeugten Diagramme bearbeiten?

Ja. Die editierbare Grundlage ist die HTML-Datei mit CSS und Inline-SVG. Sie können Beschriftungen, Farben, Knoten, Pfeile und Abstände direkt im Quelltext ändern oder Claude Code mit einer präzisen Änderungsanweisung beauftragen. Für umfangreiche freie Layoutänderungen ist dennoch eine manuelle Vektorbearbeitung oft schneller.

Was unterscheidet diagram-design von normaler Bildgenerierung?

Ein normales KI-Bild ist in erster Linie eine Pixel- oder Rasterausgabe. diagram-design erzeugt dagegen strukturierte Webinhalte: HTML, CSS und SVG. Dadurch bleiben Texte und grafische Elemente nachvollziehbarer, können versioniert und in unterschiedliche Formate exportiert werden. Die Struktur verbessert die Bearbeitung, beseitigt aber nicht das Risiko falscher Inhalte.

Abnahme-Checkliste für den ersten Team-Rollout

• [ ] Ist der verwendete Repository-Stand dokumentiert?
• [ ] Ist geklärt, ob Plugin- oder lokale Installation verwendet wird?
• [ ] Wurde ein lesender beziehungsweise bestätigungsbasierter Berechtigungsmodus getestet?
• [ ] Sind echte Architekturquellen von Modellannahmen getrennt?
• [ ] Wurde für jedes Diagramm ein passender Typ ausgewählt?
• [ ] Sind Hauptpfade, Nebenpfade und externe Abhängigkeiten eindeutig beschriftet?
• [ ] Wurde die HTML-Datei lokal in mehreren Fensterbreiten geprüft?
• [ ] Wurde der SVG-Export in der vorgesehenen Zielanwendung geöffnet?
• [ ] Sind title, desc und alternative Beschreibung für zentrale Grafiken vorhanden?
• [ ] Wurden Schriftlizenzen und externe Ressourcen kontrolliert?
• [ ] Liegen Quelltext, Exportdatei und Review-Notizen gemeinsam im Projekt?
• [ ] Hat eine fachlich verantwortliche Person die Architektur freigegeben?
• [ ] Sind sensible Dateien, Sitzungsdaten und temporäre Exporte nach dem Test gelöscht?
• [ ] Ist entschieden, ob lokale Hardware oder eine entfernte Mac-Umgebung wirtschaftlicher ist?

Für die meisten Teams lautet die sinnvolle Reihenfolge: zuerst einen kleinen Architektur- oder Sequenzdiagramm-Test mit realen Projektdaten durchführen, danach die Style-Regeln festlegen und erst anschließend mehrere Autoren oder automatisierte Exporte anbinden.

Wenn Sie aktuell auf einzelnen Windows- oder Linux-Arbeitsplätzen arbeiten, entstehen in der Praxis oft drei Nachteile: unterschiedliche lokale Installationen, uneinheitliche Browser- und Exportumgebungen sowie schwer nachvollziehbare Berechtigungen für Projektdateien. Eine geteilte Remote-Umgebung löst diese Punkte nicht automatisch, kann aber bei wiederkehrenden Claude-Code-Aufgaben eine stabilere Basis schaffen. Für kurzfristige Tests, wechselnde Autoren oder isolierte Dokumentationsprojekte kann das Mieten eines Mac über Kvmjet sinnvoller sein als der Kauf zusätzlicher Hardware. Bei dauerhaft hoher Auslastung, speziellen physischen Schnittstellen oder strengen lokalen Datenanforderungen bleibt ein eigener Rechner die ehrlichere Wahl. Entscheidend ist, ob Sie nur einmal ein Diagramm exportieren oder eine reproduzierbare Arbeitsumgebung für viele Ausgaben betreiben möchten.