Drawio Visuals Skill

Was macht Drawio Visuals Skill?

Erstelle, rekonstruiere und bearbeite native, benutzerbearbeitbare Draw.io-Dateien ohne Server, MCP, feste Vorlage, Szenen-IR oder benutzerdefinierten Renderer.

Standardmäßig Objekte, nicht Textmodule

Für einen neuen erklärenden Fluss – einen Prozess, eine Pipeline, eine Swimlane, einen Anfragelebenszyklus oder einen Architekturfluss – verwende standardmäßig erkennbare bearbeitbare Objekte und sichtbare Änderungen. Eine einfache Anfrage wie „zeichne den Workflow“ aktiviert diese Regel; der Benutzer muss nicht nach „bildhaften“, „konkreten“ oder „illustrierten“ Grafiken fragen. Wähle den Diagrammtyp separat von dieser visuellen Behandlung.

Bevor du Knoten platzierst, identifiziere, was sich bewegt, was sich ändert und wer handelt. Wähle dann eine Silhouette, sinnvolle Inhalte oder eine kleine Objektszene für jedes Hauptgeschäftsobjekt und jede Verarbeitungsstufe: Eine Warteschlange hat separate Aufgabenkarten und einen Ein-/Auslass; ein Parser zeigt ein Dokument, das zu extrahierten Teilen wird; eine Rückerstattung unterscheidet zwischen ausstehenden und zurückgegebenen Mitteln. Zeichne diese nativen Teile zuerst, füge dann kurze Namen/Aktionen hinzu. Eine Reihe von Rechtecken, die Schrittnamen enthalten, erfüllt diese Vorgabe nicht, selbst wenn die Beschriftungen kurz sind und das Layout sauber ist. Wiederholte Server-Racks, Emojis oder ein nicht zusammenhängendes Symbol auf einer Prosa-Karte sind kein Ersatz für sichtbare Bedeutung. Lies visual-storytelling.md, bevor du diese Flüsse erstellst.

Beginne mit den gebündelten Grafiken: Konsultiere den Komponentenindex, lies das relevante .drawio-XML unter assets/components/ und entscheide, ob du seine nativen Nachkommen wiederverwenden, seine Teile anpassen/kombinieren oder seine Konstruktion als Referenz für die Generierung eines neuen nativen Objekts verwenden möchtest. Kombiniere Browser-, Dokument-, Nachrichten-, Warteschlangen-, Arbeiter-, Speicher-, Chunk-, Tabellen-, Vektor-, Prüfungs-, Entscheidungs- und Benachrichtigungsobjekte, wie es die Aufgabe erfordert. Zum Beispiel: Kombiniere Browser + Dokument → Speicher, dann separat Nachricht → Warteschlange → Arbeiter; schreibe diese Namen nicht einfach in Rechtecke. Die 12 Starter sind eine erweiterbare Samen-Bibliothek, keine vollständige Vorlage oder Fähigkeitsgrenze; wenn du ein zusätzliches Objekt generierst, leihe dir relevante Konstruktionsideen wie Silhouette, sinnvolle Inhalte, Statusmarkierungen, Verschachtelung und Verbindungsanschlüsse und passe sie dann an die Domäne an. Erzwinge nicht die Beispielpalette des Starters oder eine exakte Kopie.

Eingebaute Komponentensprache: Wenn du wiederverwendbare Assets unter assets/components/ hinzufügst, generierst oder wartest, halte jede Beschriftung, jedes Feld, jeden illustrativen Textwert, jeden Status, jeden Seitenamen und jeden Tooltip auf Englisch. Zahlen, Formeln und Symbole können so bleiben. Dies ist eine Bibliotheks-Autorenregel: Diagramme, die für Benutzer generiert werden, folgen weiterhin ihrer angeforderten/Quellsprache, wobei der Startertext entsprechend angepasst wird.

Ausnahmen folgen der Aufgabe, nicht der Bequemlichkeit: Bewahre die getreue Rekonstruktion, den Umfang einer lokalen Bearbeitung, eine explizite Text-nur/minimale-Box-Anfrage und die erforderliche formale Notation. Klassen-/ER-Kompartments, Sequenz-Lebenslinien, Entscheidungs-/Verzweigungs-/Verbindungssymbole und Zustandsgrenzen tragen echte Semantik; behalte sie bei. Eine allgemeine Anfrage nach einem „Flussdiagramm“, einem „einfachen“ Diagramm, fehlenden Startern oder der Verfügbarkeit von Mermaid ist keine Ausnahme. Erkläre Zustände mit sichtbaren Objektänderungen, wo dies möglich ist; ersetze keine formalen Beziehungen durch Bilder. Diese Vorgaben gelten für jede Seite und überleben Orientierungs-/Typenänderungen.

