Openstream

Das Shopify AI Toolkit von 1.0 auf 1.8: Was sich in fünf Monaten geändert hat

Beitrag von

Nick Weisser
Shopify AI Toolkit

·

·

Ich habe die letzten Monate zum ersten Mal einen Shopify Shop mit dem Shopify AI Toolkit entwickelt. Das Toolkit ist Shopifys offizielles Plugin für Claude Code und andere KI-Entwicklungsumgebungen. Es bringt Skills mit, die die Shopify-Dokumentation durchsuchen, GraphQL-Abfragen gegen das echte Schema prüfen und Liquid-Templates validieren.

Installiert habe ich es im April 2026. Als ich heute zufällig in die Plugin-Übersicht schaute, stand dort immer noch Version 1.0.0. Unterdessen war 1.8.0 aktuell. Der Grund ist schnell erzählt: Claude Code aktualisiert Marketplaces von Drittanbietern nicht von allein und Shopify betreibt seinen über ein eigenes GitHub-Repository.

Dieser Artikel schaut sich an, was das Toolkit heute kann, was in diesen fünf Monaten dazukam und ob ich mit dem späten Update tatsächlich etwas verpasst habe.

Was das Shopify AI Toolkit überhaupt macht

Das Toolkit ist keine Shopify-App im Sinne des App Stores und hat mit dem Shop selbst nichts zu tun. Es ist ein Plugin für die Entwicklungsumgebung. Wer mit Claude Code, Cursor oder GitHub Copilot an einem Shopify-Projekt arbeitet, bekommt damit Fachwissen in den Editor, das die KI sonst aus dem Gedächtnis rekonstruieren müsste.

Der Unterschied ist in der Praxis erheblich. Ohne das Toolkit schreibt ein Sprachmodell eine GraphQL-Abfrage, die plausibel aussieht und Felder verwendet, die es in dieser API-Version nicht mehr gibt. Mit dem Toolkit wird dieselbe Abfrage gegen das echte Schema validiert, bevor sie im Code landet. Dasselbe gilt für Liquid-Templates, Checkout-Erweiterungen und Shopify Functions.

Das Toolkit besteht aus sogenannten Skills. Das sind Markdown-Dateien mit Anweisungen plus kleinen Hilfsskripten, die die Dokumentation durchsuchen und Code prüfen. Jeder Skill deckt einen abgegrenzten Bereich ab und wird nur dann aktiv, wenn die Aufgabe dazu passt. In Version 1.0.0 waren es 19 Skills. In Version 1.8.0 sind es 22. Diese Zahl allein sagt allerdings wenig, weil in der Zwischenzeit auch umbenannt und ersetzt wurde.

Die 22 Skills im Überblick

Der vollständige Bestand der Version 1.8.0, gruppiert nach Einsatzgebiet.

  1. shopify-admin: Die Admin-GraphQL-API für alles, was im Shop-Backend passiert. Produkte, Bestellungen, Kundendaten und Lagerbestände lesen und verändern.
  2. shopify-storefront-graphql: Die Storefront-API für eigene Shopfronten mit voller Kontrolle über Datenabruf und Darstellung.
  3. shopify-customer: Die Customer Account API, über die Kundinnen und Kunden ihre eigenen Bestellungen, Zahlungsmittel und Adressen einsehen.
  4. shopify-liquid: Shopifys Templating-Sprache für Themes, inklusive Sections, Blocks, Snippets und Schemas.
  5. shopify-hydrogen: Das React-Framework für Headless-Shopfronten, mit fertigen Rezepten für B2B, Bundles, Abonnemente und Märkte.
  6. shopify-functions: Serverseitige Logik für Rabatte, Versandoptionen, Zahlungsanpassungen und Lieferregeln.
  7. shopify-custom-data: Metafelder und Metaobjekte, also eigene Datenstrukturen über den Standardumfang hinaus.
  8. shopify-polaris-app-home: Die Oberfläche einer App innerhalb des Shopify-Backends.
  9. shopify-polaris-admin-extensions: Eigene Aktionen und Blöcke an definierten Stellen im Backend.
  10. shopify-polaris-checkout-extensions: Erweiterungen im Bezahlvorgang, etwa bei Produktangaben, Versand oder Bestellübersicht.
  11. shopify-polaris-customer-account-extensions: Erweiterungen im Kundenkonto, auf Bestellübersicht, Bestellstatus und Profilseite.
  12. shopify-pos-ui: Oberflächen für das Kassensystem im Detailhandel.
  13. shopify-payments-apps: Die Payments Apps API für Zahlungsanbieter, die sich in den Bezahlvorgang einklinken.
  14. shopify-partner: Programmatischer Zugriff auf das Partner-Dashboard mit Apps, Themes und Vermittlungen.
  15. shopify-shopifyql: Auswertungen und Kennzahlen über Shopifys eigene Abfragesprache. Neu seit Version 1.6.0.
  16. shopify-app-pricing: Preismodelle für öffentliche Apps, von Abonnement über Nutzungsabrechnung bis Testphase. Neu seit Version 1.8.0.
  17. shopify-app-store-review: Prüft eine App vor der Einreichung gegen die Anforderungen des App Stores.
  18. shopify-use-shopify-cli: Alles, was über die Kommandozeile läuft. Konfiguration prüfen, Entwicklungsshops anlegen, Abfragen gegen einen echten Shop ausführen.
  19. shopify-onboarding-dev: Einstieg für Entwicklerinnen und Entwickler, vom Partnerkonto bis zum Projektgerüst.
  20. shopify-onboarding-merchant: Einstieg für Händlerinnen und Händler, inklusive Datenübernahme aus WooCommerce, Etsy oder Wix.
  21. shopify-dev: Allgemeine Dokumentationssuche für alles, was kein spezialisierter Skill abdeckt.
  22. ucp: Das Universal Commerce Protocol, über das KI-Agenten selbst einkaufen. Neu hinzugekommen.

