Zwölf Anforderungen, fünf Lehren, vier Risiken: die Studie zum Agent-Skills-Verzeichnis für TYPO3

Unsere Monographie zum kuratierten Agent-Skills-Verzeichnis für TYPO3, zusammengefasst: Forschungsfragen, Anforderungskatalog, Registry-Lehren und Risikoanalyse.

Auf einen Blick

  • Die Monographie „Vertrauensinfrastruktur für KI-gestützte Softwareentwicklung“ arbeitet unsere Verzeichnis-Strategie auf rund 20.000 Wörtern in elf Kapiteln wissenschaftlich auf – dieser Artikel fasst sie zusammen.
  • Die Kernthese in einem Satz: Ein Verzeichnis verkauft keine Skills, sondern geprüfte Aussagen über Skills – Vertrauen muss belegt, datiert und widerrufbar sein.
  • Zwei übertragbare Werkzeuge entstehen dabei: der Anforderungskatalog A1–A12 und fünf Lehren aus einem Vierteljahrhundert Registry-Geschichte (L1–L5).
  • Eine adversariale Gap-Analyse fand vier materielle Risiken – vom planmäßigen Vertrauensverfall über LTS-Zyklen bis zum Bus-Faktor des Betreibers.

Heute haben wir unsere Blaupause für ein kuratiertes Agent-Skills-Verzeichnis für TYPO3 veröffentlicht. Danach haben wir das Gegenteil von Marketing gemacht: Wir haben die Strategie in eine Monographie im Dissertationsstil überführt – mit Forschungsfragen, Anforderungskatalog, Präzedenzfall-Analyse und einer adversarialen Risikoprüfung, die gezielt nach den Schwächen des eigenen Entwurfs sucht.

Herausgekommen sind rund 20.000 Wörter in elf Kapiteln. Dieser Artikel ist die Fassung für alle, die keine Dissertation lesen wollen: die vier Forschungsfragen mit ihren Antworten, die Kernthese, die übertragbaren Werkzeuge – und die vier Risiken, die die Analyse im eigenen Entwurf gefunden hat.

Die vollständige Studie

„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. Verfügbar als lesefreundliche 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-Paradigma: Erkenntnis durch Entwurf und kritische Evaluation eines Artefakts. Vier Fragen strukturieren die Arbeit – hier mit ihren Antworten in je einem Satz:

Nr.ForschungsfrageAntwort in einem Satz
F1Welche Defizite haben bestehende Verteilwege für Agent Skills?Eine strukturelle Kuratierungslücke: Horizontale Verzeichnisse indexieren, aber sie prüfen nicht – Snyk fand bei rund 13 % der untersuchten Skills kritische Probleme.
F2Was 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.
F3Wie muss ein kuratiertes Verzeichnis gestaltet sein?Git-first-Architektur mit statischem Index, vierstufige Review-Pipeline mit Rückrufmechanismus und eine rechtssichere Badge-Semantik aus datierten Prozessaussagen.
F4Wann 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 empirische Basis ist real: unser 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 der Blick auf Drupal, wo ein CI-validiertes Skills-Projekt bereits existiert .

Die Kernthese  

Ein Satz, der die ganze Studie trägt

Ein Verzeichnis verkauft keine Skills, sondern geprüfte Aussagen über Skills. Vertrauen muss als Prozess organisiert sein: belegt (getestet gegen ein reales TYPO3-Projekt), datiert (Prüfdatum sichtbar, Alterung transparent) und widerrufbar (aktiver Rückruf kompromittierter Versionen).

Alles am Entwurf dient der Belastbarkeit dieser Aussagen über die Zeit – die Architektur, die Governance, die Badge-Semantik und sogar das Geschäftsmodell. Genau das können Volumen-Verzeichnisse strukturell nicht bieten, und genau deshalb ist die kuratierte Vertikale verteidigungsfähig.

Fünf Lehren aus einem Vierteljahrhundert Registry-Geschichte  