Kernregeln

• Behandle die aktuelle .drawio-Datei als die interne bearbeitbare Quelle der Wahrheit. Liefere standardmäßig nur PNG-Bilder pro Seite und eine HTML-Vorschau aus; behalte native Dateien in einem internen Arbeitsverzeichnis, außerhalb des Auslieferungsverzeichnisses, und verlinke sie nicht in der Übergabe. Liefere native Dateien, SVG, PDF oder andere Formate nur auf ausdrückliche Anfrage aus.
• Überschreibe niemals eine Eingabe. Jeder mechanische Schreibvorgang muss einen neuen Ausgabepfad verwenden, einschließlich interner Arbeitsdateien.
• Erzwinge kein Thema, keine Formliste, keinen Diagrammtyp, kein Koordinatengitter und kein Layoutrezept.
• Befolge den vom Benutzer angegebenen Diagrammtyp, die Notation und die Ausrichtung. Wenn diese nicht angegeben sind, wähle die Darstellung, die die eigentliche Frage der Aufgabe am besten beantwortet, einschließlich UML- und Nicht-UML-Formen; setze nicht jede Anfrage standardmäßig auf ein Flussdiagramm oder eine Swimlane. Verwende diagram-selection.md, wenn du die Darstellung wählst oder wesentlich änderst.
• Wende die oben genannte Objekt-zuerst-Vorgabe auf neue erklärende Flüsse an; Standardsteuersymbole und wiederverwendbare Komponenten-Starter unterstützen dies, ohne einen festen Symbolkatalog vorzugeben.
• Führe bei vertikalen Flussdiagrammen den Hauptpfad von oben nach unten, platziere parallele Zweige nebeneinander, beschrifte Ausgänge von Entscheidungsrauten und gruppiere unterstützende Prüfungen in einer hellgrauen gestrichelten Box mit einem Zweck in einfacher Sprache.
• Wenn eine zentrale Engine externe Module koordiniert, platziere den Kern in der Mitte, gruppiere Eingaben und Arbeiter auf beiden Seiten und verwende nummerierte Pfeile mit Aktionsbeschriftungen, um den Leser durch eine Aufgabe zu führen. Leite gegebenenfalls Feedback über dem Kern, platziere menschliche Entscheidungen und Benachrichtigungskanäle darunter und zeige ein Beispiel-Workflow entlang der Unterseite. Wähle Farben passend zum Thema.
• Behalte beliebige native Draw.io-Formen, Schablonen, Stile, Geometrie, Wegpunkte, Ebenen, Gruppen und Wrapper-Metadaten bei.
• Bevorzuge eine größere Leinwand oder einen größeren Container gegenüber komprimierten Knoten, Beschriftungen oder Routing-Korridoren. Eine kollisionsfreie Datei ist nicht unbedingt geräumig, lesbar oder gut komponiert.
• Plane Beschriftungsplatz für Verbinder, bevor du benachbarte Knoten platzierst. Lange Beschriftungen müssen mit sichtbarem Abstand zwischen den verbundenen Formen passen, oder verwende explizite Zeilenumbrüche/eine andere klare Beschriftungsposition. Löse Risiken mit Endpunkt-Beschriftungen und überprüfe die tatsächlichen gerenderten Textgrenzen, bevor du ein Diagramm als bereit markierst; siehe Abstand von Verbinderbeschriftungen.
• Setze für neu erstellte oder wesentlich überarbeitete Inhalte standardmäßig flowAnimation=1 auf gerichteten semantischen Flusskanten, einschließlich normaler, sekundärer, Daten-, Ausnahme- und Wiederholungsflüsse. Halte Referenzen, Anmerkungen, Enthaltungen, Gruppierungen und rein strukturelle Beziehungen statisch. Lasse explizite Benutzerabsichten diese Richtlinie überschreiben.
• Bewahre nicht zusammenhängende Animationsstile während einer lokalen Bearbeitung, es sei denn, eine Animationsnormalisierung wird angefordert. Wenn Bewegung die Hierarchie verschleiert, mache semantische Flüsse mit niedrigerer Priorität während der gerenderten Qualitätssicherung statisch, anstatt ihre Topologie zu ändern.
• Behandle Verbinderanimation als visuellen Effekt, niemals als Routing- oder Kollisionsvermeidung.
• Verwende die gebündelte CLI nur für Inspektion, Abfrage, Patch, Validierung, Layout-/Topologieprüfungen, Desktop-/Web-Export-Orchestrierung, Begleit-HTML, Seiten-CRUD, Versionsauflistung, Veröffentlichung und Wiederherstellung. Sie erstellt, layoutet oder implementiert keinen Renderer; render delegiert an Draw.io Desktop, web-svg-bridge delegiert eine ausgewählte Seite an offizielles Draw.io Web und die HTML-Vorschau delegiert an den offiziellen Remote-Viewer.
• Behandle <basis>-vNNN als eine logische Lieferversion, die von ihren Bildern und HTML geteilt wird, nicht von jedem internen Schreibvorgang. Die native Versionierung bleibt intern, es sei denn, die Quelllieferung wird angefordert. Standardmäßig verbraucht eine vom Benutzer genehmigte Änderung höchstens eine neue Geschwisterversion.
• Halte jeden öffentlichen CLI --page-index nullbasiert, passend zum von inspect zurückgegebenen index. Bevorzuge stabile Seiten-IDs für die Arbeit mit mehreren Seiten.
• Begrenze jedes Dokument auf 15 Seiten. Die CLI lehnt größere vorhandene Dokumente und Hinzufügungen über dieses Limit mit PAGE_COUNT_LIMIT ab; kürze niemals Seiten, um dies zu erfüllen.
• Aktiviere diese Skill nicht zusammen mit der offiziellen Skill drawio@drawio; diese Skill trägt bereits denselben nativen Mermaid/XML-Autorenpfad.