Auffällig an dieser Liste ist die Bandbreite. Sie reicht von der Theme-Entwicklung über Backend-Erweiterungen und Kassensysteme bis zur Abrechnung eigener Apps. Wer nur ein Theme anpasst, wird nie mit der Hälfte davon in Berührung kommen. Genau das ist der Punkt: Die Skills melden sich nur, wenn die Aufgabe passt.

Vier neue Skills zwischen 1.0 und 1.8

Das Changelog des Toolkits ist detailliert geführt, was die Auswertung erleichtert. Vier Skills sind seit April neu dazugekommen.

  1. ucp: Bedient das Universal Commerce Protocol über dessen Kommandozeilenwerkzeug. Damit kann ein Agent Produkte über einen globalen Katalog suchen, Warenkörbe bei einzelnen Händlern anlegen, Bestellungen auslösen und deren Status verfolgen.
  2. shopify-shopifyql: Beantwortet Auswertungsfragen mit ShopifyQL, also Shopifys eigener Abfragesprache für aggregierte Kennzahlen.
  3. shopify-app-pricing: Führt bei der Preisgestaltung öffentlicher Apps auf den von Shopify unterstützten Weg statt auf die ältere Billing-API. Die jüngste Ergänzung.
  4. shopify-use-shopify-cli: Bündelt alles, was über die Shopify-Kommandozeile läuft. Konfigurationen prüfen, Entwicklungsshops anlegen und löschen, Abfragen gegen einen echten Shop ausführen.

UCP: Der Agent als Kundschaft

Der ucp-Skill ist die inhaltlich grösste Veränderung. Das Universal Commerce Protocol haben Shopify und Google gemeinsam entwickelt und am 11. Januar 2026 veröffentlicht. Es ist ein offener Standard dafür, wie KI-Agenten Händler finden, deren Fähigkeiten abfragen und Käufe abschliessen. Etsy, Target, Walmart und Wayfair gehören zu den beteiligten Händlern.

Technisch veröffentlichen Händler und Agenten je ein Profil unter dem Pfad /.well-known/ucp. Der Händler berechnet daraus die Schnittmenge, also welche Fähigkeiten beide Seiten beherrschen. Ein Checkout durchläuft anschliessend definierte Zustände von unvollständig über eskalationsbedürftig bis abschlussbereit. Der mittlere Zustand ist der interessante: Er erlaubt die Übergabe an einen Menschen, wenn der Agent an eine Grenze stösst, etwa bei einer Zahlungsfreigabe.

Bemerkenswert an dem Skill ist die Perspektive. Alle anderen Skills im Toolkit richten sich an Menschen, die für Shopify entwickeln. Der ucp-Skill richtet sich an einen Agenten, der einkauft. Er enthält Anweisungen dazu, wie breit gesucht wird, wann verglichen und wann bezahlt wird. Shopify liefert damit nicht mehr nur Werkzeuge für die Angebotsseite, sondern auch für die Nachfrageseite. Wir haben die Entwicklung in Richtung Agentic Commerce und agentischer Zahlungen mehrfach verfolgt. Der Skill ist der Punkt, an dem sie in der täglichen Entwicklungsumgebung ankommt.

