Der Publisher hat seit MZP-82 eine eigene Diagramm-Engine mit 21+ Typen, Skins und einem Delta-Router. Diese Analyse schaut nicht nach neuen Abhängigkeiten, sondern nach Ideen — Features, die anderswo Zugkraft haben und die die Engine ohne neue Fremdbibliothek nachbilden könnte.
Sternezahlen aus Websuche September 2026, Momentaufnahme — keine Live-API-Abfrage.
| Projekt | Was es tut | MZP-Bezug |
|---|---|---|
| tt-a1i/archify T1 FAVORIT | Agent-Skill für Cursor/Claude Code/Codex: aus Code oder Systembeschreibung wird typisiertes JSON-IR, deterministisch zu selbstenthaltenem HTML/SVG kompiliert. Fünf Typen (Architektur, Workflow, Sequenz, Data-Flow, Lifecycle). Architektur-Delta zwischen zwei Snapshots, Knoten mit Beleg-Verweis auf konkrete Git-Commits, Export als PNG/SVG/WebM/Share-Card. | Sehr nah am MZP-Modell (typeBlocks, selbstenthaltenes HTML, diffDiagram). Zwei Ideen fehlen
dem MZP: Knoten mit Commit-Beleg und Route/Reach-Tracing über den
Graphen. Siehe Empfehlung 1. |
| imxv/Pretty-mermaid-skills T2 STARK | Mermaid-Quelle ohne Browser zu SVG, PNG oder Terminal-ASCII rendern — 15 Themes, 6 Diagrammtypen, Batch-CLI. | MZP rendert ausschliesslich HTML/SVG. Ein ASCII-Fallback wäre für CLI-Kontexte (Log-Ausgabe,
backlogQuery-Antworten, MCP-Tool-Resultate ohne Browser) billig nachzurüsten. Siehe
Empfehlung 2. |
| excalidraw/mermaid-to-excalidraw | Übersetzt Diagram-as-Code (Mermaid) in editierbare Excalidraw-Elemente — vom starren Rendering zum weiterbearbeitbaren Canvas. | Kein 1:1-Fit (MZP hat keinen interaktiven Canvas-Editor), aber die Denkrichtung — generiertes Diagramm als Startpunkt, nicht Endpunkt, exportierbar in ein Format, das jemand von Hand weiterzieht — ist einen Blick wert, falls je ein Editier-Modus kommt. |
| Projekt | Was es tut | MZP-Bezug |
|---|---|---|
| kieler/elkjs | Eclipse Layout Kernel für JS: hierarchisches (Sugiyama), Kraft-basiertes und radiales Auto-Layout, getrennt von der Diagramm-Darstellung selbst. | Referenzimplementierung für Layout-Algorithmen, keine neue Abhängigkeit nötig — der MZP hat mit dem Edge-Router (Phase A, senkrechte Pfeile via 12px-Stub) bereits eigene Layout-Logik. Bei künftigen Layout-Bugs lohnt der Blick in ELKs Sugiyama-Implementierung als Blaupause, nicht als Library-Import (Konvention: keine neuen Abhängigkeiten ohne Not). |
| D2, PlantUML, Mermaid (Diagram-as-Code-Trio) | 2026 als "gereifter" Standard beschrieben: Text rein, Layout raus, nativ gerendert in GitHub/GitLab/ Notion/Obsidian/Slack. | Bestätigt den vom MZP schon gewählten Weg (typisierte Diagramm-Spec statt Freihand-Canvas). Kein Nachholbedarf, eher Bestätigung der bestehenden Architektur-Entscheidung. |
| Projekt | Was es tut | MZP-Bezug |
|---|---|---|
| rough-stuff/rough (Rough.js) | <9 kB Grafik-Bibliothek für handgezeichnete Linien/Kurven/Formen, Canvas und SVG. | Der MZP hat laut diagram-design-Skill bereits einen eigenen Sketchy-Stil. Kein Grund, Rough.js als Abhängigkeit zu ziehen — aber falls die eigene Sketchy-Implementierung mal an Grenzen stösst, ist Rough.js die zitierfähige Referenz für den Perlin-Noise-Jitter-Ansatz auf Pfaden. |
| jwilber/roughViz | Handgezeichnete Charts (Balken, Linien, Pie) über D3 + Rough.js. | Zeigt, dass der Sketchy-Stil auch auf Business-Charts (nicht nur Architektur-Diagramme) angewendet wird — deckt sich mit den MZP-Diagrammtypen bar/line/pie, für die der Skin ja schon existiert. |
Die "Art"-Ecke von GitHub-Trending ist 2026 vor allem generative Kunst (Shader, Turtle-Grafik, Terrain-Generatoren, ASCII-Art-Tools wie Aniso). Für einen Wiki-/Diagramm-Dienst mit fester Typologie (kein Freihand-Canvas, keine Kunstgenerierung) trägt das kaum etwas bei — siehe Kein Fit.
Archify bindet Knoten an konkrete Git-Commits als Beleg. Der MZP kennt diffDiagram und
diffVersions bereits als Vergleichs-Werkzeuge zwischen zwei Diagramm-Versionen — ein optionales
sourceRef-Feld je Knoten (Commit-Hash, Datei:Zeile) wäre eine kleine Erweiterung der bestehenden
DTOs, kein neuer Diagrammtyp. Nutzen: Architektur-Diagramme, die aus echtem Code generiert werden, bleiben
nachvollziehbar, statt Behauptung zu bleiben.
Pretty-mermaid-skills rendert dieselbe Spec wahlweise als SVG oder als Terminal-ASCII, ganz ohne Browser.
Für MZP-Antworten, die über MCP-Tools ohne HTML-Renderer konsumiert werden (Log-Ausgabe, CLI-Agenten, schneller
Vorschau-Text in getPageContext), wäre ein schlanker ASCII-Renderer über die bestehende
Diagramm-Spec ein greifbarer Zusatznutzen — kein neuer Diagrammtyp, sondern ein zweiter Ausgabe-Pfad für
vorhandene Typen.
Mermaid/D2/PlantUML als "gereifter Standard" bestätigen die vom MZP schon 2025 getroffene Wahl (typisierte Spec statt Freihand-Canvas). Kein Handlungsbedarf, nur Bestätigung — wert, in einer ADR als Fussnote zu erwähnen, falls die Entscheidung je hinterfragt wird.