Wähle die Darstellung

Trenne den Diagrammtyp vom Autorenwerkzeug. Wähle danach, was der Leser verstehen muss: Ablauf, Verantwortlichkeiten, Interaktionen, Zustände, Struktur, Bereitstellung, Datenbewegung oder Vergleich. Ein bereitgestelltes Diagramm, ein explizites Format oder eine angeforderte lokale Bearbeitung schränkt diese Wahl ein. Wenn der Benutzer es offen lässt, triff die Wahl autonom, erkläre sie kurz, wenn es nützlich ist, und fahre fort; zwinge den Benutzer nicht, aus einem Katalog zu wählen. Lese diagram-selection.md für die Frage-zu-Form-Anleitung und Kompromisse.

Wende die standardmäßige visuelle Behandlung oder die explizite Ausnahme der Aufgabe auf alle Seiten und Revisionen an. Füge keine reine Text-Begleitseite als Ersatz für eine objektbasierte Erklärung hinzu.

Wähle dann Objekte und Notation, die für diese Darstellung geeignet sind. Konkrete Illustrationen können Nutzlasten und Transformationen erklären, während formale UML, ER und andere etablierte Symbole ihre semantischen Konventionen beibehalten sollten. Behandle nicht jede beschriftete Klasse, jeden Zustand oder jedes Schemafeld als Textlast-Flussdefekt.

Wähle den Arbeitsablauf

Anfrage	Arbeitsablauf
Erkläre einen Prozess, eine Pipeline, eine Swimlane, einen Lebenszyklus oder einen Architekturfluss	Nachweis/Zuständigkeit → visuelles Storytelling → Objekt-/Zustandskonstruktionen → direktes natives XML → offizielles Renderer-QA
Erstelle ein formales Strukturdiagramm oder ein explizit minimales Box-Diagramm	Bewahre Notation/Inhalt → Mermaid, wenn es die beabsichtigte Darstellung beibehält und Desktop verfügbar ist; andernfalls natives XML
Erstelle mit benutzerdefinierten Formen/Stilen/Positionen	Direktes natives XML → .drawio
Erstelle aus PDF oder Text	Lese Quelle → extrahiere unterstützte Struktur → wähle Darstellung mit denselben Standardeinstellungen → natives XML oder geeignetes Mermaid
Rekonstruiere aus einem Bild	Inspiziere in Originalauflösung → bearbeitbare native Zellen → optionale Vorschau-Vergleich
Prüfe auf visuelle Konflikte	check-layout → Desktop render → inspiziere Bild → kleiner Patch → rerendern; Fallback auf Viewer-HTML
Prüfe einen Geschäftsfluss	check-topology mit bekannten Startpunkten, Endpunkten und erforderlichen Kanten
Anzeigen ohne Desktop	preview → Begleit-.html mit sichtbarer Seitenanzahl/-namen unter Verwendung des offiziellen Remote-Viewers
Exportiere SVG ohne Desktop	Bevorzuge eine web_svg_session.py-Loopback-Sitzung; behalte web-svg-bridge → commit-web-svg für manuelle Wiederherstellung bei
Exportiere oder wende ein angefordertes Layout an	Erstelle zuerst .drawio → Draw.io Desktop CLI
Bearbeiten, Ziel unbekannt	inspect → query → patch
Bearbeiten, Seiten- und Zellen-ID bekannt	query → patch
Bearbeiten, frisches vertrauenswürdiges CLI-Ergebnis hat bereits Revision und Ziel	patch
Seite hinzufügen, umbenennen oder löschen	inspect → page add/rename/delete
Dateiversion auflisten oder wiederherstellen	versions oder versions → inspect old → restore
Fertige Arbeitsdatei veröffentlichen	inspect working → publish
Eine oder mehrere bekannte Zellen anzeigen	query
Datei unabhängig prüfen	validate