Für Shops im DACH-Raum ist das weniger abstrakt, als es klingt. Wenn Agenten Produktdaten über solche Protokolle beziehen, entscheidet die Qualität der eigenen Daten darüber, ob ein Shop überhaupt in Frage kommt. Das ist dieselbe Logik, die wir in der Frage nach der Lesbarkeit für KI und bei den Agentic Storefronts im DACH-Raum beschrieben haben.

ShopifyQL: Die Lücke, die GraphQL nicht schliesst

Der zweite neue Skill schliesst eine Lücke, die im Projektalltag regelmässig auffällt. Die Admin-GraphQL-API eignet sich dafür, einzelne Datensätze zu lesen und zu verändern. Sie eignet sich nicht dafür, Kennzahlen zu berechnen. Fragen nach dem Umsatz der letzten sieben Tage, nach Bestellungen je Verkaufskanal oder nach der Konversionsrate im Wochenvergleich lassen sich damit nicht sinnvoll beantworten.

Vorher führte dieser Weg zu umständlichen Konstruktionen. Alle Bestellungen eines Zeitraums abrufen und selbst summieren funktioniert bei kleinen Shops und bricht bei grossen zusammen. ShopifyQL rechnet das serverseitig. Der Skill schreibt die Abfrage, die Ausführung gegen den echten Shop übernimmt der Kommandozeilen-Skill.

Auffällig ist, wie streng die Anweisungen an dieser Stelle formuliert sind. Der Skill schärft dem Modell ein, das passende Schema bewusst zu wählen und nicht das aus dem Beispiel zu übernehmen. Wörtlich steht dort, eine Kennzahl aus einem Schema existiere in einem anderen nicht. Wer sie dort nicht finde, habe schlicht das falsche gewählt. Solche Formulierungen entstehen erfahrungsgemäss nicht am Reissbrett, sondern nachdem Modelle den Fehler wiederholt gemacht haben.

Umbenannt, ersetzt, verschwunden

Zwei Skills aus Version 1.0.0 tragen heute andere Namen oder sind aufgegangen. Aus shopify-app-review wurde shopify-app-store-review. Der Skill prüft eine App vor der Einreichung im App Store auf Richtlinienverstösse. Neben dem Namen änderte sich die Arbeitsweise: Statt einer im Skill mitgeführten Kopie der Anforderungen holt er die offizielle Seite bei jedem Lauf frisch ab. Eine Anforderungsliste, die von Hand nachgepflegt wird, ist nach wenigen Monaten überholt.

Der Skill shopify-admin-execution ist aus der Liste verschwunden, seine Aufgabe aber nicht. Sie ist in shopify-use-shopify-cli aufgegangen, der zusätzlich Konfigurationsprüfung, Entwicklungsshops und allgemeine Fehlersuche abdeckt. Wer sich die Beschreibungen nebeneinander legt, erkennt die Herkunft an fast wörtlich übernommenen Beispielen.

Für den Alltag heisst das vor allem eines: Wer sich Notizen oder eigene Anweisungen gebaut hat, die Skills beim Namen nennen, sollte sie nach einem solchen Sprung durchsehen. Skill-Namen sind hier eine Schnittstelle und sie ändern sich ohne Ankündigung.

Habe ich mit dem späten Update etwas verpasst?

Die ehrliche Antwort lautet: teilweise. Und an einer anderen Stelle als erwartet.

Die vier neuen Skills fallen für mein Projekt kaum ins Gewicht. ShopifyQL hätte mir bei zwei, drei Auswertungsfragen Umwege erspart, aber diese Fragen liessen sich auch anders lösen. Der ucp-Skill ist für ein klassisches Shop-Projekt schlicht nicht relevant, so interessant er strategisch ist. App Pricing betrifft nur, wer eine öffentliche App im Store verkauft. Der Kommandozeilen-Skill bündelt vor allem, was vorher schon vorhanden war.

Anders sieht es bei den Verbesserungen aus, die nicht als neue Funktion angekündigt wurden. Sie stehen als Patch-Einträge im Changelog und wirken sich direkt auf die Qualität der Ergebnisse aus. Zwei davon hätten meine Arbeit spürbar verändert.

Die API-Version: der teuerste blinde Fleck

Der gewichtigste Nachteil der alten Version betrifft etwas, das man beim Arbeiten nicht sieht. Version 1.0.0 kannte keine API-Versionen. Weder die Dokumentationssuche noch die Validierung liessen sich auf eine bestimmte Version einschränken. Beides lief immer gegen den neuesten Stand.