Die Studie validiert jede Entwurfsentscheidung gegen dokumentierte Erfolge und Misserfolge etablierter Registries – von TER über npm bis zum Home-Assistant-Store HACS. Fünf Lehren tragen den Entwurf:

  1. Schichten entkoppeln. Discovery und Vertrauen sind vom Distributionskanal trennbar – TER überlebte als Vertrauensschicht, während die Auslieferung zu Composer/Packagist wanderte .
  2. Menschen prüfen, Artefakte badgen. Drupal.org ersetzte die Einzelprüfung jedes Projekts durch einmaliges Prüfen der Maintainer:innen plus sichtbare Abdeckungs-Badges – das skaliert .
  3. Kontokompromittierung einkalkulieren. Die Übernahme vertrauenswürdiger Konten schlägt jede Inhaltsprüfung – wie Supply-Chain-Vorfälle à la Nx zeigen; nötig sind Provenienznachweise und ein Rückrufmechanismus .
  4. Prosa ist Angriffsfläche. Agent Skills können schon über natürlichsprachige Anweisungen angreifen; Review muss Texte und Skripte gleichermaßen erfassen .
  5. Governance vor Wachstum. Namensraum-, Streit- und Übergaberegeln gehören publiziert, bevor sie gebraucht werden – und ein Pfad Richtung Community-Anerkennung beugt Machtkonzentration vor, wie HACS und die Open Home Foundation vormachen .

Zwölf Anforderungen, vier Cluster  

Das Scharnier der Studie ist der Anforderungskatalog A1–A12, hergeleitet aus den Perspektiven von Nutzer:innen und Autor:innen sowie der Betreiberseite. Gruppiert in vier Cluster:

Belegen statt behaupten

Versionierte LTS-Kompatibilitätsaussagen (A2), nachvollziehbare Provenienz (A3) und Badges als datierte Prozessaussagen statt Ergebnisgarantien (A10).

Sicherheit als Prozess

Security-Prüfung von Prosa und Skripten vor Publikation (A4) und ein aktiver Yank-Mechanismus, der installierte Clients warnt (A6).

Fairness für Beitragende

Publizierte Review-Kriterien mit verbindlichen Antwortzeiten (A7) und verdiente Namensräume mit Squatting-Schutz (A8).

Betrieb und Bestand

Spezifikationstreue (A1), Ein-Kommando-Installation (A5), datenschutzkonforme Telemetrie (A9), Alterungstransparenz über LTS-Zyklen (A11) und ein dauerhaft kostenloser Kernkatalog (A12).

Der Sicherheitsprozess übernimmt bewusst ein erprobtes Vorbild aus dem eigenen Ökosystem: Intake, koordinierte Advisories und Rückruf nach dem Muster des TYPO3 Security Teams . Die Abdeckungsmatrix in Kapitel 10 der Studie zeigt: Keine der zwölf Anforderungen bleibt ungedeckt – aber keine ist risikofrei erfüllt.

Vier Risiken, die die Gap-Analyse fand  

Der methodisch spannendste Teil: Eine adversariale Vollständigkeitskritik suchte gezielt nach Widersprüchen und blinden Flecken im eigenen Entwurf – und wurde viermal fündig. Alle vier Funde haben den Entwurf materiell verändert:

Was die Studie nicht löst  

Zur intellektuellen Ehrlichkeit gehören die Grenzen: Die Arbeit ist eine Einzelfallstudie am Beispiel TYPO3, ein Ex-ante-Entwurf ohne Felddaten, und ihre Quellenlage ist die eines sehr jungen Ökosystems. Der Entwurf beseitigt die Haftungsexposition nicht, sondern mindert sie – und gegen eine gut ausgestattete offizielle Initiative kann er nicht gewinnen, ihr aber ein anschlussfähiges Kooperationsangebot machen. Auch die Markenfrage bleibt ein Gate: 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. Ihre Werkzeuge sind bewusst übertragbar angelegt: Der Anforderungskatalog A1–A12 und die Lehren L1–L5 sind für andere vertikale Ökosysteme anschlussfähig – ob Drupal, Shopware oder ein internes Plattform-Team; die Studie selbst weist die Übertragbarkeit ehrlich als plausibilisiert, nicht als gezeigt aus. Das Betreibermodell folgt erprobten Vorbildern , die Community-Finanzierung bleibt sauber getrennt .

Weiterlesen und mitreden

Die vollständige Monographie ist frei verfügbar, die Strategie mit Roadmap steht im Begleitartikel. Feedback zur Studie nehmen wir gern persönlich entgegen – etwa auf den T3DD26 in Karlsruhe – oder über unser Kontaktformular.

Lassen Sie uns über Ihr Projekt sprechen

Standorte

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Wien
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Dieser Inhalt wurde teilweise mithilfe von KI erstellt.