Drei Monate nach Launch: was wir aus dem Claude Code Marketplace gelernt haben

Vor drei Monaten haben wir intern einen eigenen Claude Code Marketplace aufgesetzt: ein Set aus Plugins, Skills und Agents, die unsere agentischen Workflows rund um Content und Frontend orchestrieren sollen. Die Idee war simpel, wiederkehrende Aufgaben in wiederverwendbare, klar abgegrenzte Bausteine zu giessen, statt jedes Mal neu zu improvisieren. Was folgt, ist kein Erfolgsbericht mit glatten Zahlen, denn belastbare Nutzungs- oder ROI-Kennzahlen liegen uns für diesen Zeitraum schlicht nicht vor. Es ist eine qualitative Zwischenbilanz aus täglicher Arbeit: welche Plugins tatsächlich im Alltag ankommen, welche nur auf dem Papier gut aussahen, wo die eigentliche Arbeit liegt und was wir inzwischen anders machen würden. Für alle, die selbst überlegen, agentische Workflows in ihrer Content- oder Frontend-Pipeline zu strukturieren, ist genau dieser ungeschönte Blick vermutlich näher an der Realität als jede Launch-Ankündigung.

Welche Plugins wirklich benutzt werden, gegenüber denen, die gut klangen

Am Anfang stand eine lange Liste an Ideen: Plugins für SEO-Audits, für Wettbewerbsbeobachtung, für automatisierte Changelog-Zusammenfassungen, für Asset-Kuratierung, für Markenprüfung. Fast alle klangen im Konzept überzeugend, weil sie ein reales Problem adressierten. Nach drei Monaten zeigt sich aber ein deutliches Muster: benutzt werden vor allem die Plugins, die in einen bestehenden, täglichen Arbeitsschritt eingebettet sind, nicht die, die einen neuen Prozess erst etablieren müssten.

Der Brand-Review-Skill etwa läuft mittlerweile faktisch bei jedem Content-Stück vor der Veröffentlichung, weil er sich an eine Stelle im Ablauf hängt, die es ohnehin schon gab, nämlich die Prüfung vor dem Push. Ein Skill für proaktive Wettbewerbsrecherche dagegen, den niemand aktiv anstossen musste, weil er "irgendwann relevant werden könnte", wird deutlich seltener aufgerufen als gedacht. Er ist nicht schlecht, er sitzt nur an keiner Stelle, an der jemand täglich vorbeikommt.

Eine zweite Beobachtung: Skills, die eine klare Vorher-Nachher-Transformation liefern, etwa Markdown zu einem publizierbaren Blog-Node mit Asset-Referenzen, werden häufiger angefragt als Skills, die "nur" recherchieren oder vorschlagen. Recherche-Ergebnisse müssen von jemandem bewertet und weiterverarbeitet werden, das kostet zusätzliche Aufmerksamkeit. Ein fertiges Artefakt dagegen lässt sich sofort prüfen und freigeben oder verwerfen. Diese Reibungsdifferenz unterschätzen wir am Anfang deutlich.

Und schließlich: Plugins, die für einen sehr spezifischen, seltenen Anlass gebaut wurden, etwa für punktuelle Locale-Reparaturen, werden von der Mehrheit der Teammitglieder gar nicht als eigenständige Werkzeuge wahrgenommen, sondern eher als Notfall-Schublade. Das ist in Ordnung, solange man beim Bauen weiß, dass man für eine kleine, spezialisierte Zielgruppe entwickelt, und nicht enttäuscht ist, wenn die große Mehrheit sie nie anfasst.

Warum Skills mit klarer Trigger-Beschreibung besser gefunden werden

Ein Skill ist nur so nützlich wie die Wahrscheinlichkeit, dass er im richtigen Moment aufgerufen wird. Genau hier haben wir in den ersten Wochen unterschätzt, wie viel an der Formulierung der Trigger-Beschreibung hängt. Skills mit vagen, allgemeinen Beschreibungen wie "hilft bei Content-Aufgaben" wurden in der Praxis deutlich seltener korrekt zugeordnet als Skills mit konkreten Auslösern wie "Update Hero-Bild auf bestehendem Blog-Post" oder "CSV-Import für Partner-Apps aus HubSpot".