Version 1.4.0 führte dafür einen Schalter ein. Seither lässt sich sowohl bei der Suche als auch bei der Prüfung angeben, gegen welche Version gearbeitet wird. Der Skill liest sie idealerweise aus den Projektdateien aus, etwa aus der Konfiguration einer App oder Erweiterung. Ohne Angabe gilt weiterhin die neueste stabile Version, die Antwort nennt dann aber, welche verwendet wurde.

Der Unterschied ist grösser, als er klingt. Shopify veröffentlicht vierteljährlich eine neue API-Version und unterstützt jede davon mindestens ein Jahr. Ein Projekt, das im Frühjahr startet, hängt also nach kurzer Zeit an einer Version, die nicht mehr die neueste ist. Wenn die Prüfung trotzdem gegen den aktuellen Stand läuft, entstehen zwei Arten von Fehlern. Code, der als gültig durchgeht, obwohl er Felder verwendet, die es in der Projektversion noch nicht gibt. Und Beanstandungen an Feldern, die in der eigenen Version völlig in Ordnung sind.

Das ist die unangenehme Sorte Fehler. Sie fällt nicht beim Schreiben auf, sondern erst beim Ausführen gegen den echten Shop. Wer sich auf die Prüfung verlässt, sucht die Ursache dann zuerst überall sonst. Wenn mich das späte Update etwas gekostet hat, dann hier.

Falsche Fehler bei der Theme-Prüfung

Der zweite spürbare Punkt betrifft die Theme-Entwicklung. Version 1.5.0 brachte mehrere Korrekturen an der Liquid-Prüfung. Vorher wurden einzelne Codeblöcke auch dann geprüft, wenn die Prüfung eigentlich weitere Dateien im selben Theme voraussetzt, also Snippets, Assets, Blocks oder Übersetzungsdateien. Das Ergebnis waren Fehlermeldungen für Code, der in seinem tatsächlichen Umfeld einwandfrei funktioniert.

Dazu kam die Einstufung der Meldungen. Hinweise und Warnungen wurden wie Fehler behandelt. Seit 1.5.0 gelten sie als Empfehlung. Sie erscheinen weiterhin in der Detailansicht, lassen die Prüfung aber nicht mehr scheitern.

Falsche Fehlermeldungen sind nicht nur lästig. Sie kosten doppelt, weil erst die Zeit für die Suche draufgeht und danach das Vertrauen in das Werkzeug leidet. Wer sich angewöhnt, Meldungen zu übergehen, übersieht irgendwann die echten. In der alten Version habe ich einige Prüfergebnisse für unbrauchbar gehalten, die vermutlich auf genau dieses Muster zurückgingen.

Ähnliches gilt für kleinere Korrekturen an anderer Stelle. Die Anweisungen für Shopify Functions enthielten fehlerhafte Beispiele, in denen GraphQL-Variablen ein überflüssiges Zeichen trugen. Die Beispiele für Checkout- und Kundenkonto-Erweiterungen zeigten einen Wert für Statusabzeichen, den es dort gar nicht gibt. Und die Anleitung zur App-Oberfläche erklärt seit 1.7.0, wann ein Raster statt eines einfachen Stapels nötig ist, weil Eingabefelder sonst jede Zeile für sich beanspruchen. Alles Kleinigkeiten, die im Einzelfall ein paar Minuten kosten und in Summe deutlich mehr.

Was ich nicht verpasst habe

Zur Ehrlichkeit gehört die Gegenrichtung. Ein erheblicher Teil der Änderungen zwischen 1.0 und 1.8 hätte für mich keinen Unterschied gemacht.

Mehrere Versionen drehen sich um die Verbreitung des Toolkits selbst. Version 1.3.0 brachte ein Installationspaket für Hermes, Version 1.6.0 eines für Pi, Version 1.7.0 eines für OpenClaw sowie die Veröffentlichung als npm-Paket. Version 1.5.0 ergänzte Angaben für einen Codex-Marketplace. Das ist Arbeit an der Reichweite, nicht an der Funktion. Für jemanden, der ohnehin mit Claude Code arbeitet, ändert sich dadurch nichts.

Auch die Straffung der Liquid-Anweisungen gehört in diese Kategorie. Die Datei schrumpfte von rund 1700 auf 370 Zeilen. Das klingt nach Verlust, ist aber eine Verlagerung. Statt Wissen im Skill mitzuführen, wird die Dokumentation gezielt durchsucht. Für das Ergebnis macht das wenig aus, für die Aktualität einiges.

Ebenso wenig relevant war für mich die Verlagerung der Einrichtung von Vorschau-Shops zwischen zwei Skills oder die Korrektur an einem Beispiel für Shopify Functions in Rust. Wer diese Bereiche nicht berührt, merkt davon nichts.

Die Bilanz nach fünf Monaten