Lese references/authoring.md für Erstellung, Vorschau, Desktop-Erkennung, Layout und Export. Lese references/web-svg-export.md nur, wenn Desktop nicht verfügbar ist und explizit angeforderte SVGs über offizielles Draw.io Web exportiert werden müssen. Lese references/layout-authoring.md bei der Erstellung eines überfüllten Diagramms, der Aufrechterhaltung der seitenübergreifenden visuellen Konsistenz, der Interpretation von check-layout oder der Durchführung der gerenderten visuellen Qualitätssicherung. Lese references/topology.md, wenn ein Prozess, Lebenszyklus oder Anforderungspfad verbunden werden muss. Lese references/source-to-diagram.md, wenn die Quelle PDF, Text oder ein Bild ist. Lese references/drawio-xml.md nur für direktes XML-Authoring. Lese references/patch-contract.md, bevor du einen Patch erstellst. Lese references/versioning.md für Seitenbefehle und unveränderlichen Verlauf.

Plane eine logische Lieferung

• Bevor du schreibst, ordne jede angeforderte Änderung ihrer Seite/Zelle zu, den erforderlichen Entscheidungsausgängen, kritischen Start-/End-/Kanteneinschränkungen, Nebeneffekten oder Fehlerpfaden, der Terminologie und allen betroffenen Seiten.
• Definiere für neue mehrseitige Dokumente dokumentlokale visuelle Rollen vor dem Authoring und verwende Seitenfundamente, Typografie, wiederholte Komponentenstile und Beziehungsstyling seitenübergreifend wieder. Erbe beim Hinzufügen oder Bearbeiten von Inhalten die vorhandene Dokumentkonvention innerhalb des angeforderten Umfangs. Befolge dokumentvisuelle Konsistenz für die Rollenauswahl, absichtliche Ausnahmen und die seitenübergreifende Akzeptanz.
• Schreibe für eine einzelne atomare Änderung, die später keine Topologie-, Layout- oder visuelle Korrektur benötigt, direkt in eine neue interne native Version.
• Erstelle für mehrseitige Änderungen oder jede Aufgabe, die wahrscheinlich eine QA-Korrektur benötigt, ein agenteneigenes temporäres Verzeichnis und schreibe working-01.drawio, working-02.drawio und so weiter. Führe alle angeforderten Änderungen und Prüfungen dort durch; publish ist optional für einen internen endgültigen Schnappschuss oder eine explizit angeforderte native Lieferung.
• Generiere das Liefer-HTML und die PNGs pro Seite aus demselben endgültigen geprüften nativen Schnappschuss; eine veröffentlichte .drawio-Lieferung ist nicht erforderlich. Bette für benutzerseitiges HTML eine verifizierte Darstellung jeder Seite mit preview --fallback-png ein (wiederhole in Seitenreihenfolge). Überprüfe das gelieferte HTML mit blockiertem Remote-Viewer, auch bei schmaler Breite. Ein erfolgreiches Online-Rendering allein verifiziert nicht die Vorschau des Empfängers. Wenn kein offizielles Rendering verfügbar ist, kennzeichne das HTML als reine Online-Ansicht und lege die Einschränkung offen. Temporäre Vorschauen sind QA-Artefakte, keine Liefergegenstände.
• Entferne nach der Verifizierung von eigenständigen Bildern und HTML nur die durch diese Aufgabe erstellten entsorgbaren QA-Dateien; behalte den endgültigen nativen Schnappschuss für spätere Änderungen intern. Bereinige niemals vorhandene formale Versionen ohne ausdrückliche Benutzerautorisierung.

Erstellen

1. Lese references/authoring.md und wähle die Darstellung, bevor du eine Syntax wählst. Verwende für einen neuen erklärenden Fluss die Objekt-zuerst-Vorgabe und direktes natives XML; die Desktop-Verfügbarkeit ändert den Export, nicht die visuelle Anforderung. Verwende Mermaid nur, wenn es die gewählte Semantik/Darstellung beibehält, z. B. bei einem formalen Strukturdiagramm oder einem explizit minimalen Box-Diagramm. Erkenne Desktop für Konvertierung/Export.
2. Wähle einen beschreibenden Basisnamen in Kleinbuchstaben mit Bindestrichen, reserviere <basis>-v001 für die anfängliche Bild-/HTML-Lieferung und behalte seinen .drawio-Schnappschuss intern, …

[gekürzt für die Übersetzung]