Der Grund ist naheliegend, wenn man ihn einmal ausgesprochen hat: eine agentische Instanz muss aus einer natürlichsprachlichen Anfrage ableiten, welches von mehreren möglichen Werkzeugen gemeint ist. Je präziser die Trigger-Formulierung den tatsächlichen Sprachgebrauch abbildet, mit dem Menschen die Aufgabe im Alltag beschreiben, desto zuverlässiger die Zuordnung. Wir haben mehrfach erlebt, dass ein technisch einwandfreier Skill schlicht nicht gefunden wurde, weil seine Beschreibung in einer anderen Terminologie geschrieben war als die, die im Team tatsächlich verwendet wird.

Daraus folgt ein Arbeitsprinzip, das wir inzwischen konsequent anwenden: bevor ein neuer Skill gebaut wird, sammeln wir die tatsächlichen Formulierungen, mit denen Kolleginnen und Kollegen die Aufgabe beim Namen nennen würden, und bauen die Trigger-Beschreibung darum herum, nicht umgekehrt. Das klingt banal, hat aber mehr Unterschied gemacht als jede Optimierung an der eigentlichen Skill-Logik.

Ein weiterer Effekt: mehrere sehr ähnliche Skills mit leicht überlappenden Triggern schaden mehr, als sie nutzen. Statt Präzision entsteht Verwirrung, welches Werkzeug für welchen Fall zuständig ist. Wir haben deshalb im Laufe der drei Monate zwei ursprünglich getrennte Skills zusammengelegt, weil ihre Zuständigkeiten in der Praxis niemand sauber auseinanderhalten konnte, und die Zuverlässigkeit der Zuordnung ist seither spürbar gestiegen.

Warum Memory-Pflege der eigentliche Aufwand ist, nicht das Schreiben der Skills

Wenn man einen Marketplace mit agentischen Werkzeugen aufsetzt, geht die meiste anfängliche Energie in das Design der Skills selbst: welche Schritte, welche Delegationen, welche Ausgabeformate. Nach drei Monaten steht fest, dass dieser Teil vergleichsweise schnell erledigt ist. Der wirklich anhaltende Aufwand liegt woanders, nämlich in der laufenden Pflege der Memory-Dateien, auf die sich diese Skills stützen.

Ein Skill, der Brand-Voice prüfen soll, ist nur so gut wie die Guidelines-Datei, die er referenziert. Wenn sich die Tonalität weiterentwickelt, ein neues verbotenes Buzzword dazukommt oder ein Wettbewerber sich neu positioniert, muss diese Änderung in die Memory-Datei einfliessen, sonst arbeitet der Skill mit veralteten Annahmen und produziert Ergebnisse, die formal korrekt, inhaltlich aber nicht mehr aktuell sind. Diese Pflege passiert nicht automatisch, sie erfordert regelmäßige, bewusste Zeit von jemandem, der den aktuellen Stand kennt.

Ähnlich bei der Hygraph-Schema-Dokumentation: sobald sich ein Content-Model ändert, ein neues Pflichtfeld dazukommt oder eine Taxonomie erweitert wird, muss die entsprechende Memory-Datei nachgezogen werden, sonst produzieren nachgelagerte Skills Mutationen gegen ein Schema, das es in dieser Form nicht mehr gibt. Wir haben das mehrfach unterschätzt und danach Fehler debuggt, die sich am Ende als schlicht veraltete Referenzdaten entpuppten, nicht als Logikfehler im Skill.

Die ehrliche Beobachtung nach drei Monaten lautet daher: agentische Workflows verschieben den Aufwand nicht weg von Menschen, sie verschieben ihn von der Ausführung hin zur Pflege der Wissensgrundlage. Das ist kein Nachteil per se, aber es ist eine andere Art von Arbeit als vorher, und wer das nicht einplant, wird von der laufenden Instandhaltung überrascht.

Wo agentische Automatisierung in der Content- und Frontend-Pipeline wirklich trägt