Unter dem Strich fällt die Bilanz gemischt aus, aber nicht dramatisch. Kein neuer Skill hätte mein Projekt umgekrempelt. Die Arbeit war die ganze Zeit möglich und das Toolkit in der alten Version deutlich besser als gar keines.

Was ich verpasst habe, ist präziseres Werkzeug. Die versionsbewusste Prüfung ist der Punkt, an dem sich das unbemerkt in echte Fehler übersetzt haben kann. Bei den falschen Fehlermeldungen in der Theme-Prüfung ist der Schaden geringer, weil sie auffallen. Er besteht in verlorener Zeit.

Bemerkenswert finde ich vor allem, wo die relevanten Änderungen standen. Nicht bei den neuen Skills, die als Neuerung angekündigt wurden, sondern in den Patch-Einträgen darunter. Wer nur auf die Liste der neuen Funktionen schaut, hätte den Sprung von 1.0 auf 1.8 für verzichtbar gehalten. Für die tägliche Arbeit war das Gegenteil der Fall.

Einordnung

Aus fünf Monaten mit einem veralteten Werkzeug ziehe ich drei Folgerungen.

  1. Plugins in der Entwicklungsumgebung gehören in den Wartungsplan: Für Server, WordPress-Installationen und Abhängigkeiten in Projekten haben die meisten von uns feste Routinen. Für Werkzeuge im eigenen Editor hat sie kaum jemand, obwohl sie mittlerweile ähnlich viel tun. Ein Termin pro Quartal, an dem die installierten Plugins geprüft werden, hätte meinen Fall verhindert. Wo möglich, sollte die automatische Aktualisierung pro Marketplace bewusst eingeschaltet werden, statt sich auf ein Versprechen im README zu verlassen.
  2. Bei Werkzeugen zählen die Patch-Einträge mehr als die neuen Funktionen: Die vier neuen Skills waren für mein Projekt fast bedeutungslos. Die versionsbewusste Prüfung und die Korrekturen an der Theme-Validierung standen weiter unten im Changelog und haben direkt beeinflusst, wie verlässlich die Ergebnisse waren. Bei einem Werkzeug, das Code prüft, ist die Qualität der Prüfung wichtiger als der Funktionsumfang.
  3. Die API-Version des Projekts explizit festhalten: Unabhängig vom Toolkit lohnt es sich, in jedem Shopify-Projekt schriftlich zu fixieren, gegen welche API-Version gearbeitet wird. Sobald das Werkzeug diese Angabe verarbeiten kann, prüft es gegen den richtigen Stand. Ohne die Angabe prüft es gegen den neuesten. Dann meldet es Probleme, die keine sind, oder übersieht welche, die es sind.

Bei aller Nützlichkeit bleibt einiges mühsam und langsamer, als man es einem KI-gestützten Werkzeug zutrauen würde. Das Toolkit ist stark, solange die Arbeit aus Code besteht. Sobald sie im Backend visuell erledigt werden muss, endet der Vorteil abrupt.

Das deutlichste Beispiel ist das Anlegen eines Ablaufs in der Shopify Flow App. Keiner der 22 Skills deckt Flow ab. Es bleibt also nur der Weg über den Browser. Dort wird es zäh. Der Shopify-Adminbereich bindet solche Apps über Iframes ein. Wenn ein Agent diese Oberfläche über Chrome bedienen soll, kommt es regelmässig zu Problemen mit genau dieser Einbettung. Elemente werden nicht gefunden, Klicks landen im falschen Rahmen, Zustände lassen sich nicht zuverlässig auslesen. Was von Hand ein paar Minuten dauert, wird zur Geduldsprobe.

Das ist keine Eigenheit des Toolkits, sondern eine Grenze der Automatisierung von Oberflächen, die nicht dafür gebaut wurden. Vernünftig wäre gewesen, den Ablauf von Hand anzulegen. Aus Bequemlichkeit habe ich es trotzdem das Toolkit machen lassen. Am Ende ging mehr Zeit fürs Nachfassen drauf als das Klicken gekostet hätte. Wer ehrlich rechnet, kommt bei solchen Aufgaben schneller selbst zum Ziel. Das Toolkit spielt seine Stärke dort aus, wo es Code schreibt und prüft, nicht dort, wo es klicken muss.

Das Toolkit selbst würde ich weiter empfehlen. Es nimmt einem im Shopify-Alltag echte Arbeit ab und die Validierung gegen das tatsächliche Schema verhindert eine ganze Klasse von Fehlern, die sonst erst spät auffällt.

Quellen

Beitragsbild von Jonathan Castañeda.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert