Was der MZP vom GitHub-Oekosystem beanspruchen kann
Zwoelf Funde, drei Buckets, ein Massstab: uebernimmt MZP das Projekt, das Muster — oder bewusst nichts
Datum
2026-09-27
Anlass
Dritte GitHub-Runde mit anderer Blickrichtung: nicht nur Integrationen, sondern DESIGN-, TOOLS- und DEVS-Projekte — und pro Fund die Frage, ob der MZP etwas davon fuer sich beanspruchen kann oder sollte
Methode
Pro Fund: Quelle → tragende Idee → Urteil (beansprucht / teilweise / Grenze) → bei teilweise ein konkreter Zuschnitt mit Nennung der beruehrten Klassen
Grundlage
Stand der Codebasis 2026-09-27, rund 40 MCP-Tools, Branch main. Sternezahlen und Lizenzen aus den jeweiligen Repos
Abgrenzung
Keine Doppelung zu Band 1/2 (Tool-Integrationen) und den Design-Goldgruben; kein Fremdcode, keine neuen Laufzeit-Abhaengigkeiten — die AGENTS.md-Regel gilt unveraendert
TL;DR
Drei 2026er Wellen sind seit Band 1/2 neu relevant: Design-Tokens als Agenten-Vokabular
(DTCG, DESIGN.md), Spec-Driven Development als Standard-Workflow (spec-kit steht bei
133k Sternen) und Browser-Agenten als zweite Leserschaft von MZP-Seiten (Steel,
Stagehand, Playwright-CLI).
Der Befund quer durch alle drei Buckets: MZP kann fast nirgends das Projekt beanspruchen —
wohl aber eine Reihe von Mustern, und drei davon hat es bereits: die DESIGN.md-Profile
(getDesignMdFor/searchBranding sind genau das),
den Komponenten-Katalog mit kopierfertigen Beispielen (lookupStyles ist das
shadcn-Prinzip) und die deklarative Spec mit Validierung, Version und Delta
(DiagramSpec ist das, was Vega fehlt). Die logische Erweiterung liegt
deshalb nicht im Kern, sondern an den Randpfaden: Token-Export,
Fremdformat-Import, Agent-Lesbarkeit,
Spec↔Ticket-Drift. Genau die sind unten als Zuschnitt formuliert und als
IDEA-Tickets im Backlog gelandet.
1 · DESIGN — Vokabeln und Vertraege, kein Editor
MZP ist kein Design-Tool und wird keines. Beanspruchbar sind die Formate, mit denen Design an
Agenten und Artefakte geraten: Tokens, Profile, Snippets.
D1 · Tokens
Style Dictionary + DTCG — der fehlende Transformationsschritt
github.com/style-dictionary/style-dictionary · designtokens.org (Design Tokens Community Group)
Die Idee: Tokens einmal definieren und in alle Zielformate transformieren — CSS, SCSS, iOS, Android, Doku. Eine Quelle, viele Ausgaben.
teilweiseBeanspruchbar ist der Transformationsschritt, nicht das Tool
MZP hat die Quelle bereits — vier Branding-Profile (nightline, ledger, monoblock, arcade) plus die
DiagrammVarianten — aber nur eine Ausgabeform: getDesignMdFor als
Markdown-Profil. Es fehlt die Maschinen-Ausgabe.
Zugeschnitten auf MZP
Ein exportDesignTokens(codename)-Tool liefert die Tokens eines Profils
als CSS-Custom-Properties (--mz-accent …) und DTCG-JSON. Ein
Artefakt zieht sie per fromSlug-Muster (M2) als Begleitdatei, statt
Werte zu kopieren. Reiner Serialisierer ueber vorhandene Daten.
Die 2026er Bewegung: Designregeln als maschinenlesbares Markdown, das ein Agent liest und auf jedes Artefakt anwendet.
beanspruchtDas Muster traegt MZP bereits
getDesignMdFor(codename) liefert genau das — Farbrollen, Typo-Rollen,
Layout-Prinzipien, Voice je Profil — und searchBranding findet Profile
sogar ueber Freitext-Vibe. Der Report markiert es als Ist-Stand, nicht als Luecke.
Logische Erweiterung (klein, spaeter)
Der Rueckweg: ein Artefakt darf Token-Overrides mitschicken (metadata.design),
und der Server validiert sie gegen die bekannten Rollen des Profils, statt unbekannte Werte still
durchzulassen — dieselbe Guard-Philosophie wie UNKNOWN_STYLE_CLASS.
beruehrt: publishArtifact-Metadaten, neue Validierung · Stufe: spaeter
Die Idee: volle Design-Plattform mit Programmierschnittstelle und MCP — fuer Teams, die ihre Design-Infrastruktur besitzen wollen.
GrenzeKein Anspruch — MZP publiziert und versioniert, editiert nicht
Ein Editor ist ein eigener Betrieb, eine eigene Kategorie. Was MZP beansprucht, ist die Ablage-Seite
und die hat es: SVG-Exporte landen ueber publishAsset (R31) mit
trust:inert in der Asset-Bibliothek, andere Seiten ziehen sie per
fromSlug. Ein Design-Team oder Design-Agent kann Penpot-Exporte also
heute schon als Assets ablegen — kein Code noetig.
beruehrt: nichts · bereits abgedeckt durch R31/M2
D4 · Snippets
shadcn/ui — das Katalog-Prinzip steht, der Skill fehlt
github.com/shadcn-ui/ui (~120k Sterne, MIT) · Komponenten als verteilbarer Code plus skills/shadcn im Repo
Die Idee: Komponenten nicht als Blackbox-Paket, sondern als kopierbarer Code mit fertigen Snippets — und ein Agenten-Skill, der die Nutzung erlernbar macht.
beanspruchtKatalog + Beispiele existieren, der Skill ist die kleine Luecke
getCapabilities().styling + lookupStyles
liefern fuer jede mzone-ui-Klasse Zweck, Signatur und fertiges HTML-Beispiel — das shadcn-Prinzip
ist 1:1 da. Das Repo vendort zudem bereits einen Skill
(.kimi-code/skills/diagram-design).
Logische Erweiterung (klein)
Ein mzone-ui-Komponenten-Skill analog skills/shadcn: er nimmt dem
Agenten die Katalog-Routine ab (welche Klasse fuer welchen Zweck, wann getCapabilityFor
statt lookupStyles) und haelt die Beispiele auf dem Stand des
Design-Systems. Kein Core-Code.
beruehrt: docs/agent-workflows oder Skills-Verzeichnis · Stufe: sofort
2 · TOOLS — dem Agenten Arbeit abnehmen oder definieren
Hier liegen die beiden konkreten Luecken dieser Runde: nichts kommt als Fremdformat herein, und
nichts prueft, ob MZP-Seiten fuer Agenten lesbar sind.
T1 · Prozess
Spec Kit — MZP als Spec-Host, nicht als SDD-Prozess
github.com/github/spec-kit (~133k Sterne, MIT) · Spec → Plan → Tasks → Implement, Markdown-Artefakte, Gates, 38 Agenten-Integrationen, Workflows als YAML
Die Idee: Spezifikation als ausfuehrbares Artefakt — jede Phase erzeugt ein Dokument, das die naechste speist, mit menschlichen Gates dazwischen.
teilweiseBeanspruchbar ist die Kopplung der drei Speicher
MZP traegt die Artefakt-Seite bereits: Backlog-Cockpit, docs/superpowers/specs/
(die MZP-18-Spec liegt dort), Ratschen als Gates, Evals (MZP-113). Was fehlt, ist die Kante:
Specs leben im Repo, Tickets im Backlog, Seiten im Graphen — drei Speicher ohne Verbindung.
Zugeschnitten auf MZP
(a) Spec-Seiten: pageType=spec im wiki-page-Template, mit
crossRefs auf die Ticket-Keys, die die Spec erfuellt.
(b) lintWiki-Befundklasse TICKET_DRIFT:
referenzierte Keys, die im Backlog fehlen oder auf DONE/DROPPED stehen, feldgenau mit Quell-Slug.
(c) Die Workflow-Prompts aus Band 1 (4.2) bleiben der Transport — spec-kit bestaetigt die Nachfrage,
nicht den Weg.
MarkItDown — der fehlende Eingangs-Pfad fuer Fremdformate
github.com/microsoft/markitdown (~178k Sterne, MIT) · offizielles markitdown-mcp, ein Tool: convert_to_markdown(uri)
Die Idee: jedes Format (PDF, DOCX, XLSX, EPUB, HTML, Bilder mit OCR) nach Markdown, fuer LLM-Konsum gedacht — mit dem offiziellen MCP-Server als Andockmuster.
teilweiseBeanspruchbar als Importpfad nach dem mzone-render-Muster
Band 2 hat Docling als schweren Import notiert (P3). MarkItDown ist die leichte Variante desselben
Bedarfs. MZP hat den Ausgang (MZP-76 Doku-Export, MZP-79 Markdown→Praesentation), aber keinen
Eingang: nichts wird als PDF/DOCX/XLSX zur Seite.
Zugeschnitten auf MZP
Ein Converter-Service im Container, angesprochen wie mzone-render —
MZP bleibt ein Spring-Prozess ohne Python. Dazu ein Tool
importDocument(uri|base64, slug?, metadata?): konvertiert nach
Markdown und legt das Ergebnis als bodyMd-Wiki-Seite ueber den
bestehenden Publish-Pfad ab. Groessengrenzen und Typ-Whitelist wie ueberall.
Die Idee: Browser und Seiten fuer Agenten lesbar machen — Accessibility-Tree-Trimmen, act/observe/extract, Markdown-Snapshots statt Roh-DOM.
teilweiseNicht der Cloud-Browser — die Erkenntnis ueber die eigene Auslieferung
Den Cloud-Browser beansprucht MZP nicht: den hat es mit mzone-render
selbst. Beanspruchbar ist die Konsequenz: MZP-Seiten sind Zielseiten von Browser-Agenten, also lohnt
Agent-Lesbarkeit als eigenes Qualitaetsmass. Im Diagramm-SVG hat MZP das mit MZP-52/53 bereits
geleistet (data-node-kind u. a.) — den HTML-Seiten fehlt es.
Zugeschnitten auf MZP
Eine Befundklasse AGENT_READABILITY im Browser-Blick
(validateArtifact/publishArtifact): Titel, Landmarks (main/nav), Ueberschriften-Hierarchie ohne
Sprung, Alt-Texte, eindeutige Beschriftungen interaktiver Elemente — als WARNING, nicht als ERROR.
Ergaenzt das HTML-Qualitaets-Gate aus Band 2 (Q1) um die Agenten-Brille; die .md-Fassung (MZP-69)
bleibt der token-sparsame Volltext-Pfad.
Die Ideen: die MCP-Flaeche als App, Tools als registrierte und geroutete Einheiten — und der Harness-Dispatch: wenige generische Tools ueber einem Resource-Typ-Register statt ein Tool je Endpunkt.
beobachtenFrameworks ersetzen nichts — das Dispatch-Muster ist die Notiz
Spring AI + mzone-mcp-common tragen MZP; kein Framework-Wechsel.
Das Dispatch-Muster wird interessant, wenn die Tool-Zahl weiter waechst (LLMs waehlen bei vielen
Tools schlechter). Der naehere Schritt bleibt Band 1 (4.1): Seiten als MCP-resources. Notiz, kein
Plan.
beruehrt: nichts jetzt · Wiedervorlage bei wachsender Tool-Zahl
3 · DEVS — eigene Engine vor fremdem SDK
Bibliotheken und SDKs, die der Agent heute schon kennt. Hier ist die Regel am haertesten: drei
Grenzen, eine kleine Bruecke.
V1 · Canvas
tldraw — keine zweite Engine, aber eine zweite Hand-Editing-Bruecke
Grenze + kleinDer Editor bleibt draussen, der Export nicht
Die Engine-Frage ist entschieden (ADR-011-Pipeline, eigener Viewer MZP-53). Einziger Anspruchspunkt:
ein .tldr-Export neben dem .excalidraw-Export
aus Band 1 (1.6), damit ein publiziertes Diagramm in tldraw von Hand weitergezeichnet werden kann.
Passt zum Export-Ausbau MZP-56.
beruehrt: neuer Export neben diagram.svg · Stufe: spaeter, an MZP-56
GrenzeEigene deklarative Grammatik vorhanden — kein Import noetig
DiagramSpec ist die eigene Grammatik, inklusive Chart-Typen (pie,
treemap, sankey, heatmap, funnel). Was Vega nicht hat — Validierung, Versionierung, Delta
(MZP-55), Interaktiv-Viewer, PNG-Export — ist genau MZPs Kern. Budgets und Schemata je Typ liefert
getCapabilityFor('<typ>'). Ein Vega-Adapter waere eine zweite
Grammatik ohne Gewinn.
beruehrt: nichts
V4 · Design-Agenten
open-pencil — MZP als Publikationsziel, nicht als Werkbank
komplementaer beanspruchtDer Design-Agent editiert in seinem Werkzeug, MZP publiziert
Fertige SVGs gehen ueber publishAsset (trust:inert) in die
Asset-Bibliothek, ganze Figuren ueber den sketch-to-figure-Workflow (MZP-107). Kein Code — die
Arbeitsteilung existiert bereits.
beruehrt: nichts · bereits abgedeckt durch R31/MZP-107
Synthese — Reihenfolge
Sortiert nach Wirkung geteilt durch Aufwand. „Sofort“ = eigenstaendig, kein Core-Code
noetig. „Mittelfristig“ = ein Entwurf wert. „Spaeter“ = haengt an anderem
oder ist reine Ergaenzung. „Beobachten“ = Notiz ohne Plan.
S1sofort
mzone-ui-Agenten-Skill nach shadcn-Muster (D4) und Spec-Seiten mit Ticket-Drift-Lint (T1) — beide ohne Core-Code: ein Skill-Dokument, eine pageType-Erweiterung plus eine lintWiki-Befundklasse.
M1mittelfristig
Design-Token-Export (D1) — der fehlende Transformationsschritt der Branding-Profile; ein Serialisierer, kein Subsystem.
M2mittelfristig
importDocument (T2) — der fehlende Eingangs-Pfad fuer Fremdformate, Gegenstueck zu MZP-79; ein Converter-Container nach dem mzone-render-Muster.
M3mittelfristig
Agent-Lesbarkeit als Befundklasse (T3) — die Band-2-Q1-Ergaenzung um die Agenten-Brille, im vorhandenen Render-Pruefweg.
L1spaeter
Token-Override-Validierung (D2) und .tldr-Export (V1, an MZP-56) — beide sinnvoll, beide erst nach den mittelfristigen Entwuerfen.
B1beobachten
Resource-Typ-Dispatch (T4) — erst wenn die Tool-Zahl waechst; Band 1 (4.1 resources) bleibt der naehere Schritt.
Die bewussten Nicht-Anspruche
Fund
Was nicht beansprucht wird
Warum
Penpot (D3)
Design-Editor, Token-Editor, MCP-Design-API
Andere Kategorie: MZP publiziert und versioniert, editiert nicht. Die Ablage-Seite existiert (R31/M2)
xyflow (V2)
Canvas-Node-UI als Viewer-Ersatz
Der eigene Viewer (MZP-53) liest das SVG-DOM; ein SDK waere Redundanz plus Abhaengigkeit
Vega/Vega-Lite (V3)
Chart-Grammatik, Vega-Adapter
DiagramSpec ist die eigene Grammatik und hat, was Vega fehlt: Validierung, Version, Delta, Viewer
FastMCP/Gateway (T4)
MCP-Framework-Wechsel, Gateway-Infrastruktur
Spring AI + mzone-mcp-common tragen MZP; nur das Dispatch-Muster bleibt als Notiz
Quellen
#
Projekt / Spec
Genutzte Idee
Fundort
D1
Style Dictionary · DTCG
Tokens einmal definieren, in alle Zielformate transformieren