Heute haben wir unser Konzept für ein kuratiertes Agent-Skills-Verzeichnis für TYPO3 veröffentlicht – Agent Skills sind Wissenspakete für KI-Coding-Assistenten wie Claude Code. Danach haben wir die Strategie zu einer ausführlichen wissenschaftlichen Arbeit (Monographie) ausgearbeitet: mit Forschungsfragen, einem Anforderungskatalog, einer Analyse vergleichbarer Fälle und einer kritischen Risikoprüfung, die gezielt nach Schwächen im eigenen Entwurf sucht.
Herausgekommen sind rund 20.000 Wörter in elf Kapiteln. Dieser Artikel fasst die Arbeit zusammen: die vier Forschungsfragen mit ihren Antworten, die Kernthese, die übertragbaren Werkzeuge und die vier Risiken, die die Analyse im eigenen Entwurf gefunden hat.
„Vertrauensinfrastruktur für KI-gestützte Softwareentwicklung: Konzeption eines kuratierten Agent-Skills-Verzeichnisses für vertikale Software-Ökosysteme am Beispiel TYPO3“ – elf Kapitel, Glossar, 27 geprüfte Quellen. Den vollständigen Forschungsartikel lesen Sie in unserer Rubrik Forschung – außerdem als HTML-Fassung und als Markdown-Quelltext. Transparenz: Die Arbeit ist eine Design-Science-Studie aus der Praxis im Dissertationsstil – KI-gestützt erstellt, redaktionell geprüft und keiner Hochschule vorgelegt.
Vier Forschungsfragen, vier Antworten
Die Studie folgt dem Design-Science-Ansatz: Erkenntnisse entstehen, indem man etwas Konkretes entwirft und kritisch bewertet – in diesem Fall das Verzeichnis-Konzept. Die Arbeit ist entlang von vier Forschungsfragen aufgebaut. Die Antworten, jeweils in einem Satz:
| Nr. | Forschungsfrage | Antwort in einem Satz |
|---|---|---|
| F1 | Welche Defizite haben bestehende Verteilwege für Agent Skills? | Es fehlt Kuratierung: Große horizontale Verzeichnisse listen Skills nur auf, prüfen sie aber nicht – Snyk fand bei rund 13 % der untersuchten Skills kritische Probleme. |
| F2 | Was fordern die Stakeholder eines CMS-Ökosystems? | Ein doppeltes Vertrauensversprechen: belegte, datierte Kompatibilitäts- und Sicherheitsaussagen für Nutzer:innen, faire und planbare Aufnahmeprozesse für Autor:innen. |
| F3 | Wie muss ein kuratiertes Verzeichnis gestaltet sein? | Git-first-Architektur mit statischem Index, eine Review-Pipeline in vier Stufen mit Rückrufmechanismus – und Badges, die datierte Prüfprozesse beschreiben statt rechtlich riskanter Garantien. |
| F4 | Wann trägt sich der Dauerbetrieb? | Als strategische Infrastruktur mit kostenlosem Kernkatalog – nicht als Produktgeschäft; betrieben nach dem Packagist-Vorbild mit angestrebter Community-Anerkennung. |
Die Studie stützt sich auf reale Daten: unseren Katalog aus 137 kuratierten Skills , die offene Agent-Skills-Spezifikation mit rund 30 unterstützenden Agents , die dokumentierte Sicherheitslage öffentlicher Verzeichnisse wie skills.sh – und auf den Vergleich mit Drupal, wo bereits ein CI-validiertes Skills-Projekt existiert .
Die Kernthese
Der Wert eines kuratierten Verzeichnisses liegt nicht in den Skills selbst, sondern in geprüften Aussagen über Skills. Dieses Vertrauen muss als Prozess organisiert sein: belegt (getestet an einem realen TYPO3-Projekt), datiert (Prüfdatum sichtbar, Alterung transparent) und widerrufbar (kompromittierte Versionen werden aktiv zurückgerufen).
Alle Teile des Entwurfs – Architektur, Governance, Badge-Semantik und auch das Geschäftsmodell – sind darauf ausgelegt, dass diese Aussagen über die Zeit belastbar bleiben. Verzeichnisse, die nur auf Masse setzen, können das nicht leisten. Das ist der Vorteil eines kuratierten, spezialisierten Verzeichnisses.
Fünf Lehren aus 25 Jahren Registry-Geschichte
Die Studie prüft jede Entwurfsentscheidung an dokumentierten Erfolgen und Misserfolgen etablierter Registries – von TER über npm bis zum Home-Assistant-Store HACS. Daraus ergeben sich fünf Lehren, auf denen der Entwurf aufbaut:
- Schichten entkoppeln. Discovery und Vertrauen sind vom Distributionskanal trennbar – TER überlebte als Vertrauensschicht, während die Auslieferung zu Composer/Packagist wanderte .
- Personen prüfen statt jedes Projekt einzeln. Drupal.org prüft Maintainer:innen einmal gründlich und kennzeichnet Projekte danach mit sichtbaren Badges – dieser Ansatz skaliert .
- Account-Übernahmen einkalkulieren. Wird ein vertrauenswürdiges Konto übernommen, hilft keine Inhaltsprüfung mehr – das zeigen Supply-Chain-Vorfälle wie bei Nx. Nötig sind Herkunftsnachweise (Provenance) und ein Rückrufmechanismus .
- Auch reiner Text ist Angriffsfläche. Agent Skills können schon über normale Sprache angreifen (Prompt Injection); das Review muss deshalb Texte und Skripte gleichermaßen prüfen .
- Governance vor Wachstum. Namensraum-, Streit- und Übergaberegeln sollten veröffentlicht sein, bevor man sie braucht. Ein Weg Richtung Community-Anerkennung beugt außerdem Machtkonzentration vor – HACS und die Open Home Foundation zeigen, wie das funktioniert .
Zwölf Anforderungen, vier Bereiche
Das Kernstück der Studie ist der Anforderungskatalog A1–A12. Er ist aus den Perspektiven von Nutzer:innen, Autor:innen und der Betreiberseite abgeleitet und in vier Bereiche gruppiert:
Geprüfte, datierte Aussagen
Sicherheit als Prozess
Fairness für Beitragende
Betrieb und Bestand
Der Sicherheitsprozess übernimmt bewusst ein erprobtes Vorbild aus dem eigenen Ökosystem: eine zentrale Meldestelle (Intake), koordinierte Sicherheitshinweise (Advisories) und ein Rückrufverfahren nach dem Muster des TYPO3 Security Teams . Die Abdeckungsmatrix in Kapitel 10 der Studie zeigt, dass alle zwölf Anforderungen abgedeckt sind – allerdings keine davon ohne Restrisiko.
Vier Risiken, die die Gap-Analyse fand
Der methodisch wichtigste Teil ist die kritische Vollständigkeitsprüfung. Sie hat gezielt nach Widersprüchen und Lücken im eigenen Entwurf gesucht und vier Probleme gefunden. Alle vier haben zu Änderungen am Entwurf geführt:
Was die Studie nicht löst
Die Arbeit hat klare Grenzen: Sie ist eine Einzelfallstudie am Beispiel TYPO3, ein Entwurf ohne Praxisdaten, und die Quellenlage ist dünn, weil das Ökosystem noch sehr jung ist. Der Entwurf verringert das Haftungsrisiko, beseitigt es aber nicht . Sollte eine gut ausgestattete offizielle Initiative entstehen, hätte er ihr wenig entgegenzusetzen – er könnte ihr aber eine Kooperation anbieten. Auch die Markenfrage bleibt offen: Die Wortmarke „TYPO3“ gehört der TYPO3 Association und darf ohne Genehmigung nicht in Produkt- oder Domainnamen erscheinen .
Fazit
Die Studie bestätigt die Strategie und hat sie an vier Stellen messbar verbessert. Der Anforderungskatalog A1–A12 und die Lehren L1–L5 sind bewusst so angelegt, dass sie sich auf andere Ökosysteme übertragen lassen – etwa auf Drupal, Shopware oder ein internes Plattform-Team. Die Studie hält allerdings fest, dass diese Übertragbarkeit plausibel, aber nicht belegt ist. Das Betreibermodell folgt erprobten Vorbildern , die Community-Finanzierung bleibt sauber getrennt .
Die vollständige Monographie ist frei verfügbar, die strategische Analyse steht im Begleitartikel. Diese Studie ist ein Entwurf, keine Produktankündigung – Feedback dazu nehmen wir gern über unser Kontaktformular entgegen.