Am deutlichsten trägt Automatisierung dort, wo eine Aufgabe repetitiv, klar strukturiert und mit eindeutigen Erfolgskriterien versehen ist. Der Push von fertigen Markdown-Drafts in Hygraph, inklusive Asset-Upload, Localisation-Verknüpfung und Publish-Schritt, ist so ein Fall: die Schritte sind immer dieselben, die Reihenfolge ist bekannt, und Fehler lassen sich klar an Statuscodes und Query-Ergebnissen erkennen. Genau hier hat der einheitliche Push-Pfad die vorherige Sammlung an Einzelskripten spürbar abgelöst.

Auch bei der Qualitätssicherung vor Veröffentlichung trägt Automatisierung gut: ein deterministischer Check auf relative Links, fehlende Locale-Präfixe oder eine zu geringe Zahl an Hub-Verlinkungen ist genau die Art von Regel, die ein Skript zuverlässiger prüft als ein Mensch unter Zeitdruck am Ende eines langen Arbeitstags. Das ist kein Ersatz für redaktionelles Urteil, aber eine sinnvolle Vorstufe davor, die offensichtliche Fehler herausfiltert, bevor überhaupt ein Mensch draufschaut.

Auch die Apps-Registry-Synchronisation zwischen HubSpot, Supabase und Hygraph gehört in diese Kategorie: die Struktur der Daten ist stabil, die Transformation ist regelbasiert, und die Ergebnisse lassen sich stichprobenartig validieren, ohne dass jemand jede einzelne Zeile von Hand prüfen muss. Hier spart Automatisierung tatsächlich Aufmerksamkeit, weil sie eine Aufgabe übernimmt, die vorher niemand gerne gemacht hat, weil sie zwar notwendig, aber wenig anspruchsvoll war.

Gemeinsam ist all diesen Fällen: es gibt eine klare Definition von "richtig" und "falsch", die sich in Code giessen lässt. Überall dort, wo diese Klarheit fehlt, etwa bei der Frage, ob ein Text tatsächlich überzeugend ist oder ob ein Thema strategisch sinnvoll ist, trägt Automatisierung deutlich weniger.

Wo Automatisierung Handarbeit nur verschiebt

Weniger überzeugend ist die Bilanz dort, wo eine Aufgabe zwar formal automatisiert wird, die eigentliche Entscheidung aber weiterhin bei einem Menschen liegt. Ein gutes Beispiel ist die Themenfindung für Content: ein Agent kann Recherche zusammenfassen, Trends sichten und Vorschläge formulieren, aber die Entscheidung, welches Thema für die eigene Zielgruppe und Positionierung tatsächlich relevant ist, bleibt eine strategische Abwägung, die kein Skill übernehmen sollte. Wird das trotzdem versucht, entsteht ein trügerischer Effizienzgewinn: die Vorarbeit ist schneller erledigt, aber die eigentliche Prüfung, ob der Vorschlag taugt, braucht am Ende genauso viel Aufmerksamkeit wie vorher.

Ähnlich bei der Bildauswahl für die Apps-Registry: das automatisierte Logo-Sourcing findet in der Mehrheit der Fälle brauchbare Ergebnisse, aber es liefert regelmäßig auch Marketing-Mockups oder falsch zugeordnete Bilder, die erst durch einen manuellen Blick auffallen. Die Handarbeit verschwindet also nicht, sie verschiebt sich von "Bild suchen" zu "Bild prüfen", und diese Prüfung lässt sich schlecht delegieren, weil sie ein Gespür für Markenkonsistenz braucht, das schwer in Regeln zu fassen ist.

Auch bei Brand-Voice-Fragen zeigt sich diese Verschiebung: ein Skill kann verbotene Begriffe zuverlässig herausfiltern, aber die subtilere Frage, ob ein Text im Ton zur Marke passt oder nur formal die Regeln einhält, bleibt eine Beurteilung, die letztlich ein Mensch treffen muss. Wer glaubt, dieses Urteil vollständig outsourcen zu können, verschiebt lediglich den Zeitpunkt, an dem die Handarbeit anfällt, meist nach hinten, kurz vor der Veröffentlichung, wenn Korrekturen teurer werden.

Was nicht funktioniert hat

Ehrlichkeit gehört zu dieser Bilanz dazu: nicht alles hat sich bewährt. Ein früher Versuch, einen Skill zu bauen, der eigenständig neue Content-Themen basierend auf Wettbewerbsaktivität vorschlagen sollte, wurde nach kurzer Zeit kaum noch genutzt, weil die Vorschläge zwar plausibel klangen, aber selten den tatsächlichen strategischen Prioritäten entsprachen. Das Problem lag nicht am Skill selbst, sondern daran, dass wir eine Entscheidung automatisieren wollten, die schlicht nicht ausreichend regelbasiert ist.

Auch der Versuch, Locale-Reparaturen vollständig automatisch laufen zu lassen, ohne vorherige Diagnose, hat sich als riskant erwiesen. Ein einzelner falsch interpretierter Datensatz konnte in der Breite mehr Schaden anrichten, als eine punktuelle, manuell geprüfte Korrektur je verursacht hätte. Inzwischen läuft jede Reparatur über eine Diagnose-Abfrage zuerst, und erst danach über gezielte, einzelne Mutationen, nie über einen pauschalen Re-Push.

Eine dritte Lehre betrifft die Erwartungshaltung an Geschwindigkeit: die Annahme, dass mehr Automatisierung automatisch weniger Gesamtzeit bedeutet, hat sich in dieser Form nicht bestätigt. Wo Automatisierung Zeit spart, verschiebt sie diese Zeitersparnis oft in zusätzliche Sorgfalt an anderer Stelle, etwa in die bereits erwähnte Memory-Pflege. Das ist kein Grund, die Automatisierung zu verwerfen, aber es ist ein Grund, sie nicht als reine Zeitersparnis zu verkaufen, sondern als Verschiebung von Aufwand an eine Stelle, an der er sich besser kontrollieren lässt.

Einordnung: was das für eine eigene agentische Pipeline bedeutet

Wer selbst überlegt, agentische Workflows für Content oder Frontend-Betrieb zu strukturieren, sollte aus unseren drei Monaten vor allem eine Erwartung mitnehmen: der Aufwand verschwindet nicht, er verlagert sich. Von der Ausführung repetitiver Schritte hin zur Pflege der Wissensgrundlage, von der Suche nach Informationen hin zur Prüfung von Vorschlägen, von einzelnen Skripten hin zu einem einheitlichen, auditierbaren Pfad. Das ist ein sinnvoller Tausch, aber nur, wenn man ihn bewusst eingeht und nicht ein leeres Zeitversprechen dahinter vermutet.

Am ehesten lohnt sich der Einstieg dort, wo Aufgaben bereits heute klar strukturiert, wiederkehrend und mit eindeutigen Erfolgskriterien versehen sind, etwa im Push-Pfad zwischen Redaktion und Content-Management-System. Genau in diesem Bereich unterstützt unsere agentische Frontend Management Platform (FMP) Teams dabei, Content-Operationen strukturiert und nachvollziehbar zu halten, statt sie in ad-hoc Skripten zu verstreuen.

Weniger lohnend ist der Versuch, strategische oder geschmackliche Entscheidungen vollständig zu automatisieren. Wer in seiner eigenen Rolle als Content-Manager verantwortlich für Ton, Priorisierung und Qualität bleibt, findet in unserem Überblick zum Content-Management einen guten Ausgangspunkt, um zu sehen, wo strukturierte Werkzeuge diese Rolle unterstützen, ohne sie zu ersetzen. Und wer sich fragt, wie eine komponierbare, headless Frontend-Architektur solche Workflows technisch trägt, findet dazu Kontext in unserer Übersicht zum composable headless Frontend.

Drei Monate sind kurz genug, um noch nichts abschliessend zu bewerten, aber lang genug für ein ehrliches Zwischenfazit: die Werkzeuge, die bleiben, sind die, die sich in bestehende Arbeit einfügen, nicht die, die einen neuen Prozess von aussen aufdrücken. Wer diese Unterscheidung von Anfang an mitdenkt, spart sich einige der Umwege, die wir in den ersten drei Monaten gegangen sind, und findet in unserer Rollen-Übersicht für Content-Manager weitere Anhaltspunkte, wo der nächste sinnvolle Schritt liegt.