Vertrauensinfrastruktur für KI-gestützte Softwareentwicklung

Konzeption eines kuratierten Agent-Skills-Verzeichnisses für vertikale Software-Ökosysteme am Beispiel TYPO3

Kurt Dirnbauer webconsulting.at, Wien/Österreich Juli 2026

Hinweis zur Natur dieses Dokuments Diese Monographie ist im Stil einer Dissertation verfasst, wurde jedoch keiner Hochschule vorgelegt und nicht wissenschaftlich betreut. Sie ist eine Design-Science-Studie aus der Praxis: Sie dokumentiert Problemanalyse, Anforderungserhebung, Artefakt-Entwurf und Risikoevaluation für ein reales Vorhaben. Die zugrunde liegende Recherche wurde im Juli 2026 durchgeführt; alle Quellen waren zu diesem Zeitpunkt öffentlich zugänglich.

---

Zusammenfassung

KI-Coding-Agents wie Claude Code, Cursor oder Gemini CLI beziehen Fachwissen zunehmend über Agent Skills – portable Markdown-Wissenspakete nach einer offenen Spezifikation, die von rund 30 Agents unterstützt wird. Die Distribution dieser Skills erfolgt heute überwiegend über horizontale Verzeichnisse, die auf Volumen statt auf Prüfung optimieren: Eine Sicherheitsanalyse von Snyk fand bei rund 13 % der untersuchten, öffentlich gelisteten Skills kritische Probleme – von Prompt Injection bis zu Schadsoftware. Zugleich fehlt in etablierten CMS-Ökosystemen wie TYPO3 eine kuratierte, vertikale Alternative.

Die vorliegende Arbeit entwirft nach dem Design-Science-Paradigma ein kuratiertes Agent-Skills-Verzeichnis für das TYPO3-Ökosystem. Aus einer Analyse von Registry-Präzedenzfällen (TER/Packagist, Drupal.org, npm, VS-Code-Marketplace, HACS) und einer Stakeholder-Untersuchung wird ein Anforderungskatalog (A1–A12) abgeleitet. Darauf aufbauend werden vier Artefakte entworfen: eine Git-first-Architektur mit statischem Index und mehrkanaliger Distribution, ein Governance-Modell mit vierstufiger Review-Pipeline und aktivem Rückrufmechanismus, ein rechtlicher Rahmen (Markenrecht, Lizenzarchitektur, Digital Services Act, EU-Produkthaftung) mit rechtssicherer Badge-Semantik sowie ein Betreibermodell nach dem Packagist-Vorbild („Endorsed Operator").

Die Evaluation über eine adversariale Gap-Analyse identifiziert vier materielle Risiken – planmäßiger Vertrauensverfall über LTS-Zyklen, Eigentumswiderspruch, außervertragliche Haftung und Kapazitätsgrenzen des Betreibers – und führt sie in den Entwurf zurück. Zentrales Ergebnis: Ein vertikales Verzeichnis ist gegenüber horizontalen Katalogen genau dann verteidigungsfähig, wenn es Vertrauen als geprüften, datierten und widerrufbaren Prozess organisiert – nicht als Behauptung.

Schlagwörter: Agent Skills, KI-gestützte Softwareentwicklung, Software-Registries, Kuratierung, Vertrauensinfrastruktur, TYPO3, Design Science Research, Supply-Chain-Sicherheit

---

Abstract (English)

AI coding agents such as Claude Code, Cursor, and Gemini CLI increasingly consume domain knowledge through Agent Skills – portable Markdown knowledge packages following an open specification supported by roughly 30 agents. Today, these skills are distributed mainly through horizontal directories optimized for volume rather than verification: a Snyk security analysis found critical issues – from prompt injection to malware – in about 13 % of the publicly listed skills it examined. At the same time, established CMS ecosystems such as TYPO3 lack a curated, vertical alternative.

Following the design science research paradigm, this thesis designs a curated agent skills directory for the TYPO3 ecosystem. From an analysis of registry precedents (TER/Packagist, Drupal.org, npm, the VS Code Marketplace, HACS) and a stakeholder study, a requirements catalogue (A1–A12) is derived. Four artefacts are then designed: a git-first architecture with a static index and multi-channel distribution; a governance model with a four-stage review pipeline and an active recall (yank) mechanism; a legal framework (trademark law, licensing architecture, the Digital Services Act, the new EU Product Liability Directive) with legally robust badge semantics; and an operating model following the Packagist precedent ("endorsed operator").

Evaluation through an adversarial gap analysis identifies four material risks – scheduled trust decay across LTS cycles, an ownership contradiction, non-contractual liability, and operator capacity limits – and feeds them back into the design. The central finding: a vertical directory is defensible against horizontal catalogues precisely when it organizes trust as a verified, dated, and revocable process – not as an assertion.

Keywords: agent skills, AI-assisted software engineering, software registries, curation, trust infrastructure, TYPO3, design science research, supply chain security

---

Wie diese Arbeit zu lesen ist

Die Arbeit ist auf Lesbarkeit hin geschrieben. Drei Konventionen helfen bei der Navigation:

• Jedes Kapitel beginnt mit einem Kasten Kernaussagen und endet mit einem Zwischenfazit. Wer wenig Zeit hat, liest nur diese Elemente sowie Kapitel 10 und 11.
• Der Anforderungskatalog A1–A12 (Kapitel 4) und die Lehren L1–L5 (Kapitel 3) werden in der gesamten Arbeit als Referenzpunkte verwendet; die Abdeckungsmatrix in Kapitel 10 führt beide zusammen.
• Nummerische Quellenverweise [1]–[27] verweisen auf das Literaturverzeichnis am Ende.

---

Inhaltsverzeichnis

1. Einleitung – Problemstellung, Forschungsfragen, Methodik, Aufbau
2. Grundlagen – Agent Skills und das TYPO3-Ökosystem
3. Registries als Vertrauensinfrastruktur – Präzedenzfälle und verwandte Systeme
4. Anforderungsanalyse – Stakeholder, Nutzungsszenarien und Vertrauensbedarfe
5. Systementwurf – Architektur des kuratierten Verzeichnisses
6. Governance-Modell – Kuratierung, Namensräume und Sicherheitsprozesse
7. Rechtlicher Rahmen – Marke, Lizenzen, Plattformpflichten und Haftung
8. Betreibermodell und ökonomische Tragfähigkeit
9. Einführungsstrategie – Community, Kommunikation und Roadmap
10. Evaluation und Risikoanalyse – Belastbarkeit des Entwurfs
11. Fazit und Ausblick

Anhang A: Glossar · Literaturverzeichnis

---

---

1 Einleitung

Kernaussagen dieses Kapitels

• Agent Skills verschieben die Frage „Was weiß mein KI-Coding-Agent?" von der Modellwahl zur Wissensdistribution – und schaffen damit ein neues, weitgehend ungeprüftes Einfallstor in Entwicklungsumgebungen.
• Horizontale Skill-Verzeichnisse optimieren auf Volumen; ihre strukturelle Kuratierungslücke ist empirisch belegt und für vertikale Ökosysteme wie TYPO3 nicht akzeptabel.
• Die Arbeit entwirft nach dem Design-Science-Paradigma ein kuratiertes, vertikales Verzeichnis und evaluiert dessen Belastbarkeit entlang von vier Forschungsfragen.

1.1 Problemstellung

Softwareentwicklung mit KI-Coding-Agents ist 2026 Alltag. Werkzeuge wie Claude Code, Cursor oder Gemini CLI erledigen Implementierungs-, Migrations- und Prüfaufgaben weitgehend selbstständig – vorausgesetzt, sie verfügen über das richtige Fachwissen. Dieses Wissen erreicht die Agents zunehmend in Form von Agent Skills: versionierbaren Markdown-Wissenspaketen nach einer offenen Spezifikation [2], die von rund 30 Agents unterstützt wird. Ein Skill kann einem Agent beibringen, wie eine TYPO3-Extension korrekt auf die aktuelle LTS-Version migriert wird, wie Barrierefreiheitsprüfungen ablaufen oder welche Konventionen ein Projekt verlangt [1].

Mit der Verbreitung entsteht ein Distributionsproblem, das aus der Geschichte der Software-Registries wohlbekannt ist – und eine Verschärfung, die neu ist. Bekannt ist das Muster: Wo Pakete zentral auffindbar werden, entstehen Kataloge; wo Kataloge auf Wachstum optimieren, erodiert die Prüfung. Neu ist die Angriffsfläche: Ein Agent Skill benötigt keinen ausführbaren Code, um Schaden anzurichten. Bereits die Prosa einer SKILL.md kann einen Agent durch Prompt Injection zu unerwünschtem Verhalten anleiten. Eine Analyse von Snyk fand bei rund 13 % der untersuchten, öffentlich gelisteten Skills kritische Sicherheitsprobleme [7]. Die dominierenden horizontalen Verzeichnisse indexieren dennoch ungeprüft [5], [6] – eines stellt ausdrücklich klar, keine Sicherheit zu zertifizieren [6].

Für ein vertikales Software-Ökosystem wie TYPO3 – ein agenturgetriebenes Enterprise-CMS mit starker Verankerung im deutschsprachigen Raum – ist diese Lage doppelt unbefriedigend. Erstens fehlt jede fachliche Prüfung: Kein horizontales Verzeichnis testet, ob ein Skill mit TYPO3 v14.3 LTS [22] tatsächlich funktioniert. Zweitens fehlt die institutionelle Antwort: Anders als im Drupal-Ökosystem, wo bereits ein CI-validiertes Skills-Projekt auf der offiziellen Plattform existiert [8], gibt es für TYPO3 kein kuratiertes Verzeichnis. Die Lücke ist zugleich Risiko und Gestaltungsraum.

1.2 Forschungsfragen

Die Arbeit beantwortet vier aufeinander aufbauende Forschungsfragen:

Tabelle 1.1: Forschungsfragen und ihre Verortung in der Arbeit

1.3 Methodik

Die Arbeit folgt dem Design-Science-Research-Paradigma: Erkenntnis entsteht durch den Entwurf und die kritische Evaluation eines Artefakts, das ein reales Problem lösen soll. Der Erkenntnisprozess gliedert sich in vier Schritte:

1. Problemidentifikation durch Analyse der Skill-Distributionslandschaft und dokumentierter Sicherheitsvorfälle (Kapitel 2–3).
2. Anforderungserhebung aus einer Stakeholder-Analyse des TYPO3-Ökosystems, verdichtet zu einem expliziten Anforderungskatalog A1–A12 (Kapitel 4).
3. Artefakt-Entwurf in vier Dimensionen: Architektur (Kapitel 5), Governance (Kapitel 6), Recht (Kapitel 7) und Betreibermodell (Kapitel 8–9).
4. Evaluation in zwei Formen: erstens durch Präzedenzfall-Validierung – jede zentrale Entwurfsentscheidung wird gegen dokumentierte Erfolge und Misserfolge etablierter Registries geprüft; zweitens durch eine adversariale Gap-Analyse, die den Gesamtentwurf gezielt auf Widersprüche und blinde Flecken untersucht (Kapitel 10).

Empirische Grundlage sind öffentlich zugängliche Primärquellen (Spezifikationen, Richtlinien, Vorfallsberichte, offizielle Dokumentation; Stand Juli 2026) sowie der reale Startkatalog von 137 kuratierten Skills mit Provenienz- und Audit-Tooling [1]. Eine Feldevaluation des betriebenen Verzeichnisses liegt außerhalb des Untersuchungszeitraums; die daraus folgenden Grenzen der Aussagekraft werden in Kapitel 10 ausgewiesen.

1.4 Abgrenzung

Drei Abgrenzungen präzisieren den Gegenstand. Erstens behandelt die Arbeit die Distribution von Skills, nicht deren Autorenschaft: Wie ein fachlich guter Skill geschrieben wird, ist nicht Untersuchungsgegenstand. Zweitens wird kein neues Skill-Format entworfen; der Entwurf bleibt bewusst innerhalb der offenen Spezifikation [2], [3], um Portabilität nicht zu gefährden (Anforderung A1). Drittens ist das Artefakt ein Verzeichnis mit Kuratierung – kein Marktplatz mit Zahlungsabwicklung; die ökonomische Analyse in Kapitel 8 begründet diese Einschränkung.

1.5 Aufbau der Arbeit

Kapitel 2 legt die Grundlagen zu Agent Skills und dem TYPO3-Ökosystem. Kapitel 3 analysiert Registry-Präzedenzfälle und destilliert fünf übertragbare Lehren (L1–L5). Kapitel 4 erhebt die Anforderungen der Stakeholder und formuliert den Katalog A1–A12. Die Kapitel 5 bis 7 entwerfen das Artefakt in seinen drei Dimensionen Technik, Organisation und Recht. Kapitel 8 klärt Betreibermodell und Tragfähigkeit, Kapitel 9 die Einführung im Ökosystem einschließlich der Kapazitätsgrenzen des Betreibers. Kapitel 10 evaluiert den Gesamtentwurf und weist seine Limitationen aus. Kapitel 11 beantwortet die Forschungsfragen, benennt die Beiträge der Arbeit und skizziert den Ausblick.

1.6 Zwischenfazit

Die Ausgangslage lässt sich in einem Satz fassen: Agent Skills sind zur relevanten Wissensinfrastruktur der KI-gestützten Entwicklung geworden, ihre Distribution ist es noch nicht. Die dokumentierte Kuratierungslücke horizontaler Verzeichnisse trifft auf ein TYPO3-Ökosystem ohne eigene Antwort – ein klassisches Design-Science-Problem: real, relevant und gestaltbar. Die folgenden Kapitel zeigen, dass die Lösung weniger eine technische als eine institutionelle Bauaufgabe ist.

---

2 Grundlagen: Agent Skills und das TYPO3-Ökosystem

Kernaussagen dieses Kapitels

• Agent Skills sind portable, Markdown-basierte Wissenspakete nach einer offenen Spezifikation; ihr Wirkprinzip der Progressive Disclosure unterscheidet sie grundlegend von MCP-Servern und CLI-Tools [2], [3].
• Rund 30 KI-Coding-Agents unterstützen die Spezifikation; die Distributionslandschaft ist jung, stark fragmentiert und fast ausschließlich horizontal organisiert — eine ökosystemspezifische Kuratierung fehlt bislang [2], [4], [5], [6].
• Das TYPO3-Ökosystem ist ein agenturgetriebenes Nischen-CMS mit DACH-Schwerpunkt, planbaren LTS-Zyklen (aktuell v14.3 LTS) und einer langen Registry-Tradition in Gestalt des TER [14], [22], [23].
• Der Startkatalog aus 137 kuratierten Skills, davon 31 TYPO3-spezifisch, liefert samt Provenienz-Tooling die empirische Basis für den Entwurf des Verzeichnisses [1].

2.1 Agent Skills: Format, Spezifikation und Wirkprinzip

Ein Agent Skill ist ein Ordner mit einer zentralen Datei SKILL.md: ein in Markdown verfasstes Wissenspaket, das ein KI-Coding-Agent — also ein Werkzeug wie Claude Code, Cursor oder Gemini CLI — in seinen Arbeitskontext laden kann. Die Struktur folgt einer offenen, herstellerunabhängigen Spezifikation, die unter agentskills.io gepflegt wird [2] und deren Referenzimplementierung öffentlich einsehbar ist [3]. Kern des Formats ist ein Frontmatter-Block in YAML, ein maschinenlesbarer Kopfbereich der Datei: Verpflichtend sind lediglich die Felder name und description; optional lassen sich license, compatibility, allowed-tools sowie eine frei belegbare metadata-Zuordnung von Zeichenkette zu Zeichenkette ergänzen [2]. Gerade diese offene Metadaten-Map ist für die vorliegende Arbeit zentral, denn sie erlaubt es, verzeichnisspezifische Angaben — etwa versionierte TYPO3-Kompatibilitätsaussagen im Sinne von Anforderung A2 (der Anforderungskatalog A1–A12 wird in Kapitel 4 hergeleitet) — unterzubringen, ohne die Portabilität des Formats zu verletzen (Anforderung A1). Neben SKILL.md kann ein Skill-Ordner Zusatzverzeichnisse wie scripts/, references/, assets/ oder examples/ enthalten; die Konformität einer Skill-Struktur lässt sich mit dem Werkzeug skills-ref automatisiert validieren [2], [3].

Das Wirkprinzip der Skills heißt Progressive Disclosure, also gestufte Offenlegung: Der Agent sieht zunächst nur Name und Kurzbeschreibung aller installierten Skills. Erst wenn eine Aufgabe zum beschriebenen Einsatzzweck passt, lädt er den vollständigen Anleitungstext, und referenzierte Zusatzdateien werden nur bei Bedarf nachgeladen [2]. Dieses Prinzip schont das begrenzte Kontextfenster des Sprachmodells und macht es überhaupt erst praktikabel, viele Dutzend Skills parallel zu installieren — eine Eigenschaft, die für ein Verzeichnis mit über hundert Einträgen konstitutiv ist [1].

Von zwei benachbarten Mechanismen sind Skills klar abzugrenzen. Ein MCP-Server ist ein laufender Dienst, der einem Agent über das Model Context Protocol — ein standardisiertes Schnittstellenprotokoll — konkrete Werkzeuge bereitstellt und über eine eigene Registry auffindbar ist [13]. Ein CLI-Tool ist ein ausführbares Programm, das der Agent über die Kommandozeile startet. Ein Skill hingegen besitzt keine eigene Laufzeitumgebung: Er wirkt deklarativ, indem seine Prosa das Verhalten des Agents anleitet. Daraus folgt eine sicherheitstechnische Besonderheit, die Kapitel 3 vertieft: Die primäre Angriffsfläche eines Skills ist der Text selbst, denn bereits die Anleitung kann eine Prompt Injection enthalten, also versteckte Instruktionen, die den Agent zu unerwünschtem Verhalten verleiten — Schadwirkung setzt keine Skripte voraus [7]. Tabelle 2.1 fasst die Abgrenzung zusammen.

Tabelle 2.1: Abgrenzung von Agent Skills gegenüber MCP-Servern und CLI-Tools

2.2 KI-Coding-Agents und die Distributionslandschaft

Die Spezifikation hat sich binnen kurzer Zeit als gemeinsamer Nenner der Werkzeuglandschaft etabliert: Rund 30 KI-Coding-Agents lesen das SKILL.md-Format, darunter Claude Code, Cursor, GitHub Copilot, Gemini CLI und Codex [2], [3]. Diese Breite ist die Geschäftsgrundlage jedes Verzeichnisses — und zugleich die Begründung für Anforderung A5, die eine Ein-Kommando-Installation über gängige Agents hinweg verlangt: Ein Skill, der nur in einem einzigen Client funktioniert, verfehlt den Kern des offenen Formats.

Die Distribution von Skills hat sich demgegenüber deutlich unübersichtlicher entwickelt. Von einem einzigen Verzeichnis im Dezember 2025 wuchs die Landschaft bis Mitte 2026 auf acht bis zwölf konkurrierende Angebote. Drei Archetypen lassen sich unterscheiden. Erstens kuratierte Beispielkataloge: Anthropic betreibt mit anthropics/skills einen bewusst klein gehaltenen Vorbildkatalog, der ausdrücklich kein Marktplatz sein will [4]. Zweitens horizontale Verzeichnisse, also themenübergreifende Kataloge: skills.sh von Vercel indexiert Skills quer über alle Domänen, bietet eine Installationsstatistik und die Kommandozeilen-Installation per npx skills add [5], [12]; SkillsMP arbeitet als GitHub-Scraper mit einem minimalen Popularitätsfilter und stellt ausdrücklich klar, keine Sicherheitsaussagen über die gelisteten Skills zu treffen [6]. Drittens dezentrale Selbstverwaltung: Jedes Git-Repository mit einer Manifestdatei kann als Plugin-Marktplatz für Claude Code dienen, ganz ohne zentrale Infrastruktur [11]. Tabelle 2.2 ordnet die Wege ein.

Tabelle 2.2: Distributionswege für Agent Skills im Überblick (Stand Juli 2026)

Das Muster ist deutlich: Scraper konkurrieren über Volumen, Kurator:innen über Vertrauen — und kein Anbieter besetzt bislang die Tiefe eines einzelnen Software-Ökosystems. Wie riskant ungeprüftes Volumen ist, zeigt eine Analyse von Snyk, nach der rund 13 Prozent der öffentlich gelisteten Skills kritische Sicherheitsprobleme aufweisen [7]. Diese Befunde und die daraus abzuleitenden Präzedenzlehren behandelt Kapitel 3 systematisch; hier genügt die Feststellung, dass die Lücke zwischen horizontaler Reichweite und vertikaler Prüftiefe genau der Raum ist, den das in Kapitel 5 entworfene vertikale Verzeichnis füllen soll.

2.3 Das TYPO3-Ökosystem als Untersuchungsgegenstand

TYPO3 ist ein quelloffenes Enterprise-Content-Management-System mit klarem Nischenprofil: Es dominiert nicht den Weltmarkt, ist aber im deutschsprachigen Raum — Deutschland, Österreich, Schweiz — fest verankert und wird dort vor allem von spezialisierten Agenturen für Behörden, Hochschulen und mittelständische Unternehmen eingesetzt. Diese Agenturzentrierung prägt die Kultur des Ökosystems: Professionelle Dienstleister tragen die Weiterentwicklung, organisiert über die TYPO3 Association als Mitgliederorganisation [27], die über ein Community Budget auch Vorhaben ohne direkten Erwerbszweck fördert [26].

Für die vorliegende Arbeit sind zwei Strukturmerkmale entscheidend. Erstens die planbaren Release-Zyklen: TYPO3 erscheint in Long-Term-Support-Versionen (LTS) mit definierten Wartungsfenstern; aktuelles LTS ist v14.3 vom April 2026 [22], [23]. Diese Taktung macht Kompatibilität zu einer datierbaren, überprüfbaren Aussage — die Grundlage der Anforderungen A2 und A11, die versionierte Kompatibilitätsangaben und Alterungstransparenz über LTS-Zyklen hinweg verlangen. Zweitens die Registry-Erfahrung der Community: Mit dem TYPO3 Extension Repository (TER) verfügt das Ökosystem seit Jahrzehnten über eine zentrale Erweiterungs-Registry samt Namensraumvergabe über Extension-Keys. Die Distributionsfunktion des TER ist inzwischen weitgehend an Composer und Packagist übergegangen; das TER-eigene Composer-Repository ist offiziell als veraltet markiert [14]. Bemerkenswert ist jedoch, was blieb: TER besteht als Vertrauens-, Auffindbarkeits- und Markenschicht fort. Diese Entkopplung von Discovery und Distribution ist einer der wichtigsten Präzedenzfälle für den Systementwurf und wird in Kapitel 3 vertieft.

Im Feld der Agent Skills existiert bislang keine offizielle TYPO3-Initiative. Die nächstliegende Aktivität ist der kuratierte Marktplatz der Agentur Netresearch mit rund 40 Skills zu TYPO3, PHP und angrenzenden Themen [9]. Zum Vergleich: Die Drupal-Community betreibt bereits ein offizielles, spezifikationskonformes Skills-Projekt auf ihrer zentralen Plattform [8] — ein Beleg dafür, dass CMS-Communities dieses Feld aktiv besetzen. Für TYPO3 ist die Position noch unbesetzt; die strategischen Konsequenzen daraus behandeln die Kapitel 6 und 9.

2.4 Der Startkatalog als empirische Basis

Design-Science-Arbeiten benötigen ein Artefakt-Fundament, an dem sich Anforderungen und Entwurfsentscheidungen konkretisieren lassen. Diese Rolle übernimmt hier der Startkatalog webconsulting-skills: eine öffentlich zugängliche, kuratierte Bibliothek von 137 Skills, gegliedert in 13 Themencluster [1]. Das mit 31 Skills größte Cluster ist TYPO3-spezifisch und deckt unter anderem Content Blocks, Testing, Extension-Upgrades, Security, Barrierefreiheit und Solr-Suche ab; die Skills zielen auf TYPO3 v14.x, einzelne decken zusätzlich v13 ab [1]. Damit ist der Katalog zugleich Machbarkeitsnachweis und Untersuchungsmaterial: An ihm lässt sich prüfen, ob Kuratierung in dieser Größenordnung mit vertretbarem Aufwand durchhaltbar ist.

Drei Eigenschaften des Katalogs sind für den späteren Entwurf besonders aufschlussreich. Erstens die Spezifikationstreue: Alle Skills folgen dem offenen SKILL.md-Format samt einem Progressive-Disclosure-Standard für Autor:innen und werden mit skills-ref validiert [1], [2] — die praktische Vorwegnahme von Anforderung A1. Zweitens das Provenienz-Tooling: Ein maschinenlesbares Quellenverzeichnis dokumentiert die Herkunft jedes Skills, eine CI-Prüfung (Continuous Integration, also automatisierte Prüfläufe bei jeder Änderung) verhindert das Entfernen von Attributionsblöcken, und ein dreistufiges Audit-Skript prüft Struktur, Provenienz-Drift und Optimierungslücken [1]. Zwölf Skills des TYPO3-Clusters sind nachweislich von Netresearch adaptiert und entsprechend attribuiert [1], [9] — gelebte Praxis der Anforderung A3. Drittens die Multi-Client-Installation: Ein Installationsskript verknüpft die Skills mit fünf Clients — Cursor, Claude Code, Gemini CLI, OpenAI Codex und Windsurf — und ein Aktualisierungsskript synchronisiert Upstream-Änderungen unter Erhalt der Attribution [1]; damit ist Anforderung A5 im Kleinen bereits demonstriert. Ergänzt wird dies durch ein geteiltes Lizenzmodell — MIT für Code, CC-BY-SA-4.0 für Inhalte, Drittlizenzen bleiben erhalten [1] —, dessen rechtliche Tragweite Kapitel 7 untersucht.

Der Katalog ist damit mehr als eine Sammlung: Er ist der empirische Prototyp des Verzeichnisses. Was ihm fehlt — publizierte Review-Kriterien (A7), ein Rückrufmechanismus (A6), geschützte Namensräume (A8) und datierte Kompatibilitätsnachweise (A2) —, markiert exakt die Lücke, die die Anforderungsanalyse in Kapitel 4 systematisiert und der Systementwurf in Kapitel 5 schließt.

2.5 Zwischenfazit

Agent Skills sind ein offenes, deklaratives Format, dessen Stärke — Portabilität über rund 30 Agents hinweg — zugleich seine Schwäche ist: Die Prosa selbst ist Angriffsfläche, und die vorhandenen horizontalen Verzeichnisse indexieren, ohne zu prüfen [2], [5], [6], [7]. Das TYPO3-Ökosystem bringt umgekehrt genau die Eigenschaften mit, die vertrauensstiftende Kuratierung begünstigen: datierbare LTS-Zyklen, eine agenturgetragene Professionalisierung und mit dem TER eine erprobte Registry-Kultur [14], [22], [23], [27]. Der Startkatalog belegt, dass spezifikationstreue Kuratierung mit Provenienznachweis in relevanter Größenordnung praktisch funktioniert [1]. Für den Entwurf folgt daraus: Das Verzeichnis muss die Offenheit des Formats bewahren (A1, A5), die Prüf- und Provenienzpraxis des Katalogs institutionalisieren (A3, A4) und die TYPO3-spezifische Versionslogik zum tragenden Unterscheidungsmerkmal machen (A2, A11) — die Präzedenzfälle dafür analysiert das folgende Kapitel 3.

---

3 Registries als Vertrauensinfrastruktur: Präzedenzfälle und verwandte Systeme

Kernaussagen dieses Kapitels

• Erfolgreiche Registries trennen Discovery und Vertrauen von der technischen Distribution: Das TER überlebte den Wandel zum Composer-Ökosystem als Vertrauens- und Sichtbarkeitsschicht, während Packagist die Auslieferung übernahm [14], [24].
• Drupal.org zeigt, dass einmaliges Vetting von Maintainer:innen mit günstigen, projektbezogenen Badges skalierbarer ist als eine aufwendige Einzelprüfung jedes Projekts [16].
• Vorfälle von npm bis zur Nx-Console-Kompromittierung belegen: Identitätsnachweise ersetzen keine Inhaltsprüfung, und kompromittierte Konten unterlaufen jede Code-Review [10].
• Skills verschärfen das Problem, weil bereits Prosa als Angriffsfläche wirkt; die Snyk-Analyse ToxicSkills fand bei rund 13 % öffentlich gelisteter Skills kritische Sicherheitsprobleme [7].
• Aus den Präzedenzfällen folgen fünf übertragbare Lehren (L1–L5), die die Entwurfsentscheidungen der Kapitel 5 bis 8 empirisch begründen.

Design-Science-Arbeiten gewinnen ihre Belastbarkeit nicht allein aus dem Artefakt, sondern aus der Wissensbasis, auf der es aufsetzt. Dieses Kapitel analysiert deshalb Registries und Verzeichnisse, die vergleichbare Vertrauensprobleme bereits gelöst — oder an ihnen gescheitert — sind. Die Auswahl umfasst das TYPO3-eigene Extension-Ökosystem (Abschnitt 3.1), das Governance-Modell von Drupal.org (3.2), dokumentierte Sicherheitsvorfälle in Paket- und Extension-Ökosystemen (3.3), skill-spezifische Vorfälle (3.4), horizontale Skill-Verzeichnisse (3.5) sowie das Koexistenzmodell von HACS im Home-Assistant-Ökosystem (3.6). Abschnitt 3.7 verdichtet die Befunde zu fünf Lehren, auf die sich die Anforderungsanalyse in Kapitel 4 und der Entwurf in den Kapiteln 5 bis 8 beziehen.

3.1 TER und Packagist: Entkopplung von Discovery, Vertrauen und Distribution

Das TYPO3 Extension Repository (TER) ist der naheliegendste Präzedenzfall, weil es dieselbe Zielgruppe adressiert wie das entworfene Verzeichnis. Das TER etablierte sich historisch über zwei Mechanismen: Es war lange der einzige Verbreitungskanal für Extensions, und es vergab mit den Extension-Keys einen zentralen Namensraum, der Eindeutigkeit und Zurechenbarkeit garantierte. Mit der Durchsetzung von Composer als Standardwerkzeug der PHP-Welt verlor das TER jedoch seine Rolle als Distributionskanal: Die kanonische Auflösung von Paketen wanderte zu Packagist, das als professionell betriebene Infrastruktur die technische Auslieferung übernimmt [24]. Das TER-eigene Composer-Repository ist inzwischen als veraltet markiert; die offizielle Dokumentation empfiehlt den direkten Bezug über Packagist [14].

Entscheidend ist, was das TER trotz dieses Funktionsverlusts behielt: Es blieb die Sichtbarkeits-, Vertrauens- und Markenschicht des Ökosystems — mit Verknüpfung zu Packagist und automatisierter Publikation über Werkzeuge des TYPO3-Ökosystems. Discovery und Vertrauen einerseits, Distribution andererseits erwiesen sich als entkoppelbare Schichten. Für den Entwurf folgt daraus unmittelbar die in Kapitel 4 formulierte Anforderung A5: Das Verzeichnis muss nicht selbst ausliefern, sondern kann die Installation an bestehende Mechanismen der KI-Coding-Agents delegieren und sich auf Kuratierung, Metadaten und Auffindbarkeit konzentrieren. Ebenso stützt der Extension-Key-Mechanismus die Anforderung A8: Ein verlässlich verwalteter Namensraum war ein wesentlicher Teil des TER-Vertrauenskapitals.

3.2 Drupal.org: Vetting von Maintainer:innen statt Projekt-Review

Drupal.org stand vor einem Skalierungsproblem, das jedes kuratierte Verzeichnis kennt: Eine gründliche menschliche Prüfung jedes einzelnen Projekts erzeugt lange Warteschlangen und entmutigt Beitragende. Die Antwort war der Wechsel von der projektbezogenen Aufnahmeprüfung zum Security Advisory Opt-in: Menschen werden einmalig geprüft, bevor sie stabile Releases mit Sicherheitsabdeckung veröffentlichen dürfen; danach entscheiden sie pro Projekt über die Teilnahme an der Sicherheitsabdeckung, die als sichtbares, binäres Badge kommuniziert und von einem ehrenamtlichen Security-Team getragen wird [16]. Der teure Prüfschritt wird also von der wachsenden Menge der Artefakte auf die langsamer wachsende Menge der Autor:innen verlagert.

Bemerkenswert ist zudem, dass Drupal die Übertragung dieses Modells auf Agent Skills bereits begonnen hat: Mit dem offiziellen Projekt „Agentic Skills" existiert auf Drupal.org ein Katalog, der der offenen Spezifikation folgt und Beiträge automatisiert in der Continuous Integration validiert [8]. Ein CMS-Ökosystem organisiert Skill-Kuratierung damit erstmals institutionell — ein Beleg dafür, dass vertikale Fachgemeinschaften diese Aufgabe übernehmen, wenn horizontale Angebote sie nicht leisten. Für den Entwurf begründet dieser Präzedenzfall die Anforderungen A3 und A7: Provenienz hängt an geprüften Personen und Organisationen, und die Prüfkriterien samt Bearbeitungszusagen müssen publiziert sein, damit das Badge etwas bedeutet.

3.3 Sicherheitsvorfälle in Paket- und Extension-Ökosystemen

Die Geschichte der Paket-Registries liest sich als Katalog von Vertrauensbrüchen. Im npm-Ökosystem markieren vier Vorfälle jeweils eine eigene Fehlerklasse: left-pad (2016) zeigte, dass das unkontrollierte Zurückziehen von Paketen ganze Abhängigkeitsketten bricht — und motivierte restriktive Unpublish-Regeln; event-stream (2018) demonstrierte die Übergabe eines vertrauenswürdigen Projekts an bösartige Maintainer:innen; ua-parser-js (2021) die Übernahme eines legitimen Kontos; der Shai-Hulud-Wurm (2025) schließlich selbstreplizierende Kompromittierung entlang der Lieferkette. Die Gegenmaßnahmen — verpflichtende Zwei-Faktor-Authentifizierung für reichweitenstarke Konten, signierte Provenienznachweise, abgesicherte Publikationswege — setzen sämtlich beim Publikationsakt an, nicht bei der nachträglichen Inhaltsprüfung.

Der Marketplace von Visual Studio Code liefert den jüngsten und für Badge-Semantik lehrreichsten Fall: Allein 2025 mussten dort über hundert bösartige Erweiterungen entfernt werden, und im Mai 2026 wurde die Nx-Console-Erweiterung — rund 2,2 Millionen Installationen, versehen mit einem Verified-Publisher-Badge — über das kompromittierte Konto einer angestellten Person trojanisiert [10]. Das Badge bestätigte lediglich den Domainbesitz der publizierenden Organisation, nicht die Unbedenklichkeit des Inhalts; genau diese Lücke zwischen wahrgenommener und tatsächlicher Aussage erzeugte fehlgeleitetes Vertrauen. Ergänzend zeigt das WordPress-Plugin-Verzeichnis eine Governance-Fehlerklasse ohne Angreifer:innen von außen: 2024 übernahm dort der Verzeichnisbetreiber selbst im Zuge eines kommerziellen Konflikts den Namensraum eines fremden Plugins — Machtkonzentration ohne vorab publizierte, neutrale Streitregeln ist ein eigenes Risiko. Für den Entwurf begründen diese Fälle die Anforderungen A4 und A6 (Prüfung vor Publikation, aktiver Rückruf per Yank mit Warnung installierter Clients), A8 (geschützte Namensräume mit publizierten Streitregeln) und A10 (Badges, die präzise Prozess- statt pauschaler Ergebnisaussagen treffen).

3.4 Skill-spezifische Vorfälle: ToxicSkills und Prosa als Angriffsfläche

Dass sich die Fehlerklassen der Paket-Welt auf Agent Skills übertragen — und dort verschärfen —, ist inzwischen empirisch belegt. Die Snyk-Untersuchung ToxicSkills analysierte öffentlich gelistete Skills eines unkuratierten Katalogs und fand bei rund 13 % kritische Sicherheitsprobleme, darunter Skills, die als Infostealer Zugangsdaten und Schlüsselmaterial abgreifen [7]. Die strukturelle Verschärfung gegenüber klassischen Paketen liegt in der Natur des Formats: Ein Skill ist im Kern natürlichsprachige Anweisung an einen KI-Coding-Agent. Prompt Injection — das Einschleusen manipulierender Anweisungen in Inhalte, die der Agent als vertrauenswürdig behandelt — funktioniert damit bereits in reiner Prosa, ganz ohne ausführbaren Code [7]. Ein Review-Prozess, der nur Skripte statisch analysiert, prüft folglich die falsche Hälfte des Artefakts.

Für den Entwurf ist dies der unmittelbarste Befund des Kapitels: Anforderung A4 verlangt ausdrücklich die Prüfung von Prosa und Skripten vor Publikation, und die in Kapitel 5 entworfene Review-Pipeline muss neben statischer Code-Analyse eine systematische Prüfung der Anweisungstexte auf Injektionsmuster enthalten. Zugleich stützt der Befund die Transparenzanforderung A7: Ein Verzeichnis, das Sicherheit verspricht, muss seine Prüfmethodik offenlegen, damit die Aussagekraft der Prüfung von Dritten eingeordnet werden kann.

3.5 Horizontale Skill-Verzeichnisse und die strukturelle Kuratierungslücke

Seit Ende 2025 ist eine schnell wachsende Landschaft horizontaler Skill-Verzeichnisse entstanden. Zwei Vertreter markieren die Pole: skills.sh von Vercel kombiniert ein Install-Ranking mit einem Ein-Kommando-Installationsweg und listet eine Skill-Menge im hohen fünfstelligen Bereich, verzichtet jedoch auf inhaltliche Prüfung und auf ein erkennbares Geschäftsmodell [5]. SkillsMP indexiert als GitHub-Scraper nach eigenen Angaben über zwei Millionen Skills, filtert lediglich über ein Mindestmaß an Repository-Popularität und erklärt ausdrücklich, keine Sicherheitszusagen zu treffen [6]. Damit bestätigt sich das bereits in Kapitel 2.2 skizzierte Muster: Scraper konkurrieren über Volumen, nicht über Vertrauen.

Die Kuratierungslücke dieser Angebote ist dabei nicht Nachlässigkeit, sondern strukturell. Ein horizontales Verzeichnis kann Skills auflisten und zählen, aber nicht fachlich testen: Es besitzt weder die Domänenkompetenz noch die Infrastruktur, um einen TYPO3-Skill gegen eine reale TYPO3-Installation zu validieren oder eine datierte Kompatibilitätsaussage je LTS-Version zu treffen — genau die Leistungen, die die Anforderungen A2 und A11 beschreiben. Ein generisches Themen-Tag „typo3" ersetzt keine geprüfte LTS-Matrix. Die in Kapitel 2 eingeführte kuratierte Bibliothek mit 137 Skills, davon 31 TYPO3-spezifisch [1], sowie der kuratierte Katalog von Netresearch [9] zeigen, dass diese Lücke bislang von einzelnen Agenturen gefüllt wird — verteilt, ohne gemeinsame Governance und ohne gemeinsame Prüfstandards. Ebendiese Lücke ist die Marktposition des entworfenen vertikalen Verzeichnisses.

3.6 HACS und die Open Home Foundation: Koexistenz als Betriebsmodell

Der Home Assistant Community Store (HACS) beantwortet eine Frage, die sich dem entworfenen Verzeichnis gegenüber der TYPO3 Association stellen wird: Kann ein community-getragenes Verzeichnis dauerhaft neben offiziellen Strukturen bestehen? HACS gelingt dies seit Jahren, weil es zwei Bedingungen erfüllt: Es ist schneller und niederschwelliger als der offizielle Kanal, und es kommuniziert seinen Status ehrlich — Inhalte sind erkennbar als „nicht offiziell unterstützt" gekennzeichnet, sodass keine falsche Autoritätsvermutung entsteht [25]. Die organisatorische Anbindung an die Open Home Foundation zeigt zudem einen Pfad, wie ein zunächst privates Community-Projekt in eine neutrale, gemeinnützige Trägerschaft überführt werden kann [25]. Für das Betreibermodell in Kapitel 8 und die Einführungsstrategie in Kapitel 9 ist HACS damit der zentrale Referenzfall: Koexistenz ist möglich, wenn Statusklarheit und Geschwindigkeit zusammenkommen — und eine spätere Übergabe an eine Ökosystem-Institution von Beginn an mitgedacht wird.

3.7 Fünf übertragbare Lehren

Aus den analysierten Präzedenzfällen lassen sich fünf Lehren ableiten, die im weiteren Verlauf der Arbeit als L1 bis L5 referenziert werden:

1. L1 — Schichten entkoppeln: Discovery und Vertrauen sind vom Distributionskanal trennbar; das Verzeichnis besetzt die Vertrauensschicht und delegiert Auslieferung an bestehende Installationswege der KI-Coding-Agents (TER/Packagist [14], [24]; Grundlage für die Architektur in Kapitel 5 sowie A1 und A5).
2. L2 — Menschen prüfen, Artefakte badgen: Einmaliges Vetting von Maintainer:innen skaliert besser als Einzelprüfung jedes Artefakts; projektbezogene Badges machen die Abdeckung sichtbar (Drupal.org [8], [16]; Grundlage für das Governance-Modell in Kapitel 6 sowie A3 und A7).
3. L3 — Kontokompromittierung einkalkulieren: Die Übernahme vertrauenswürdiger Konten schlägt jede Inhaltsprüfung; nötig sind abgesicherte Publikationswege, Provenienznachweise, erneute Prüfung jeder Version und ein aktiver Rückrufmechanismus (npm-Vorfälle, Nx Console [10]; Grundlage für die Sicherheitsprozesse in Kapitel 6 sowie A4 und A6).
4. L4 — Prosa ist Angriffsfläche: Skills können bereits über natürlichsprachige Anweisungen angreifen; Review muss Anweisungstexte und Skripte gleichermaßen erfassen und die Methodik offenlegen (ToxicSkills [7]; Grundlage für die Review-Pipeline in Kapitel 5 und die Badge-Semantik in Kapitel 7 gemäß A4 und A10).
5. L5 — Governance vor Wachstum: Namensraum-, Streit- und Übergaberegeln müssen vor dem Wachstum publiziert sein, und ein Pfad in neutrale, community-nahe Trägerschaft beugt Machtkonzentration vor (WordPress-Namensraumkonflikt, HACS/Open Home Foundation [25]; Grundlage für Kapitel 6 und 8 sowie A8 und A12).

Tabelle 3.1: Registry-Präzedenzfälle, ihre Governance-Modelle und die daraus abgeleiteten Lehren L1–L5.

3.8 Zwischenfazit

Die Präzedenzfallanalyse zeigt, dass die Vertrauensprobleme eines Skill-Verzeichnisses nicht neu, sondern in Paket- und Extension-Ökosystemen wiederholt durchlebt worden sind — und dass Skills die bekannten Fehlerklassen um die Angriffsfläche der Prosa erweitern [7]. Kein untersuchtes horizontales Verzeichnis schließt die Kuratierungslücke für ein CMS-Ökosystem; Drupal belegt zugleich, dass vertikale Fachgemeinschaften diese Aufgabe institutionell übernehmen können [8]. Die fünf Lehren L1 bis L5 bilden damit die empirische Brücke dieser Arbeit: Sie fließen in Kapitel 4 als Begründung der Anforderungen A1 bis A12 ein, strukturieren in Kapitel 5 die Architekturentscheidungen, in Kapitel 6 das Governance-Modell und in Kapitel 8 das Betreibermodell. Der Entwurf muss folglich nicht bei null beginnen, sondern kann erprobte Mechanismen — Schichtentrennung, Maintainer-Vetting, Provenienzpflicht, Prosa-Scanning und vorab publizierte Governance — auf den Skill-Kontext übertragen.

---

4 Anforderungsanalyse: Stakeholder, Nutzungsszenarien und Vertrauensbedarfe

Kernaussagen dieses Kapitels

• Die Anforderungen an das Verzeichnis ergeben sich aus drei Perspektiven: nutzende Entwickler:innen, beitragende Autor:innen und Agenturen sowie die Betreiberseite mit begrenzter Kuratierungskapazität.
• Vertrauen ist das dominierende Bedarfsmuster: Sicherheit der Skills, Vertraulichkeit von Kundencode und datierte, versionierte Kompatibilitätsaussagen wiegen für die Zielgruppen schwerer als Katalogbreite.
• Der Nutzungs-Funnel von Entdecken bis Beitragen übersetzt diese Bedarfe in konkrete Systemfunktionen und macht Lücken bestehender horizontaler Verzeichnisse sichtbar.
• Ergebnis ist der kanonische Anforderungskatalog A1–A12 (Tabelle 4.2), der als Scharnier zwischen Problemanalyse und den Entwurfskapiteln 5 bis 8 dient.

Kapitel 2 hat Agent Skills als portable Markdown-Wissenspakete nach offener Spezifikation eingeführt [2], Kapitel 3 hat gezeigt, dass bestehende horizontale Verzeichnisse wie skills.sh und SkillsMP ohne Prüfschranke arbeiten [5], [6] und dass etablierte Registries wie das TER ihre Vertrauensfunktion über Jahre aufgebaut haben [14], [15]. Dieses Kapitel leitet daraus systematisch ab, welche Anforderungen ein kuratiertes, vertikales Verzeichnis für das TYPO3-Ökosystem erfüllen muss. Methodisch folgt die Analyse dem Design-Science-Vorgehen: Zunächst werden die Stakeholder-Gruppen mit ihren Aufgaben und Einwänden charakterisiert (4.1–4.3), anschließend werden Nutzungsszenarien entlang eines Adoptions-Funnels durchgespielt (4.4), und schließlich wird der Anforderungskatalog A1–A12 konsolidiert (4.5).

4.1 Nutzende Entwickler:innen: Aufgaben, Einwände, Vertrauensbedarfe

Die primäre Zielgruppe des Verzeichnisses sind Entwickler:innen, die TYPO3-Projekte mit KI-Coding-Agents wie Claude Code oder Cursor bearbeiten. Die Analyse unterscheidet vier Entwickler-Personas sowie eine sekundäre redaktionelle Persona. Für jede Persona wird der Job-to-be-done — die konkrete Aufgabe, für deren Erledigung das Verzeichnis „angeheuert" wird — den zentralen Einwänden gegenübergestellt.

Tabelle 4.1: Personas der nutzenden Seite mit Jobs-to-be-done und Einwänden

Drei Einwandsmuster ziehen sich durch alle Personas. Erstens die Sicherheitsfrage: Der Befund, dass rund 13 % öffentlich gelisteter Skills kritische Sicherheitsprobleme aufweisen [7], ist für Tech-Leads kein abstraktes Risiko, sondern ein konkretes Beschaffungshindernis — ein Skill ist eine Instruktionsdatei, die das Verhalten eines Agents mit Zugriff auf Kundencode steuert. Zweitens die Vertraulichkeitsfrage: Agenturen arbeiten unter Geheimhaltungsvereinbarungen und müssen belegen können, dass ein installierter Skill keinen zusätzlichen Datenabfluss erzeugt. Die Antwort des Entwurfs lautet, dass Skills lokale Markdown-Dateien sind, die vom ohnehin genutzten Agent gelesen werden; das Verzeichnis fügt keinen eigenen Datenpfad hinzu, und Skills mit ausführbaren Skripten erhalten eine sichtbare Kennzeichnung und werden zeilenweise geprüft. Drittens die Aktualitätsfrage: TYPO3-Wissen altert entlang der LTS-Zyklen [22], [23]; eine Kompatibilitätsaussage ohne Datum und Versionsbezug ist für Projektentscheidungen wertlos. Aus diesen Mustern folgen unmittelbar die Anforderungen an Security-Review (A4), Provenienz (A3), Kompatibilitätsmatrix (A2), Alterungstransparenz (A11) und datenschutzkonforme Telemetrie (A9) — Letztere ist im DACH-Raum, dem Kerngebiet des TYPO3-Ökosystems, ein eigenständiges Argument und nicht bloß eine Pflichtübung.

4.2 Beitragende Autor:innen und Agenturen

Die zweite Stakeholder-Gruppe sind jene, die Skills einreichen: einzelne Autor:innen, TYPO3-Agenturen und bestehende Skill-Maintainer:innen wie Netresearch, deren Marketplace bereits als Präzedenzfall dient [9]. Da Skill-Autor:innen fast ausnahmslos Entwickler:innen sind, erwarten sie einen Einreichungsweg über Pull Requests statt über Webformulare: Diff-basierte Reviews, öffentliche Diskussionsstränge und CI-Prüfungen sind ihnen vertraut und erzeugen Provenienz als Nebenprodukt. Anthropics eigener kuratierter Beispielkatalog arbeitet nach demselben Muster manueller Prüfung [4], während skills.sh auf jede Sicherheitsprüfung verzichtet [5] — genau diese Lücke ist die Marktöffnung des vorliegenden Entwurfs.

Beitragende formulieren drei Erwartungen. Erstens Planbarkeit: Publizierte Aufnahmekriterien und verbindliche Bearbeitungsfristen (Review-SLAs, also zugesagte Antwortzeiten) sind selbst ein Beitragsanreiz, weil sie die Einreichung kalkulierbar machen (A7). Zweitens Anerkennung: Attribution muss über den gesamten Lebenszyklus erhalten bleiben, auch bei Übernahme verwaister Skills; Autor:innenprofile und Installationsstatistiken machen Beiträge sichtbar (A3). Drittens Namensräume: Agenturen wollen unter verifiziertem Namen publizieren (etwa netresearch/typo3-solr-tuning), während generische Slugs wie typo3-seo an die erste angenommene, funktionierende Einreichung vergeben werden — verdient statt reserviert. Das vermeidet das aus dem TER bekannte Squatting von Extension-Keys und überträgt zugleich dessen bewährte Regel, dass Eigentumsübergänge die Zustimmung der bisherigen Eigentümer:innen erfordern (A8); die Details regelt Kapitel 6. Namensräume, die eine Billigung durch die TYPO3 GmbH oder die TYPO3 Association suggerieren, bleiben reserviert, denn die Markenpolitik des Projekts untersagt die Verwendung von „TYPO3" in Produkt- und Domainnamen ohne Genehmigung [17], [18]; die markenrechtliche Absicherung behandelt Kapitel 7.

4.3 Betreiberperspektive: Kuratierungsaufwand und Skalierung des Reviews

Kuratierung ist per Definition menschliche Arbeit, und menschliche Arbeit skaliert nicht beliebig. Die Aufwandsschätzung aus der Betreiberanalyse setzt für ein vollständiges Review einer neuen Einreichung 60–90 Minuten an — dominiert vom Funktionstest gegen ein reales TYPO3-v14.3-Projekt. Mit wachsendem Einreichungsvolumen steigt der Wochenaufwand von wenigen Stunden auf ein Niveau, das zusätzliche Kategorie-Maintainer:innen, eine beschleunigte Spur für vertrauenswürdige Autor:innen und schließlich bezahlte redaktionelle Kapazität erfordert; die detaillierte Dimensionierung nach Betriebsstufen leistet Kapitel 6.3 (Tabelle 6.2).

Für den Anforderungskatalog folgt daraus zweierlei. Erstens muss die Sicherheitsprüfung zweistufig sein: Automatisierte Prüfungen — Secret-Scanner, Allowlists für ausgehende URLs, Deny-Patterns gegen destruktive Kommandos und Prompt-Injection-Zeichenketten, also in Prosa versteckte Manipulationsanweisungen an den Agent — filtern maschinell Erkennbares, bevor menschliche Reviews Prosa und Skripte inhaltlich prüfen (A4). Ein Verzeichnis, das jede Zeile ausschließlich manuell prüft, skaliert nicht; eines, das nur automatisiert prüft, verfehlt den Anspruch der Kuratierung. Zweitens muss der Betrieb dauerhaft tragfähig sein, ohne den öffentlichen Kernkatalog hinter eine Bezahlschranke zu legen — die TYPO3-Community honoriert offene Infrastruktur, und Fördermodelle wie das Community-Budget der TYPO3 Association setzen Gemeinnützigkeit der Kernleistung voraus [26], [27] (A12); das Betreibermodell entwickelt Kapitel 8. Auch der Sicherheitsprozess selbst ist eine Betreiberanforderung: Nach dem Vorbild des TYPO3 Security Teams [15] braucht das Verzeichnis einen Meldeweg, koordinierte Advisories und einen aktiven Rückrufmechanismus (A6), den Kapitel 6 als Yank-Prozess ausarbeitet.

4.4 Nutzungsszenarien entlang des Funnels

Die Stakeholder-Bedarfe lassen sich zu einem sechsstufigen Nutzungs-Funnel verdichten, der jede Phase der Adoption mit einer Systemfunktion verknüpft.

Entdecken. Nutzer:innen finden das Verzeichnis über Suchmaschinenseiten je Skill, über die Listung in horizontalen Verzeichnissen [5] und über TYPO3-eigene Kanäle (Slack, Camps, typo3.org). Voraussetzung ist, dass Skills im portablen Standardformat vorliegen und damit überall anschlussfähig bleiben (A1) [2], [3].

Bewerten. Die Skill-Detailseite ist die eigentliche Vertrauensseite: Kuratierungs-Badge mit Datum und benannter Prüfperson, TYPO3-Kompatibilitätsmatrix (A2), Provenienz und Lizenz (A3) sowie der Freshness-Status, der die Aktualität des Kompatibilitätsnachweises über LTS-Zyklen hinweg ausweist (A11) [23]. Das Badge muss dabei den Prüfprozess dokumentieren, nicht ein fehlerfreies Ergebnis zusichern — eine rechtlich erhebliche Unterscheidung angesichts der neuen EU-Produkthaftungsregeln für Software [19], die Kapitel 7 vertieft (A10). Auf Sternebewertungen verzichtet der Entwurf bewusst: Bei Nischenreichweite sind sie statistisch bedeutungslos und manipulierbar; verlinkte Issues sind das belastbarere Signal.

Installieren. Die Analyse der Client-Landschaft zeigt fünf verschiedene Installationssemantiken — von Skill-Ordnern in Claude Code über Plugin-Marktplatz-Manifeste [11] bis zu Clients, die nur Verweisdateien lesen. Diese Heterogenität muss hinter einem einzigen kanonischen Kommando verschwinden, wie es die Skills-CLI agent-übergreifend ermöglicht [12] (A5); rund 30 Agents unterstützen die zugrunde liegende Spezifikation [2].

Aktivieren. Der erste Erfolg muss innerhalb von zehn Minuten erreichbar sein — exemplarisch: eine TYPO3-Extension rein lesend auf v14-Konformität prüfen. Der Verzicht auf schreibende Operationen beim Erstkontakt entschärft den Einwand „Zerstört die KI das Projekt?" konstruktiv statt rhetorisch.

Beibehalten. Ein monatlicher Digest kommuniziert Kompatibilitätsänderungen entlang der TYPO3-Releases [22]; Update-Mechanismen prüfen bei jeder Synchronisation eine signierte Rückrufliste und warnen bei zurückgezogenen Versionen (A6) — ein Mechanismus, den horizontale Verzeichnisse bislang nicht bieten [5].

Beitragen. Jede Skill-Seite führt in eine Beitragsleiter von der Fehlermeldung über Pull Requests bis zur Co-Maintainer:innenschaft; transparente Kriterien (A7) und verdiente Namensräume (A8) machen den Aufstieg planbar.

4.5 Der kanonische Anforderungskatalog A1–A12

Die Befunde aus 4.1 bis 4.4 verdichten sich zu zwölf Anforderungen. Sie bilden den Bewertungsmaßstab für den Systementwurf (Kapitel 5), das Governance-Modell (Kapitel 6), den rechtlichen Rahmen (Kapitel 7) und das Betreibermodell (Kapitel 8) und werden in Kapitel 10 zur Evaluation des Gesamtentwurfs herangezogen.

Tabelle 4.2: Kanonischer Anforderungskatalog A1–A12 mit Stakeholder-Evidenz und Quellen

Der Katalog ist bewusst als Vertrauenskatalog gebaut: Kein einziger Eintrag fordert Katalogbreite oder Wachstumsmechanik. Das unterscheidet das entworfene Verzeichnis strukturell von horizontalen Verzeichnissen, deren Wettbewerbslogik auf Masse beruht [5], [6], und positioniert es in der Tradition der in Kapitel 3 analysierten Registries, die ihre Existenzberechtigung aus geprüfter Qualität beziehen.

4.6 Zwischenfazit

Die Anforderungsanalyse zeigt ein konsistentes Bild: Alle drei Stakeholder-Gruppen artikulieren primär Vertrauensbedarfe — Sicherheit und Vertraulichkeit auf der Nutzungsseite, Planbarkeit und Anerkennung auf der Beitragsseite, Skalierbarkeit der Prüfarbeit auf der Betreiberseite. Der Nutzungs-Funnel übersetzt diese Bedarfe in konkrete Funktionen und macht sichtbar, dass die kritischen Lücken bestehender Verzeichnisse in der Bewertungs-, Rückruf- und Alterungsphase liegen, nicht in der Entdeckungsphase. Der daraus abgeleitete Katalog A1–A12 bildet das Scharnier der Arbeit: Kapitel 5 entwirft die Architektur gegen diese Anforderungen, Kapitel 6 bis 8 operationalisieren Governance, Recht und Betrieb, und Kapitel 10 misst den Gesamtentwurf an ihnen. Für den Entwurf folgt daraus die Leitentscheidung, Kuratierungstiefe konsequent vor Katalogbreite zu priorisieren.

---

5 Systementwurf: Architektur des kuratierten Verzeichnisses

Kernaussagen dieses Kapitels

• Der Entwurf folgt einem Git-first-Prinzip: Ein Monorepo ist die alleinige Quelle der Wahrheit, ein CI-generierter statischer Index bildet den öffentlichen Vertrag und zugleich die Read-API; eine Datenbank wird erst mit authentifiziertem Self-Service-Publishing eingeführt.
• Ein spezifikationskonformer Metadaten-Standard mit namespaced Frontmatter-Feldern macht TYPO3-Kompatibilitätsaussagen versioniert, datiert und maschinenlesbar, ohne die Portabilität der Skills zu gefährden (A1–A3).
• Mehrschichtige Qualitäts-Gates in der CI prüfen Prosa und Skripte gleichermaßen — von Schema-Validierung über Prompt-Injection-Linting bis zu einem Eval-Harness gegen ein reales TYPO3 v14.3 LTS in DDEV (A4).
• Fünf Distributionswege speisen sich aus demselben Index (A5); Prüfsummen, Provenienz-Attestierungen und ein signierter Yank-Feed sichern die Lieferkette (A6); Betrieb und Telemetrie erfolgen EU-gehostet und ohne Personenbezug (A9).

Dieses Kapitel überführt die in Kapitel 4 erhobenen Anforderungen und die in Kapitel 3 destillierten Präzedenz-Lehren in ein technisches Design-Artefakt. Leitmotiv ist bewusste Einfachheit: Jede Komponente, die Zustand hält oder Rechte verwaltet, vergrößert Angriffsfläche, Betriebskosten und Governance-Aufwand. Die Architektur beginnt deshalb so statisch wie möglich und wächst nur dort, wo Anforderungen es erzwingen.

5.1 Entwurfsprinzip Git-first: Monorepo, statischer Index, gestufter Ausbau

Quelle der Wahrheit ist ein Git-Monorepo, in dem alle Skills als Verzeichnisse mit SKILL.md und optionalen Zusatzordnern liegen — der Startkatalog umfasst 137 kuratierte Skills, davon 31 TYPO3-spezifische [1]. Externe Autor:innen tragen entweder per Pull Request direkt bei (kuratierter Pfad) oder über einen Verweis auf ihr eigenes Repository, das ein Synchronisationsjob regelmäßig einliest (föderierter Pfad).

Aus diesem Repository erzeugt die CI bei jeder Änderung einen statischen Index: eine Gesamtdatei index.json (für den Startkatalog unter 500 KB), je Skill eine eigene JSON-Datei, Tarball-Artefakte pro Release sowie einen Atom-Feed für Änderungsbenachrichtigungen. Dieser Index ist der öffentliche Vertrag des Verzeichnisses. Die Read-API der ersten Ausbaustufe besteht schlicht aus diesen Dateien — etwa GET /api/v1/index.json und GET /api/v1/skills/<vendor>/<name>.json —, offen per CORS, langlebig cachebar über inhaltsadressierte URLs und durch eine OpenAPI-Beschreibung dokumentiert, sodass Drittclients und der spätere MCP-Server identisch konsumieren.

Die Stufung ist bewusst gewählt. Erstens: Statische Dateien halten keinen serverseitigen Zustand, sind trivial zu spiegeln und minimieren die Angriffsfläche. Zweitens: Jeder Indexstand ist aus einem Git-Commit reproduzierbar; Provenienz und Attribution bleiben damit lückenlos nachvollziehbar (A3). Drittens: Die Betriebskosten bleiben so gering, dass ein Dauerbetrieb ohne Paywall realistisch wird (vertieft in Kapitel 8). Eine Datenbank mit schmaler Schreib-API kommt erst dann hinzu, wenn authentifiziertes Self-Service-Publishing, deutlich mehr als etwa 500 Skills, Bewertungen oder personengebundene Tokens benötigt werden — und selbst dann schreibt die API in den Index, der der öffentliche Lesepfad bleibt. Das entspricht Lehre L1 aus Kapitel 3: Das TER verlor die Distributionsrolle an Composer und Packagist, blieb aber als Vertrauens- und Discovery-Schicht bestehen [14]; wer Discovery und Distribution entkoppelt, kann die Distribution an vorhandene Git-Infrastruktur delegieren.

5.2 Metadaten-Standard: spezifikationskonforme namespaced Frontmatter

Skills bleiben vollständig konform zur offenen Agent-Skills-Spezifikation, die verpflichtend name und description sowie optional license, compatibility, allowed-tools und eine freie metadata-Zuordnung von Zeichenketten vorsieht [2]. Alle verzeichnisspezifischen Angaben wandern in namespaced Schlüssel innerhalb von metadata. Dadurch bleiben die Skills für die rund 30 Agents lesbar, die die Spezifikation unterstützen [2] — das sichert Anforderung A1 strukturell ab, statt sie nur zu versprechen.

---
name: typo3-solr
description: Configures and debugs Apache Solr search for TYPO3.
license: MIT
metadata:
  version: "1.2.0"
  typo3/core: "13,14"
  registry/maturity: stable
  registry/tested: "typo3-v14.3@2026-06-30"
  registry/agents: "claude-code,cursor,gemini-cli"
  registry/category: typo3-cms
  registry/author: webconsulting
---

Die Felder tragen die Vertrauensaussagen des Verzeichnisses: version folgt semantischer Versionierung; typo3/core benennt die unterstützten TYPO3-Hauptversionen als LTS-Matrix; registry/maturity übernimmt die aus dem TER vertraute Reifegrad-Skala (experimental, beta, stable, deprecated); registry/tested dokumentiert datiert, gegen welche TYPO3-Version zuletzt erfolgreich geprüft wurde. Damit werden Kompatibilitätsaussagen versioniert und datiert (A2) und bilden zugleich die Berechnungsgrundlage für den Freshness-Status über LTS-Zyklen hinweg (A11, vertieft in Kapitel 6). registry/author verknüpft mit einem Attributionsblock, der Herkunft und Adaptionen je Skill ausweist (A3). Ergänzend verlangt der Standard je Skill ein CHANGELOG.md, einen Lizenzverweis und optional einen evals/-Ordner mit ein bis drei Beispielaufgaben. Das Gesamtschema wird als JSON Schema unter dem Namen typo3-skills-metadata v1 publiziert und in der CI erzwungen — der Standard ist damit selbst ein prüfbares Artefakt.

5.3 Qualitäts-Gates in der CI

Die Snyk-Analyse ToxicSkills fand bei rund 13 % der öffentlich gelisteten Skills kritische Sicherheitsprobleme [7]. Skills sind dabei eine breitere Angriffsfläche als klassische Pakete: Bereits die Prosa einer SKILL.md kann einen KI-Coding-Agent per Prompt Injection steuern, ganz ohne ausführbare Skripte. Der Entwurf setzt deshalb Lehre L4 aus Kapitel 3 um — Prosa und Skripte werden gleichermaßen geprüft (A4) — und staffelt die Prüfungen nach Kosten und Latenz.

Tabelle 5.1: Dreistufige Qualitäts-Gates der CI-Pipeline mit Zeitpunkt und Prüfumfang.

Die dritte Ebene ist das fachliche Alleinstellungsmerkmal gegenüber horizontalen Verzeichnissen wie skills.sh oder SkillsMP, die Skills nur indexieren, aber nicht gegen eine reale Zielplattform testen können [5], [6]. Der laufende Betrieb des Eval-Harness ist mit einem Budget von etwa 50 bis 150 Euro pro Monat realistisch kalkuliert. Die maschinellen Gates ersetzen die menschliche Kuratierung nicht: Erstaufnahmen externer Skills und Änderungen an Skripten durchlaufen zusätzlich eine Review durch Maintainer:innen, deren Kriterien und Fristen Kapitel 6 als Governance-Regeln formalisiert (A7).

5.4 Distributionswege: fünf Kanäle, ein Index

Ein-Kommando-Installation über gängige KI-Coding-Agents hinweg (A5) erfordert nicht fünf getrennte Systeme, sondern fünf dünne Adapter über demselben Index:

1. Eigener Installer: install.sh/update.sh bedienen bereits mehrere Clients (Claude Code, Cursor, Gemini CLI, Codex, Windsurf) und werden so refaktoriert, dass sie den publizierten Index statt des lokalen Repositorys lesen.
2. npx skills add: Die CLI von Vercel installiert direkt aus öffentlichen GitHub-Repositories [12]; das Monorepo-Layout bleibt kompatibel, wodurch die Skills zusätzlich im horizontalen Verzeichnis skills.sh sichtbar werden [5].
3. Claude-Code-Plugin-Marketplace: Eine marketplace.json im Repository macht den Katalog per Einzeiler abonnierbar [11]; das Netresearch-Marketplace zeigt die Praxistauglichkeit dieses Wegs im TYPO3-Umfeld [9].
4. Composer-Plugin: composer require --dev installiert ausgewählte Skills in das Skills-Verzeichnis eines TYPO3-Projekts, konfiguriert über composer.json — das holt TYPO3-Entwickler:innen in ihrem gewohnten Werkzeug ab.
5. MCP-Server: Ein leichtgewichtiger Server exponiert Suche, Abruf und Installation über das Model Context Protocol und wird mit verifiziertem Reverse-DNS-Namensraum im offiziellen MCP Registry publiziert [13].

Aktualisierungen laufen über Semver-Vergleich und Inhalts-Hash: Der Installer zeigt vor jedem Update eine Änderungszusammenfassung an. Stilles Auto-Update ist ausgeschlossen — Skills sind Prompt-Injection-Fläche, Änderungen müssen sichtbar bleiben.

5.5 Supply-Chain-Sicherheit: Prüfsummen, Attestierungen, Yank, Namensschutz

Lehre L3 aus Kapitel 3 lautet: Die Kompromittierung eines vertrauenswürdigen Publisher-Kontos schlägt jede Code-Review — der Nx-Console-Vorfall traf sogar einen verifizierten Publisher [10]. Der Entwurf begegnet dem auf vier Wegen. Erstens publiziert der Index je Skill-Version eine SHA-256-Prüfsumme, die alle Installer vor dem Entpacken verifizieren. Zweitens erzeugt die CI bei Release-Tags Provenienz-Attestierungen nach dem SLSA-Modell, die kryptografisch belegen, aus welchem Commit und welchem Build-Prozess ein Artefakt stammt; optional treten Sigstore-Signaturen hinzu (A3).

Drittens der Rückrufmechanismus (A6): Ein Yank entfernt eine Version nicht nur aus dem Index, sondern trägt sie in einen signierten Yank-Feed ein. Installierende Clients gleichen lokale Inhalts-Hashes periodisch gegen diesen Feed ab und warnen Nutzer:innen aktiv — bloßes Löschen erreicht bereits installierte Kopien nicht. Die Signatur des Feeds verhindert, dass ein manipulierter Spiegel Rückrufe unterdrückt. Viertens der Namensschutz: Slugs sind vendor-präfixiert, typo3-*-Namen bleiben verifizierten Maintainer:innen vorbehalten, und ein Levenshtein-Check in der CI blockiert Typosquatting — analog zum Modell verifizierter Namensräume des MCP Registry [13]. Die zugehörigen Vergaberegeln (A8) formuliert Kapitel 6.

5.6 Betrieb: EU-Hosting und Telemetrie ohne Personenbezug

Weil Site und Index reine Dateien sind, ist der Betrieb datenschutzrechtlich einfach zu halten (A9). Gehostet wird in der EU — ein Ursprungsserver in Deutschland hinter einem europäischen CDN. Die Web-Analyse erfolgt selbst gehostet, ohne Cookies und ohne Einwilligungsbanner. Installationszählung geschieht über einen anonymen Zählendpunkt je Skill: keine IP-Speicherung, keine Nutzerkennung, ausschließlich aggregierte Zahlen, die wieder in den Index zurückfließen. So entstehen Download-Zahlen als Relevanzsignal, wie sie das TER etabliert hat, ohne personenbezogenes Tracking. Die rechtliche Einordnung dieser Betriebsentscheidungen vertieft Kapitel 7.

5.7 Zuordnung der Entwurfsentscheidungen zu Anforderungen und Präzedenz-Lehren

Tabelle 5.2 fasst zusammen, welche Entwurfsentscheidung welche Anforderung aus Kapitel 4 adressiert und auf welcher Lehre aus Kapitel 3 sie beruht.

Tabelle 5.2: Zuordnung der Entwurfsentscheidungen zu den Anforderungen A1 bis A6, A8 und A9 sowie den Lehren L1, L3 und L4.

5.8 Zwischenfazit

Die Architektur ist als minimale Vertrauensmaschine angelegt: Ein Git-Monorepo liefert Nachvollziehbarkeit, ein statischer Index liefert einen stabilen öffentlichen Vertrag, und beides zusammen hält Betriebskosten und Angriffsfläche klein. Der Metadaten-Standard operationalisiert die zentralen Vertrauensaussagen — Version, TYPO3-Kompatibilität, Reifegrad, Prüfdatum — innerhalb der offenen Spezifikation und ohne Portabilitätsverlust. Qualitäts-Gates, Provenienz-Attestierungen und der signierte Yank-Feed übersetzen die Lehren aus den untersuchten Präzedenzfällen in prüfbare Mechanik. Zugleich zeigt der Entwurf seine Grenze: Schema-Checks und Sandboxes können menschliche Urteile über Erstaufnahmen, Namensvergabe und Rückrufe nicht ersetzen. Welche Rollen, Kriterien und Fristen diese Urteile tragen, definiert das Governance-Modell in Kapitel 6.

---

6 Governance-Modell: Kuratierung, Namensräume und Sicherheitsprozesse

Kernaussagen dieses Kapitels

• Der Aufnahmeprozess läuft als Pull-Request-basierter Funnel mit vierstufiger Review-Pipeline (Bot-Triage → CI-Gates → funktionaler Review gegen ein reales TYPO3-Projekt → Editorial/Publish) und einer öffentlich publizierten Akzeptanz-Rubrik; damit werden A4 und A7 prozessual verankert.
• Namensräume werden verdient, nicht reserviert: Ein Slug wie typo3-seo geht an die erste angenommene Einreichung, verifizierte Vendor-Namespaces und reservierte Namen verhindern Squatting und Endorsement-Täuschung (A8).
• Das Maintainer-Modell skaliert in drei Reifegraden von der Einzelkuratierung über Kategorie-Maintainer:innen bis zur Trusted-Author-Fast-Lane; die Aufwandsrechnung zeigt, dass bis etwa 20 Einreichungen pro Monat ehrenamtliche Strukturen tragen, darüber bezahlte Kapazität nötig wird.
• Der Sicherheitsprozess folgt dem Vorbild des TYPO3 Security Teams [15] und ergänzt ihn um einen signierten Yank-Feed, den installierende Clients bei jeder Synchronisation prüfen (A6) — ein struktureller Vorteil gegenüber horizontalen Verzeichnissen ohne Rückrufmechanismus [5].

Kapitel 5 hat das technische Artefakt entworfen; dieses Kapitel entwirft das organisatorische. Governance entscheidet darüber, ob die in Kapitel 4 erhobenen Vertrauensbedarfe dauerhaft erfüllt werden — nicht die Architektur allein. Leitend sind dabei zwei Lehren aus Kapitel 3: L2 (Maintainer:innen einmal gründlich prüfen, Skills danach kostengünstig auszeichnen, nach dem Vorbild des Drupal-Security-Opt-ins [16]) und L5 (Governance-Regeln schriftlich fixieren, bevor Wachstum sie erzwingt — die Lehre aus den Namens- und Übernahmekonflikten anderer Verzeichnisse).

6.1 Submission-Funnel: PR-basiert mit vierstufiger Review-Pipeline

Für die Startphase werden Einreichungen ausschließlich als Pull Requests (Änderungsvorschläge im Git-Workflow) gegen das bestehende Repository [1] angenommen, nicht über ein Webformular. Die Begründung ist pragmatisch: Die Prüfwerkzeuge existieren bereits im Repository (Skill-Audit-Skripte, Attributions-Guardrails, Spezifikationsvalidierung nach [2]), Pull Requests liefern Diff-Ansicht, Provenienz und Diskussionsfaden ohne Zusatzkosten, und Skill-Autor:innen sind ohnehin Entwickler:innen. Das Vorgehen entspricht dem kuratierten Beispielkatalog von Anthropic mit rund 20 manuell geprüften Skills [4] — und unterscheidet sich bewusst von skills.sh, das ohne Security-Review publiziert [5]. Ein Webformular als dünner Wrapper, der über die GitHub-API einen Pull Request erzeugt, ist erst für eine spätere Phase vorgesehen (vgl. Kapitel 9).

Jede Einreichung durchläuft vier Stufen:

Tabelle 6.1: Vierstufige Review-Pipeline des Submission-Funnels

Die Deny-Patterns der Stufe 2 adressieren die in Kapitel 3 dokumentierte Bedrohungslage: Snyk fand bei rund 13 % öffentlich gelisteter Skills kritische Sicherheitsprobleme, darunter Prompt Injection in der Prosa selbst [7]. Deshalb prüft die Pipeline ausdrücklich Prosa und Skripte (A4) — automatisiert in Stufe 2, zeilenweise durch Menschen in Stufe 3.

Die Akzeptanz-Rubrik wird vollständig publiziert (A7) und pro Zeile mit Bestanden/Nicht bestanden bewertet: gültiges Frontmatter mit Versions- und Kompatibilitätsangaben (A1, A2), belegte Funktionsfähigkeit durch ein Test-Transkript und mindestens einen reproduzierten Happy Path, keine Datenexfiltration und keine destruktiven Defaults, deklarierte und kompatible Lizenz mit intakter Upstream-Attribution (A3), keine Verletzung der TYPO3-Markenpolitik [17], [18] (vertieft in Kapitel 7), zielgruppengerechte Beschreibung sowie Nicht-Überschneidung mit bestehenden Skills. Duplikate werden mit Verweis auf den existierenden Skill abgelehnt. Publizierte Kriterien und publizierte Bearbeitungsfristen sind dabei nicht nur Rechenschaft, sondern selbst ein Anreiz: Vorhersehbarkeit senkt die Einreichungshürde.

6.2 Namensraum-Governance: verdiente Slugs statt Squatting

Die Namensraum-Regeln setzen A8 um und folgen L5: Sie werden vor dem ersten Konflikt schriftlich fixiert. Drei Prinzipien tragen das Modell.

Erstens: Verdiente flache Slugs. Ein Katalogname wie typo3-seo wird an die erste angenommene Einreichung vergeben, die den Review besteht — nicht an die erste Registrierung. Namensreservierungen ohne funktionierenden Skill sind ausgeschlossen. Das vermeidet das aus dem TER bekannte Muster, dass Extension-Keys auf Vorrat belegt werden, ohne dass je Code erscheint.

Zweitens: Verifizierte Vendor-Namespaces. Agenturen und Hersteller erhalten Präfixe wie netresearch/… oder webconsulting/…, verifiziert über Domain-E-Mail und Handelsregisterauszug, verbunden mit einer Profilseite. Netresearch ist als Launch-Partner naheliegend, da dessen kuratierter Marketplace mit rund 40 Skills die Quelle vieler bereits adaptierter Skills ist [9] und die Attribution im Katalog bereits geführt wird [1]. Wichtig ist die Semantik: Die Verifikation belegt Identität, nicht Code-Sicherheit — der Fall der trojanisierten Nx-Console-Extension mit Verified-Publisher-Badge [10] zeigt, dass diese Unterscheidung explizit kommuniziert werden muss (vgl. A10 und Kapitel 7).

Drittens: Reservierte Namen. Muster wie typo3-core-*, official-* und alles, was eine Billigung durch TYPO3 GmbH oder TYPO3 Association suggeriert, bleiben gesperrt und werden für eine mögliche spätere Partnerschaft mit der Association vorgehalten (vgl. Kapitel 9). Eigentumsübertragungen eines Slugs erfordern die Zustimmung der aktuellen Inhaber:innen — analog zur Extension-Key-Regel des TER —, mit der in Abschnitt 6.4 beschriebenen Ausnahme für nachweislich verwaiste Skills.

6.3 Maintainer-Modell in drei Reifegraden

Kuratierung ist menschliche Arbeit; ihre Organisation muss mit dem Einreichungsvolumen mitwachsen. Der Entwurf sieht drei Reifegrade vor:

1. Einzelkuratierung (Start bis etwa Monat 6): Eine kuratierende Person prüft alle Einreichungen und publiziert Entscheidungen offen im PR-Thread, um Präzedenzfälle zu dokumentieren.
2. Kategorie-Maintainer:innen (ab Monat 6): Je Themencluster — TYPO3 (angesichts von 31 TYPO3-spezifischen Skills [1] mit zwei Personen), Marketing, Code-Qualität, Frontend — erhalten Maintainer:innen Merge-Rechte ausschließlich in ihrem Cluster. Rekrutiert wird aus wiederkehrenden Contributor:innen.
3. Trusted-Author-Fast-Lane (ab Monat 9): Wer drei angenommene Skills und sechs Monate guten Standing vorweist, erhält für Updates Auto-Merge bei grüner CI, ergänzt um stichprobenartige Post-Publish-Audits (10 %-Stichprobe). Neue Skills durchlaufen weiterhin Stufe 3, aber mit einer Frist von drei Werktagen.

Die Fast-Lane operationalisiert L2: Die aufwendige Prüfung gilt der Person und wird einmal geleistet; danach werden einzelne Artefakte kostengünstig freigegeben — abgesichert durch Stichproben statt Vollprüfung [16]. Die Aufwandsrechnung kalkuliert mit 60–90 Minuten für den vollständigen Review eines neuen Skills, 15–20 Minuten für Updates bekannter Autor:innen und einer zweiten Review-Runde (+30 Minuten) bei rund 30 % der Einreichungen:

Tabelle 6.2: Aufwandsdimensionierung des Reviews nach Einreichungsvolumen

Die Tabelle macht die Belastungsgrenze sichtbar: Bis etwa 20 Einreichungen pro Monat trägt ein ehrenamtliches Modell; darüber ist bezahlte Kapazität oder eine Förderung, etwa über das TYPO3 Community Budget [26], erforderlich. Die ökonomische Einbettung behandelt Kapitel 8 (A12).

6.4 Lebenszyklus: Versionierung, Deprecation, Verwaisung und Adoption

Jeder Skill folgt Semantic Versioning (semantische Versionierung mit Major-, Minor- und Patch-Stufen) im Frontmatter, ergänzt um einen Changelog-Eintrag. Das Verzeichnis führt Versionshistorie und eine Kompatibilitätsmatrix über TYPO3-LTS-Versionen und KI-Coding-Agents (A2, A11).

Deprecation: Ein Skill erhält den Status deprecated mit einem superseded-by-Verweis auf den Nachfolger; nach einer sechsmonatigen Auslauffrist wird er aus dem Standardkatalog genommen. Installer geben während der Frist eine Warnung aus.

Verwaisung und Adoption folgen dem TER-Vorbild, ergänzt um eine explizite Ausweichregel für tatsächlich Abwesende: Reagieren Maintainer:innen 90 Tage über zwei Kanäle nicht, wird der Skill als orphaned markiert; es folgt ein öffentlicher Adoptionsaufruf über 30 Tage; danach überträgt die Kuratierung den Skill Fork-basiert an Adoptierende, wobei die ursprüngliche Attribution gemäß CC-BY-SA erhalten bleibt (A3). Die ursprünglichen Autor:innen können den Skill innerhalb von zwölf Monaten zurückfordern, sofern sie wieder aktiv sind. So bleibt das Konsensprinzip der TER-Schlüsselübertragung gewahrt, ohne dass verwaiste Skills das Verzeichnis veralten lassen.

6.5 Sicherheitsprozess: Intake, Advisories und Yank-Mechanismus

Der Incident-Prozess ist dem dokumentierten Vorgehen des TYPO3 Security Teams nachgebildet [15]: Meldungen gehen an eine dedizierte Security-Adresse mit Eingangsbestätigung binnen 48 Stunden, es folgen Triage, vertrauliche Kontaktaufnahme mit den Autor:innen und eine koordinierte Veröffentlichung von Fix und Advisory. Bleibt ein Fix in angemessener Zeit aus, werden die betroffenen Versionen entfernt und ein Bulletin mit Deinstallationsempfehlung publiziert — exakt der im TER etablierte Ablauf. Advisories werden von Beginn an nummeriert (Schema WCS-SA-2026-001) und als JSON- und RSS-Feed bereitgestellt.

Skills erfordern darüber hinaus zwei Ergänzungen. Erstens der Yank-Mechanismus (A6): Eine zurückgerufene Version verschwindet sofort aus dem Index; zusätzlich prüfen Installations- und Update-Skripte bei jeder Synchronisation einen signierten yanked.json-Feed und warnen vor lokal installierten Kopien beziehungsweise entfernen sie. Damit erreicht der Rückruf auch bereits installierte Clients — ein struktureller Vorteil gegenüber skills.sh, das keinen solchen Mechanismus besitzt [5]. Zweitens die Abgrenzung bösartig gegen fehlerhaft: Ein fehlerhafter Skill durchläuft den koordinierten Fix-Prozess; ein bösartiger Skill führt zum sofortigen Yank aller Versionen, zur Sperre der Autor:innen und zu einem Advisory mit Kompromittierungsindikatoren — einschließlich der Angabe, welche Daten abgeflossen sein könnten und nach welchen Prompts Betroffene ihre Transkripte durchsuchen sollten. Diese Transkript-Dimension ist skill-spezifisch: Da Prosa den Agenten auch ohne Skripte manipulieren kann [7], muss ein Advisory die Instruktionsebene mitdenken (A4). Das Maintainer-Vetting aus Abschnitt 6.3 flankiert diesen Prozess präventiv nach der Drupal-Lehre: Die einmalige Personenprüfung vor der Vergabe erweiterter Rechte reduziert das Risiko, dass die Fast-Lane selbst zum Angriffsvektor wird [16].

6.6 Anreizsystem und Code of Conduct

Ein Verzeichnis ohne Einreichungen ist wertlos; Governance muss deshalb auch motivieren. Der Entwurf sieht eine Anreizleiter vor: Verified-Author-Badge → Installations- und Download-Statistiken auf der Profilseite → monatliches Contributor-Spotlight in Blog und Newsletter → Sichtbarkeit auf Community-Veranstaltungen wie den TYPO3 Developer Days [21] → perspektivisch eine Umsatzbeteiligung an kostenpflichtigen Zusatz-Skills, die jedoch bis zur Klärung der rechtlichen und steuerlichen Dimension zurückgestellt bleibt (vgl. Kapitel 7 und 8). Der öffentliche Kernkatalog bleibt davon unberührt frei zugänglich (A12).

Als Verhaltenskodex wird der Contributor Covenant 2.1 übernommen, kulturell rückgebunden an den Code of Conduct der TYPO3-Community. Streitfälle — Ablehnungen, Namenskonflikte, Adoptionskonkurrenzen — folgen einem dreistufigen Verfahren: Entscheidung der zuständigen Maintainer:innen, schriftlicher Einspruch an die Kuratierung, öffentlich protokollierte Letztentscheidung. Auch hier gilt L5: Das Verfahren existiert, bevor der erste Konflikt eintritt.

6.7 Zwischenfazit

Das Governance-Modell übersetzt die Vertrauensanforderungen aus Kapitel 4 in überprüfbare Verfahren: Die vierstufige Review-Pipeline mit publizierter Rubrik erfüllt A4 und A7, verdiente Namensräume mit Vendor-Verifikation erfüllen A8, und der Sicherheitsprozess mit signiertem Yank-Feed erfüllt A6. Die Aufwandsrechnung zeigt zugleich die Grenze des Modells: Ab rund 20 Einreichungen pro Monat braucht Kuratierung bezahlte oder geförderte Kapazität, womit die Tragfähigkeitsfrage an Kapitel 8 übergeben wird. Die konsequente Anlehnung an TER und TYPO3 Security Team [15] ist dabei kein Traditionalismus, sondern Adoptionsstrategie: Die Zielgruppe kennt und vertraut diesen Verfahren bereits. Offen bleibt die rechtliche Absicherung von Namens-, Marken- und Haftungsfragen — sie ist Gegenstand von Kapitel 7.

---

7 Rechtlicher Rahmen: Marke, Lizenzen, Plattformpflichten und Haftung

Kernaussagen dieses Kapitels

• Die Trademark-Policy der TYPO3 Association untersagt die Verwendung der Wortmarke „TYPO3" in Produkt-, Firmen- und Domainnamen; zulässig bleibt nur beschreibende Nutzung. Das Verzeichnis benötigt daher einen neutralen Eigennamen mit dem Zusatz „für TYPO3" oder eine schriftliche Genehmigung über den offiziellen Antragsweg [17], [18].
• Redistribution von Skills ist nur zulässig, wenn deren Lizenz sie erlaubt. Jeder Skill trägt deshalb eine SPDX-Lizenzdeklaration und ein Attributions-Pflichtfeld (A3); andernfalls erfolgt lediglich ein Metadaten-Listing mit Verweis auf das Ursprungs-Repository.
• Der Digital Services Act entlastet Kleinstunternehmen von den Plattform-Sonderpflichten, verlangt aber weiterhin Notice-and-Action, Begründungspflicht und Kontaktstellen [20].
• Die neue EU-Produkthaftungsrichtlinie behandelt Software als Produkt (Umsetzungsfrist 9. Dezember 2026); die Open-Source-Ausnahme ist bei kommerzieller Einbettung fragil [19].
• Weil gängige Installationskanäle die Nutzungsbedingungen umgehen, wirken vertragliche Haftungsausschlüsse dort nicht. Die Konsequenz ist eine rechtssichere Badge-Semantik: datierte Prozessaussagen statt Ergebniszusicherungen (A10) sowie Disclaimer in jedem Kanal.

Dieses Kapitel analysiert den Rechtsrahmen des entworfenen Verzeichnisses aus der Perspektive eines Betreibers mit Sitz in Österreich unter EU-Recht. Im Sinne des Design-Science-Ansatzes werden Rechtspflichten nicht isoliert referiert, sondern als Entwurfsrestriktionen behandelt: Jede identifizierte Pflicht mündet in eine konkrete Architektur- oder Governance-Entscheidung, die an die Kapitel 5 und 6 anschließt. Die Darstellung ist bewusst für Nicht-Jurist:innen lesbar gehalten; Punkte, die eine anwaltliche Prüfung erfordern, sind ausdrücklich gekennzeichnet.

7.1 Markenrecht: Die Wortmarke „TYPO3"

„TYPO3" ist eine eingetragene Marke der TYPO3 Association mit Sitz in Baar (Schweiz). Deren Trademark Usage Policy untersagt es allen Dritten — ausdrücklich auch zahlenden Mitgliedern der höchsten Stufen —, die Wortmarke in Firmennamen, Produktnamen, Domainnamen und Social-Media-Handles zu führen; die Policy nennt als Beispiel eine Domain wie „typo3hosting.com" [17], [18]. Frei bleibt allein die beschreibende (nominative) Nutzung: Die Aussage „Agent Skills für TYPO3" ist zulässig, ein Produktname wie „TYPO3 Skills Directory" oder eine Domain mit dem Bestandteil „typo3" ist es ohne schriftliche Erlaubnis nicht [17].

Für den Entwurf folgt daraus eine klare Namensstrategie: Das Verzeichnis erhält einen erfundenen, neutralen Eigennamen und führt die Ökosystem-Zugehörigkeit ausschließlich im beschreibenden Untertitel („das Agent-Skills-Verzeichnis für TYPO3"). Bis eine schriftliche Genehmigung vorliegt, bleibt die Wortmarke aus Logo, Domain, App-Name und dem Namen der GitHub-Organisation ausgeschlossen.

Zugleich existiert ein geregelter Genehmigungsweg: Die Policy sieht ein Formular zur Registrierung einer Markennutzung vor, und die publizierten Kriterien — Nutzen für die Community, Open-Source-kompatible Lizenzierung, substanzielle Beteiligung von Beitragenden, keine implizierte Offiziellität — decken sich weitgehend mit den Zielen des Verzeichnisses [17], [18]. Strategisch attraktiver als eine bloße Nutzungserlaubnis ist die in Kapitel 9 entwickelte Option, das Verzeichnis mittelfristig als offizielle Initiative der TYPO3 Association zu positionieren, etwa über eine Einreichung im Community-Budget-Prozess [26]; damit würde das Markenproblem in ein Vertrauenssignal umgewandelt. Zu beachten ist ferner, dass bezahlte Werbung unter Verwendung der Marke eine Gold- oder Platin-Mitgliedschaft voraussetzt [17], [27]. Die Verhandlung einer Markengenehmigung ist ein Punkt für anwaltliche Begleitung.

7.2 Lizenzarchitektur: SPDX, Redistribution und Beitragsbedingungen

Der Startkatalog von 137 Skills ist lizenzrechtlich heterogen: Plattform-Code steht unter MIT, Skill-Prosa standardmäßig unter CC-BY-SA-4.0, übernommene Drittbestände unter Apache-2.0, MIT, ISC oder — in Einzelfällen — unter eigenen, nicht frei weiterverbreitbaren Bedingungen [1]. Der Entwurf reagiert darauf mit drei Regeln.

Erstens deklariert jeder Skill seine Lizenz maschinenlesbar als SPDX-Feld im Frontmatter; das Verzeichnis zeigt diese Angabe an und macht sie filterbar. Zweitens gilt eine strikte Redistributionsregel: Das Verzeichnis darf Inhalte nur dann selbst hosten oder spiegeln, wenn die Lizenz die Weiterverbreitung ausdrücklich erlaubt. Für alle anderen Skills — etwa solche mit „source-available"-Bedingungen — erfolgt ein reines Metadaten-Listing, das auf das Ursprungs-Repository verlinkt. Drittens ist Attribution ein Pflichtfeld: Herkunft und Urheberschaft jedes Skills bleiben nachvollziehbar, was zugleich die Anforderung A3 erfüllt. Eine CI-Prüfung erzwingt diese Regeln automatisiert — Lizenzfeld vorhanden, Attributionsblock intakt, keine CC-BY-SA-Prosa in MIT-lizenzierten Code kopiert; sie ist Teil der in Kapitel 6 beschriebenen Publikations-Pipeline.

Eine besondere Grenze zieht das Copyleft der CC-BY-SA-Lizenz: Wer einen CC-BY-SA-Skill bearbeitet, muss die Bearbeitung unter derselben Lizenz weitergeben; eine Umlizenzierung fremder Beiträge ist ausgeschlossen. Skills unter Apache-2.0 können daneben als eigenständige Werke koexistieren, Prosa darf jedoch nicht über Lizenzgrenzen hinweg zusammengeführt werden.

Für eingehende Beiträge setzt der Entwurf auf das Developer Certificate of Origin (DCO), also eine Herkunftsbestätigung per Sign-off je Commit, kombiniert mit einer „inbound = outbound"-Klausel: Beiträge stehen unter derselben Lizenz wie die Datei, die sie verändern. Auf ein Contributor License Agreement (CLA) wird bewusst verzichtet, da es in Open-Source-geprägten Ökosystemen wie dem TYPO3-Umfeld Beitragshürden aufbaut; auch das historische TER kommt ohne CLA aus. Eine Einreich-Checkliste (Berechtigung zur Einreichung, attribuiertes und lizenzkompatibles Drittmaterial, kein vertraulicher Kund:innen-Code) ergänzt den Prozess. Anwaltlich zu prüfen bleibt, ob die Sonderlizenzen einzelner Drittskills ein Spiegeln überhaupt zulassen.

7.3 Plattformpflichten nach dem Digital Services Act

Sobald das Verzeichnis von Nutzer:innen eingereichte Skills speichert und öffentlich bereitstellt, ist es ein Hosting-Dienst und voraussichtlich eine „Online-Plattform" im Sinne des Digital Services Act (DSA) [20]. Als Kleinstunternehmen — weniger als zehn Beschäftigte, unter zwei Millionen Euro Jahresumsatz — ist der Betreiber von den Plattform-Sonderpflichten befreit: Transparenzberichte, ein internes Beschwerdemanagement und die Einbindung vertrauenswürdiger Hinweisgeber:innen entfallen [20].

Die Grundpflichten für Hosting-Dienste bleiben jedoch bestehen: das Haftungsprivileg für fremde Inhalte bis zur tatsächlichen Kenntnis (Art. 6), ein Melde- und Abhilfeverfahren für rechtswidrige Inhalte (Notice-and-Action, Art. 16), eine Begründungspflicht gegenüber Betroffenen bei Entfernung von Inhalten (Art. 17), benannte Kontaktstellen (Art. 11–13) sowie Transparenz über Moderationsregeln in den Nutzungsbedingungen (Art. 14) [20]. Diese Pflichten sind mit geringem Aufwand umsetzbar: ein „Skill melden"-Formular je Detailseite, ein dokumentierter Takedown-Prozess und eine öffentliche Moderationsrichtlinie. Der Entwurf koppelt den Takedown-Prozess bewusst an den Rückrufmechanismus aus Kapitel 6 (A6): Dieselbe Pipeline, die eine Skill-Version aus Sicherheitsgründen zurückzieht, bedient auch DSA-Meldungen.

Eine bewusste Risikominimierung liegt im gestuften Start: Solange das Verzeichnis in Version 1 nur Metadaten führt und die Inhalte auf GitHub verbleiben, treffen die wesentlichen Hosting-Pflichten den dortigen Anbieter — ein Argument für die in Kapitel 5 begründete Metadaten-zuerst-Architektur. Ergänzend ist festzuhalten, dass ein Verzeichnis reiner Prompt-Texte weder ein KI-Modell noch ein KI-System ist; Pflichten aus der KI-Regulierung für Anbieter oder Betreiber entstehen erst, wenn die Plattform selbst Skills ausführen würde. Der Entwurf verzichtet auf eine gehostete Ausführung und dokumentiert diese Grenze in den Nutzungsbedingungen.

7.4 Haftung: Produkthaftung, Vertrauenshaftung und Badge-Semantik

Die Richtlinie (EU) 2024/2853 erweitert die Produkthaftung ausdrücklich auf Software; die Mitgliedstaaten müssen sie bis 9. Dezember 2026 umsetzen [19]. Freie und Open-Source-Software ist nur ausgenommen, wenn sie außerhalb einer geschäftlichen Tätigkeit bereitgestellt wird. Diese Ausnahme ist fragil: Monetarisierung, ein Tausch „Daten gegen Zugang" oder die Bündelung mit dem kommerziellen Angebot einer Agentur können die verschuldensunabhängige und nicht abdingbare Haftung wieder aufleben lassen [19]. Sie erfasst zwar Personenschäden, Verbraucher:innen-Sachschäden und Datenverlust, nicht aber reine Vermögensschäden zwischen Unternehmen — gerade die Einbettungsfrage macht sie jedoch zu einem Strukturthema für das Betreibermodell in Kapitel 8. Ein Umsetzungs-Memo vor dem Stichtag und die Prüfung einer Trennung von Verzeichnis und Agenturgeschäft (etwa Verein oder eigene Gesellschaft) sind anwaltlich zu beauftragen.

Die zweite, praktisch nähere Haftungsflanke ist nicht-vertraglicher Natur. Nutzer:innen installieren Skills über Kanäle wie CLI-Installer, git clone, Composer oder MCP-Anbindungen — und sehen dabei die Nutzungsbedingungen nie. Wo kein Vertrag zustande kommt, binden „AS IS"-Klauseln und Haftungsobergrenzen niemanden. Die Haftung läuft dann über das allgemeine Zivilrecht: § 1300 ABGB privilegiert zwar unentgeltlichen Rat (Haftung nur für wissentlich falschen Rat), doch gilt dieses Privileg nach österreichischer Rechtsprechung nicht, wenn der Rat mit Eigeninteresse — etwa Reputationsaufbau eines kommerziellen Anbieters — innerhalb einer Sonderbeziehung erteilt wird; dann greift volle Fahrlässigkeitshaftung am Sachverständigenmaßstab des § 1299 ABGB. Genau solche Vertrauenstatbestände schaffen Kuratierungs-Badges, die Ergebnisse zusichern: Eine Plakette „security-reviewed, getestet auf v14.3" ist eine verlässlichkeitsbegründende Qualitätsaussage, wie sie ein schlichtes GitHub-Repository nicht abgibt.

Daraus folgt die zentrale Entwurfskonsequenz dieses Kapitels, festgehalten als Anforderung A10: Badges formulieren Prozess- statt Ergebnisaussagen, sind datiert und versionsgebunden. Statt „security-reviewed" heißt es „Prozess-Review durchlaufen (2026-06)", statt „getestet" „Eval-Suite bestanden auf v14.3-Sandbox". Jedes Badge verlinkt auf die publizierten Prüfkriterien (A7) und erklärt ausdrücklich, was es nicht zusichert; auf namentliche Reviewer:innen-Badges wird verzichtet, um persönliche Haftungsrisiken der Prüfenden zu vermeiden. Der Marketingwert der Kuratierung bleibt erhalten, der Zusicherungscharakter wird entschärft. Die Datierung verzahnt sich zudem mit dem Freshness-Status aus Anforderung A11: Ein alterndes Review wird sichtbar, statt stillschweigend weiterzugelten.

Disclaimer können außerhalb eines Vertrags die Haftung nicht begrenzen, wohl aber den Vertrauenstatbestand entkräften und den Sorgfaltsmaßstab senken. Der Entwurf platziert sie deshalb redundant in allen fünf Kanälen: im Frontmatter und in der ersten Zeile jeder SKILL.md, im Lizenz- und README-Hinweis, in der Installationsausgabe der Installer, in den MCP-Werkzeugbeschreibungen und auf den Badge-Detailseiten — jeweils deutsch und englisch, mit der Kernbotschaft: Prüfung durch Menschen vor produktivem Einsatz erforderlich, Prozess-Review mit Datum für eine bestimmte TYPO3-Version. Für Kanäle mit Konto- oder Einreichfunktion sieht der Entwurf zusätzlich eine echte Zustimmungsschranke zu den Nutzungsbedingungen vor. Die Formulierung der kanalabhängigen Disclaimer und der Haftungsklauseln (Grenzen des § 6 KSchG gegenüber Verbraucher:innen, weitergehende Gestaltungsspielräume im B2B-Verhältnis) gehört in anwaltliche Hände; die Quellenlage veranschlagt hierfür ein einmaliges Budget von etwa 4.000 bis 8.000 Euro. Flankierend ist eine IT-Berufshaftpflicht mit Vermögensschadendeckung zu beschaffen; da Versicherer zunehmend KI-Ausschlüsse einführen, ist der dokumentierte menschliche Review-Prozess als Verhandlungsargument für eine Rückausnahme einzusetzen — die ökonomische Einordnung leistet Kapitel 8.

7.5 Datenschutz: Telemetrie ohne Personenbezug

Anforderung A9 verlangt datenschutzkonforme Telemetrie: Das Verzeichnis erhebt Nutzungszahlen ausschließlich aggregiert und ohne Personenbezug, gehostet auf EU-Infrastruktur. Konkret bedeutet das eine europäisch betriebene Web-Analyse ohne personenbezogene Profile statt US-zentrierter Tracking-Dienste, Kürzung von IP-Adressen bei Download-Statistiken sowie Auftragsverarbeitungsverträge nach Art. 28 DSGVO mit Hoster, Mail-Dienst und CDN. Für einen Newsletter gilt das Double-Opt-in-Erfordernis des § 174 TKG 2021. Da keine nicht-essenziellen Tracker eingesetzt werden, entfällt ein Consent-Banner; eine Datenschutzerklärung bleibt verpflichtend. Hinzu kommen die österreichischen Informationspflichten: ein Impressum nach § 5 ECG und eine Offenlegung nach § 25 MedienG, bei redaktionellen Inhalten (Blog) in der vollen Ausprägung inklusive Blattlinie. Diese Bausteine sind mit geprüften Vorlagen umsetzbar und benötigen keine individuelle anwaltliche Beratung.

7.6 Synthese: Von Rechtspflichten zu Entwurfsentscheidungen

Die folgende Übersicht verdichtet die Analyse. Sie zeigt, dass keine der identifizierten Pflichten den Entwurf blockiert; jede lässt sich in eine bereits vorgesehene Architektur- oder Governance-Entscheidung übersetzen.

Tabelle 7.1: Rechtsgebiete, Pflichten und Risiken sowie die daraus abgeleiteten Entwurfskonsequenzen des Verzeichnisses

Anwaltlicher Prüfung bedürfen zusammengefasst vier Punkte: die Markenverhandlung mit der TYPO3 Association, die Redistributionsrechte einzelner Sonderlizenzen, die Nutzungsbedingungen samt Haftungsklauseln und kanalabhängigen Disclaimern sowie das Produkthaftungs-Memo einschließlich der Frage einer Entitätentrennung.

7.7 Zwischenfazit

Der Rechtsrahmen erweist sich als gestaltbar, nicht als Hindernis. Markenrecht erzwingt eine neutrale Namensstrategie mit beschreibendem TYPO3-Bezug und eröffnet zugleich einen Genehmigungs- und Partnerschaftsweg [17], [18]. Lizenzheterogenität wird durch SPDX-Deklaration, Redistributionsregel und Metadaten-Fallback beherrschbar; der DSA ist für ein Kleinstunternehmen mit einem Meldeformular und dokumentiertem Takedown erfüllbar [20]. Die schärfste Einsicht betrifft die Haftung: Weil Installationskanäle den Vertragsschluss umgehen, muss der Vertrauensschutz in das Artefakt selbst eingebaut werden — als datierte Prozess-Badges (A10) und kanalübergreifende Disclaimer, ergänzt um die Produkthaftungsvorsorge vor dem 9. Dezember 2026 [19]. Damit sind die rechtlichen Randbedingungen gesetzt, unter denen Kapitel 8 die ökonomische Tragfähigkeit des Betreibermodells entwickelt.

---

8 Betreibermodell und ökonomische Tragfähigkeit

Kernaussagen dieses Kapitels

• TYPO3 ist ein Nischen-Ökosystem mit wenigen hundert kaufkräftigen Agenturen; ein bezahlter Skill-Marktplatz ist darauf nicht tragfähig und würde zudem unverhältnismäßige steuerliche Plattformpflichten auslösen.
• Der öffentliche Kernkatalog bleibt dauerhaft kostenlos (Anforderung A12) und wirkt als strategischer Moat: Er erzeugt Beratungs- und Workshop-Nachfrage, die alle direkten Erlösquellen zusammen übersteigt.
• Die Kostenseite ist überschaubar: Die Cash-Kosten des ersten Jahres lassen sich durch drei bis vier Sponsoren und einen Community-Budget-Zuschuss decken; der größte Posten ist Kurationsaufwand als Opportunitätskosten.
• In der Eigentumsfrage zeigt der Präzedenzfall Packagist [24]: Ein privat betriebener, aber neutral gelisteter Index wird vom Ökosystem akzeptiert. Empfohlen wird der private Betrieb mit publizierter neutraler Listing-Policy und die Verhandlung eines Endorsed-Operator-Status nach dem Vorbild HACS/Open Home Foundation [25].

8.1 Ehrliche Marktabschätzung: TYPO3 als Nische

Jede Tragfähigkeitsrechnung muss mit den tatsächlichen Größenordnungen des Ökosystems beginnen, nicht mit Wachstumshoffnungen. TYPO3 hält einen CMS-Marktanteil von etwa 0,5 bis 1,1 Prozent, mit rund 38.000 erfassten aktiven Domains und über 500.000 berichteten Installationen. Die Nutzung ist stark regional konzentriert: rund 71 Prozent der Installationen liegen in Deutschland, über 85 Prozent im DACH-Raum. Die TYPO3 Association zählt über 1.000 Mitglieder [27]; das kommerzielle Umfeld besteht aus geschätzt 300 bis 900 Agenturen und Freelancer:innen, von denen realistisch nur 150 bis 300 groß genug sind, um überhaupt als zahlende Kund:innen infrage zu kommen. Diese Deckenwerte begrenzen jedes Erlösmodell.

Gleichzeitig ist der horizontale Skills-Markt bereits besetzt. skills.sh, das im Jänner 2026 gestartete Verzeichnis von Vercel, aggregiert über 90.000 Skills für 19 Agents und dominiert das Segment „alles durchsuchen" [5]; SkillsMP verfolgt als GitHub-Scraper einen ähnlich breiten Ansatz [6]. Ein vertikales Verzeichnis kann in diesem Umfeld nicht über Menge konkurrieren, sondern ausschließlich über vertikales Vertrauen und Kuratierung. Die Snyk-Analyse, die bei rund 13 Prozent öffentlich gelisteter Skills kritische Sicherheitsprobleme fand [7], liefert die Begründung: Die Aussage „jeder gelistete Skill wurde auf TYPO3-v14-Korrektheit und Sicherheit geprüft" ist das gesamte Wertversprechen (vgl. Kapitel 4 und 6).

Für einen bezahlten Skill-Marktplatz folgt daraus eine dreifache Absage. Erstens fehlt das Volumen: Ein zweiseitiger Markt mit wenigen hundert potenziellen Käufer:innen kann die nötige Liquidität aus Angebot und Nachfrage nicht erzeugen. Zweitens ist das Segment „bezahlte, geprüfte Skills" horizontal bereits durch kommerzielle Marktplätze mit Umsatzbeteiligung besetzt. Drittens ist die regulatorische Last unverhältnismäßig, wie Abschnitt 8.2 zeigt.

8.2 Gestufte Erlösquellen

Der Entwurf ordnet Erlösquellen nach Aktivierungsschwellen: Was sofort trägt, wird sofort aktiviert; alles andere wartet auf messbare Adoption. Grundlage ist die in Kapitel 4 formulierte Anforderung A12: Der öffentliche Kernkatalog bleibt dauerhaft kostenlos. Jede Paywall auf Katalog, Suche, Installationsskripte oder Security-Audit-Berichte würde den Vertrauensvorsprung — den einzigen Wettbewerbsvorteil gegenüber horizontalen Verzeichnissen [5], [6] — zerstören.

Kostenloser Kernkatalog als strategischer Moat. Die primäre ökonomische Funktion des Verzeichnisses ist nicht direkter Umsatz, sondern Autorität: Es ist eine dauerhafte Demonstration von Kompetenz im Feld „KI-gestützte TYPO3-Entwicklung". Vergleichbare inhaltsgetriebene TYPO3-Agenturen wandeln diese Autorität in Projektgeschäft um. Eine plausible Rechnung nach zwölf Monaten: 2.000 bis 4.000 monatliche Besucher:innen, 8 bis 12 qualifizierte Anfragen pro Jahr, davon rund ein Viertel abgeschlossen bei 15.000 bis 40.000 Euro durchschnittlichem Projektvolumen — das ergibt 40.000 bis 80.000 Euro jährlich zurechenbaren Beratungsumsatz. Dieser eine Posten übersteigt alle nachfolgenden Erlösquellen zusammen.

Workshops und Enablement (sofort aktivierbar). Teamworkshops zu KI-gestützter TYPO3-Entwicklung sind ohne Adoptionsschwelle verkaufbar, da sie direkt auf der Glaubwürdigkeit des Verzeichnisses aufsetzen. Marktübliche DACH-Sätze für spezialisierte Beratung rechtfertigen 1.800 bis 2.600 Euro pro Workshop-Tag beziehungsweise 4.500 bis 7.500 Euro für ein zweitägiges Enablement-Paket inklusive privater Skill-Erstellung. 8 bis 15 Workshop-Tage im ersten Jahr — angebahnt über Konferenzvorträge, etwa bei den TYPO3 Developer Days [21] — ergeben 15.000 bis 35.000 Euro. Ein Zertifizierungsprogramm ist verfrüht; ein kostenloses Badge-Programm bereitet es vor.

Sponsoring (ab Reichweiten-Schwelle). Ab etwa 1.000 monatlich aktiven Nutzer:innen und rund 20 externen Autor:innen werden Sponsorenpakete realistisch: Gründungssponsor 2.500 bis 4.000 Euro pro Jahr, Kategoriesponsoring 1.000 bis 1.500 Euro, kleines Logo 500 Euro. Drei bis fünf Sponsoren im ersten Jahr (5.000 bis 10.000 Euro) und sechs bis zehn im zweiten (10.000 bis 20.000 Euro) decken Cash-Kosten, niemals Personalkosten.

Private Registries als spätere SaaS-Option. Die plausibelste wiederkehrende Erlösquelle sind gehostete private Registries, in denen Agenturen proprietäre Skills — Kundenkonventionen, interne Deployment-Playbooks — mit derselben Installations-, Versionierungs- und CI-Validierungsinfrastruktur publizieren. Die Zahlungsbereitschaft ist belegt: Agenturen zahlen bereits 50 bis 200 Euro monatlich für vergleichbares internes Tooling. Bei Preispunkten von 99 Euro (Team) und 249 Euro (Agentur, mit SSO und Audit-Log) und einem adressierbaren Markt von 200 bis 300 Agenturen sind zehn zahlende Kund:innen bis Ende des zweiten Jahres realistisch — 12.000 bis 30.000 Euro Jahresumsatz. Das trägt kein Unternehmen, vertieft aber die Bindung. Gebaut wird erst nach mindestens drei Design-Partner-Vorverpflichtungen.

Bezahlter Marktplatz: zurückgestellt. Neben dem Volumenproblem aus Abschnitt 8.1 sprechen steuerliche Plattformpflichten gegen einen Marktplatz: Eine Plattform, die elektronisch erbrachte Dienstleistungen verkauft, Konditionen setzt und Zahlungen abwickelt, gilt umsatzsteuerlich als unwiderleglich fingierte Leistungserbringerin (Deemed Supplier) und schuldet Umsatzsteuer im Mitgliedstaat jeder Käufer:in — mit vierteljährlichen OSS-Meldungen und zusätzlich DAC7-Meldepflichten über die Einkünfte der Autor:innen (vgl. Kapitel 7). Falls je umgesetzt, dann nur über einen Merchant of Record, der diese Pflichten gegen rund fünf Prozent Gebühr übernimmt. Entscheidungsschwelle: frühestens bei über 10.000 Installationen pro Monat und dokumentierter Nachfrage der Autor:innen.

Tabelle 8.1: Gestufte Erlösquellen mit Aktivierungsschwellen und Größenordnungen

8.3 Kostenseite und Break-even-Logik

Die Kostenstruktur ist bewusst schlank: statische Site, Suche und CI-Pipeline verursachen geringe Infrastrukturkosten; der dominante Posten ist menschliche Kurationszeit (vgl. Kapitel 6), die als Opportunitätskosten anfällt, nicht als Auszahlung.

Tabelle 8.2: Kostenschätzung Jahr 1 und Jahr 2 mit Trennung von Gesamt- und Cash-Kosten

Die Break-even-Logik verläuft zweistufig. Stufe eins betrifft die Cash-Kosten: Sie werden bereits im ersten Jahr durch drei bis vier Sponsoren plus einen Zuschuss aus dem Community-Budget-Prozess der TYPO3 Association gedeckt — dieser vergibt 160.000 Euro für 2026 in Quartalsrunden zu je rund 40.000 Euro, typische Einzelförderungen liegen bei 5.000 bis 15.000 Euro [26]. Wichtig: Ein Antrag darf nur die offene Infrastruktur betreffen (Validierungs-Tooling, Security-Audit-Pipeline), nie das Verzeichnis als Geschäftsasset, da die Förderrichtlinien direkten Erwerbszweck ausschließen [26] (siehe Abschnitt 8.4). Stufe zwei betrifft die vollen Opportunitätskosten: Sie sind gedeckt, sobald zurechenbarer Beratungsumsatz (40.000 bis 80.000 Euro) und Workshops (15.000 bis 35.000 Euro) eintreffen — plausibel zwischen Monat 12 und 18. Der SaaS-Dienst muss lediglich seine eigene Infrastruktur und Wartung tragen, wofür rund zehn Kund:innen genügen. Als Disziplinierungsregel gilt: Der Cash-Burn wird bei etwa 12.000 Euro pro Jahr gedeckelt, bis Sponsoring und Workshops ihn decken.

8.4 Eigentums- und Neutralitätsfrage

Das Betreibermodell enthält eine scheinbare Widersprüchlichkeit: Das Verzeichnis soll als neutrale Vertrauensinfrastruktur für das gesamte Ökosystem wirken (Kapitel 3), zugleich aber als Lead-Generierungs-Asset einer einzelnen Agentur. Zwei verifizierte Befunde lösen diesen Konflikt auf.

Erstens ist das Community Budget der Association das falsche Instrument für eine Übertragung oder Finanzierung des Verzeichnisses selbst: Die Regeln verlangen, dass geförderte Ideen den Antragstellenden weder direkt Einnahmen verschaffen noch Erwerbsmöglichkeiten eröffnen [26]. Ein Antrag für das Verzeichnis bei gleichzeitigem Business Case über zurechenbaren Beratungsumsatz wäre disqualifizierend und im Entdeckungsfall reputationsschädigend. Zweitens hat der erfolgreichste Präzedenzfall das Asset nie abgegeben: Packagist.org, der zentrale Paketindex des PHP-Ökosystems, gehört bis heute der Packagist Conductors GmbH, die darauf das kommerzielle Private Packagist aufsetzt [24]. Das PHP-Ökosystem akzeptiert einen privat betriebenen öffentlichen Index, weil die Governance der Listings neutral ist, obwohl das Eigentum es nicht ist. Analog blieb HACS, der Community-Store von Home Assistant, in Creator-Hand und wurde Kooperationspartner der Open Home Foundation — Endorsement und Ressourcen statt Übertragung [25]. Die vollständige Schenkung (Präzedenzfälle TER [14] und Drupal.org) ist das einzige Modell, in dem der kommerzielle Nutzen der Initiator:innen vollständig kollabiert.

Tabelle 8.3: Optionenmatrix zur Eigentums- und Neutralitätsfrage

Die Empfehlung der vorliegenden Arbeit lautet: Start als Option B, aktive Verhandlung in Richtung Option C, Option D als Rückfallebene — niemals mit Option A eröffnen. Der private Betrieb mit einer öffentlich publizierten, neutralen Listing- und Namensraum-Policy (vgl. Kapitel 6, Anforderung A8) übernimmt das erprobte Packagist-Muster [24]; der angestrebte Endorsed-Operator-Status nach dem HACS-Vorbild [25] liefert das offizielle Umfeld, ohne das Eigentum zu übertragen. Die Mitgliedschaft in der TYPO3 Association [27] und ein Community-Budget-Antrag ausschließlich für separierbare offene Infrastruktur [26] flankieren diese Position glaubwürdig. Voraussetzung der Glaubwürdigkeit ist die Entitätentrennung: Der Index gehört in eine eigene Gesellschaft, damit „das Verzeichnis" und „das Beratungsgeschäft" vertraglich separierbar sind — erst das macht Option C für konkurrierende Agenturen als Beitragende akzeptabel.

8.5 Rote Linien für Verhandlungen

Vor jedem Kontakt mit der Association — die Markenfrage eröffnet die Verhandlung (vgl. Kapitel 7) — sind folgende Grenzen zu fixieren:

• Domain ohne Wortmarke. Die Trademark Usage Policy untersagt „TYPO3" in Domains und Produktnamen [17]; Nutzungsgenehmigungen laufen über das offizielle Verfahren [18]. Die Identität des Projekts darf nie von einem Namen abhängen, den die Association widerrufen kann.
• Niemals transferierbar: der private Registry-Dienst (SaaS), die Workshop- und Trainingsmarke sowie das eigene Review-Badge-Programm. Diese Assets sind das Geschäftsmodell und stehen in keiner Verhandlung zur Disposition.
• Transferierbar nur als Paketlösung: Das Eigentum am Index wechselt ausschließlich zusammen mit (a) einem mehrjährigen bezahlten Maintainer-Vertrag, (b) dauerhaft gesicherter Attribution auf den eingebrachten Skills (Anforderung A3) und (c) einer Kopie beziehungsweise gemeinsamen Lizenz der Telemetriedaten. Mündliche Zusagen („den Vertrag regeln wir später") werden nicht akzeptiert; alle Bedingungen gehören in eine einzige unterzeichnete Vereinbarung.
• Telemetrie ab Tag eins beim Betreiber. Install- und Nutzungsdaten (datenschutzkonform aggregiert gemäß Anforderung A9) fallen der Betreibergesellschaft zu; das steht von Beginn an in der Datenschutzerklärung.
• Community Budget nur für separierbare öffentliche Ergebnisse (etwa Tutorials für Autor:innen, Spezifikationsdokumentation), nie für das Verzeichnis selbst [26].

Scheitert Option C, wird vor jedem Zugeständnis an Option A zunächst Option D (neutraler Verein) angeboten; Option A ist nur mit vollständig fixierter Paketlösung akzeptabel.

8.6 Zwischenfazit

Die Analyse zeigt: Das Verzeichnis ist ein strategischer Moat für eine Agentur, kein eigenständiges Produktgeschäft. Der adressierbare Markt ist zu klein und die horizontale Konkurrenz [5], [6] zu schnell für einen tragfähigen bezahlten Marktplatz, dessen steuerliche Plattformpflichten den Nutzen zusätzlich aufzehren würden. Tragfähigkeit entsteht stattdessen durch den dauerhaft kostenlosen Kernkatalog (A12), der Beratungs- und Workshop-Umsatz generiert, während Sponsoring und ein Community-Budget-Zuschuss die geringen Cash-Kosten decken; der Voll-Break-even ist zwischen Monat 12 und 18 plausibel. In der Eigentumsfrage folgt der Entwurf dem Packagist-Präzedenzfall [24]: privater Betrieb mit neutraler Listing-Policy, verhandelter Endorsed-Operator-Status nach dem HACS-Vorbild [25], klar fixierte rote Linien. Für die Einführungsstrategie in Kapitel 9 folgt daraus, dass Community-Legitimität über publizierte Neutralitätsregeln und offene Infrastrukturbeiträge aufgebaut werden muss — nicht über die Abgabe des Assets.

---

9 Einführungsstrategie: Community, Kommunikation und Roadmap

Kernaussagen dieses Kapitels

• Das Verzeichnis positioniert sich nicht als Konkurrenz zu horizontalen Volumenverzeichnissen wie skills.sh oder SkillsMP, sondern besetzt eine neue Kategorie: die kuratierte Vertikale für ein einzelnes Ökosystem — im Community-Vokabular: „TER, aber für Agent Skills" [5], [6], [14].
• Die Roadmap ist ereignisgetrieben und nutzt die realen Fixpunkte des TYPO3-Jahreskalenders: Private Beta im Juli 2026, Soft-Launch auf den TYPO3 Developer Days (6.–8. August 2026, Karlsruhe) [21], Hardening im Herbst, Version 1.0 zur T3CON im November.
• Die Kapazitätsanalyse ist ein zentrales Evaluationsergebnis des Entwurfsprozesses: Das ursprüngliche Einführungsprogramm überstieg die verfügbare Kapazität der Gründungsperson um den Faktor ~2,7 und wurde daraufhin systematisch gekürzt, automatisiert und um eine Deputy-Rolle ergänzt.
• Adoption wird nicht behauptet, sondern gemessen: Sechs-Monats-Ziele für Besuche, Installationen, Beitragende und KI-Zitationsrate machen den Einführungserfolg überprüfbar.

9.1 Positionierung: Kategorie-Erstbesetzung als kuratierte Vertikale

Horizontale Verzeichnisse existieren bereits: skills.sh von Vercel aggregiert Skills themenübergreifend [5], SkillsMP befüllt seinen Katalog per GitHub-Scraping [6], und Anthropic pflegt einen kuratierten Beispielkatalog [4]. Ein Wettbewerb über Volumen wäre gegen diese Anbieter aussichtslos und strategisch falsch. Die vorliegende Arbeit positioniert das Verzeichnis deshalb als Kategorie-Erstbesetzung: die erste kuratierte Vertikale für ein einzelnes CMS-Ökosystem. Das Differenzierungsmerkmal ist nicht Menge, sondern vertikales Vertrauen — jeder Skill ist gegen TYPO3 v14.3 LTS validiert [22], [23], konformitätsgeprüft (A2, A4) und mit sauberer Attribution versehen (A3). Die Snyk-Analyse, nach der rund 13 % öffentlich gelisteter Skills kritische Sicherheitsprobleme aufweisen [7], liefert das zentrale Verkaufsargument gegen ungeprüfte Volumenkataloge (vgl. Kapitel 3). Die Analogie, die sich in der TYPO3-Community selbst erklärt, lautet: „TER, aber für Agent Skills" [14].

Das Zeitfenster für diese Erstbesetzung ist real, aber kurz — die Analyse veranschlagt sechs bis zwölf Monate, bevor ein anderer Akteur die Kategorie benennt. Daraus folgt die Leitentscheidung der Einführung: Geschwindigkeit vor Perfektion.

Die Kernbotschaften sind je Zielgruppe differenziert (vgl. die Stakeholder-Analyse in Kapitel 4):

• Agenturleitung — Marge und Tempo: Nachwuchskräfte liefern bei Upgrades, Content Blocks und WCAG-Audits auf Senior-Niveau; Festpreisprojekte werden wieder profitabel. Der Beleg erfolgt über gemessene Fallstudien, etwa ein Extension-Upgrade von v12 auf v14 in vier Stunden statt drei Tagen.
• Entwickler:innen — Qualität: Skills kodieren die Konventionen des TYPO3-Kernteams (Rector, Testing, Konformität), sodass der KI-Coding-Agent keine veralteten APIs mehr halluziniert.
• Freelancer:innen — Hebel: Mit 137 kuratierten Skills [1] und einer Ein-Kommando-Installation (A5) über die rund 30 spezifikationskonformen Agents hinweg [2] arbeitet eine Einzelperson mit der Werkzeugtiefe einer kleinen Agentur.

Die Namensfrage folgt dem in Kapitel 7 entwickelten markenrechtlichen Rahmen: Start unter neutraler Domain, deskriptive Formulierung „Agent Skills für TYPO3", paralleler Antrag auf Markennutzungserlaubnis bei der TYPO3 Association [17], [18].

9.2 Ereignisgetriebene Roadmap

Die Einführung orientiert sich nicht an abstrakten Quartalen, sondern an den realen Ereignissen des TYPO3-Kalenders. Damit erzeugt jeder Meilenstein eine natürliche Deadline und ein eingebautes Publikum. Tabelle 9.1 fasst die Phasen zusammen.

Tabelle 9.1: Ereignisgetriebene Einführungs-Roadmap des Verzeichnisses

Eine Einschränkung ist dokumentationswürdig: Die T3CON-Termine für 2026 waren zum Untersuchungszeitpunkt (Juli 2026) noch nicht angekündigt; die Vorjahresveranstaltung fand Ende November statt. Der 1.0-Meilenstein ist daher als Go/No-go-Entscheidung formuliert, die erst nach Bestätigung von Terminen und Call for Papers fixiert wird — ein erster Vorgriff auf den Kapazitätsrealismus in Abschnitt 9.4.

9.3 Kanäle und Contributor-Gewinnung im TYPO3-Ökosystem

Die Kommunikationskanäle sind bewusst auf das TYPO3-Ökosystem beschränkt, in dem die Zielgruppen bereits organisiert sind. Vier Kanäle tragen die Hauptlast: erstens ein Community-Artikel auf typo3.org bzw. news.typo3.com; zweitens der TYPO3-Slack mit den Kanälen für CMS-Diskussion, Meilensteine und regionale Gruppen, perspektivisch ergänzt um einen eigenen Agent-Skills-Kanal; drittens Vorträge auf TYPO3camps und Usergroup-Meetups als wiederholbares 20-Minuten-Demo-Format; viertens LinkedIn als primärer B2B-Kanal im DACH-Raum, bewusst in der persönlichen Stimme der Gründungsperson statt über ein Unternehmensprofil. Ergänzend dienen Podcast- und Newsletter-Formate der Community sowie kurze Demo-Videos (Prompt → Ergebnis → Installationsbefehl) der Sichtbarkeit.

Strategisch bedeutsamer als die Kanäle ist der Mechanismus der Contributor-Gewinnung: Das Verified-Publisher-Programm macht potenzielle Mitbewerber zu Beitragenden. Agenturen erhalten ein verifiziertes Profil mit Logo, Backlink und eigener Skill-Portfolio-Seite — für die Agentur kostenloses Marketing, für das Verzeichnis Inhalte und Legitimität. Der Präzedenzfall Netresearch, bereits größter externer Beitragender des Startkatalogs [1], [9], belegt die Tragfähigkeit dieses Modells. Die dazugehörige Verhaltensregel ist zugleich Governance-Prinzip (vgl. Kapitel 6): Attribution wird niemals entfernt; die CI-Prüfung, die dies erzwingt, wird offensiv als Vertrauensmerkmal kommuniziert (A3).

Flankierend tritt der Betreiber der TYPO3 Association bei [27] — als Glaubwürdigkeitssignal und als Voraussetzung für den Markennutzungsantrag. Langfristig soll das Verzeichnis der Association als Community-Initiative angetragen werden: Die TER-Analogie macht es anschlussfähig an bestehende Community-Strukturen [14], [26], und der Status als Ökosystem-Infrastruktur mit der Gründungsperson als Maintainer:in ist der wirksamste Schutz gegen einen konkurrierenden Fork (vgl. Kapitel 8 und Kapitel 10).

9.4 Kapazitätsrealismus: das Kapazitätsmodell als Evaluationsergebnis

Die methodisch aufschlussreichste Erkenntnis der Einführungsplanung entstand nicht beim Entwurf, sondern bei seiner Prüfung: Die Aggregation aller Arbeitsströme über die geplanten Phasen ergab, dass das ursprüngliche Programm die verfügbare Kapazität der Gründungsperson um den Faktor ~2,7 überstieg. Im Sinne des Design-Science-Paradigmas ist dies ein Evaluationsergebnis erster Ordnung — der erste Artefakt-Entwurf der Einführung scheiterte am Machbarkeitstest und wurde revidiert. Tabelle 9.2 dokumentiert das Kapazitätsmodell.

Tabelle 9.2: Aggregiertes Kapazitätsmodell aller Einführungs-Arbeitsströme (Stunden pro Woche)

Das Modell zeigt zweierlei. Erstens ist die Spitzenlast strukturell: Gerade die Monate vor T3DD26 und T3CON — die beiden wichtigsten Meilensteine — verlangen das ~2,7-Fache der verfügbaren Zeit. Zweitens sind selbst die „ruhigen" Monate um rund 60 % überzeichnet. Der Plan war damit in seiner ursprünglichen Form nicht nur ambitioniert, sondern infeasibel — unabhängig von Disziplin oder Motivation der Gründungsperson.

Aus dieser Diagnose folgen drei Konsequenzen. Die erste ist eine Deputy-Rolle: eine zweite Person (intern oder als Contractor mit 10–15 Stunden/Woche, kalkuliert mit etwa 1.500–2.500 € monatlich, vgl. das Betreibermodell in Kapitel 8), die vier Aufgaben dokumentiert übernehmen kann — Triage des Security-Postfachs samt Eingangsbestätigung, Ausführung eines dokumentierten Takedown bzw. Yank (A6), Merge risikoarmer Skill-Pull-Requests nach schriftlicher Checkliste sowie Publikation des Digests aus einer Vorlage.

Die zweite Konsequenz betrifft den Bus-Faktor. Ein Register der Single Points of Failure identifiziert fünf kritische Abhängigkeiten von einer einzigen Person: die Security-Intake- und Yank-Autorität (verpasste Reaktionsfristen bei Urlaub oder Krankheit beschädigen öffentliches Vertrauen), die Signatur- und Provenienzschlüssel (Verlust blockiert Publikation, Leak wäre ein Supply-Chain-Vorfall), die Kontrolle über GitHub-Organisation, DNS und Registry-Namensräume (Kontosperre bedeutet Projekttod), die alleinige PR-Freigabe (die Warteschlange verrottet in Überlastmonaten) und die alleinige öffentliche Stimme. Die Gegenmaßnahmen sind unspektakulär, aber verbindlich: geteiltes Postfach mit zweiter reaktionsberechtigter Person, Schlüssel in einem gemeinsamen Credential-Vault mit Offline-Backup und Rotations-Runbook, eine zweite Organisations-Eigentümerschaft, Merge-Rechte für den Deputy sowie ein „Break-Glass"-Runbook mit der schriftlichen Anweisung, bei mehr als 14 Tagen Ausfall der Gründungsperson die Aufnahme neuer Skills einzufrieren, die Security-Reaktion aber aufrechtzuerhalten.

Die dritte Konsequenz ist die Priorisierung: Was nicht in die Kapazität passt, wird gestrichen, reduziert, automatisiert oder verschoben — und zwar dokumentiert, nicht stillschweigend. Tabelle 9.3 fasst die revidierte Verpflichtungsliste zusammen.

Tabelle 9.3: Revidierte Verpflichtungsliste nach der Kapazitätsanalyse

Bemerkenswert ist die Revision der Security-Zusage: Statt eine unhaltbare Reaktionsfrist zu publizieren und später zu brechen, wird die weichere Zusage veröffentlicht, bevor sich jemand auf die härtere verlassen kann. Transparente, publizierte Review-Zusagen (A7) sind nur dann vertrauensbildend, wenn sie kapazitätsgedeckt sind — dieser Zusammenhang wird in der Risikoanalyse in Kapitel 10 wieder aufgegriffen.

9.5 Messbare Adoptionsziele

Die Einführung gilt nicht als erfolgreich, weil sie stattgefunden hat, sondern wenn definierte Adoptionsgrößen erreicht werden. Tabelle 9.4 nennt die Zielwerte; Datengrundlage ist ausschließlich die datenschutzkonforme, aggregierte Telemetrie des Verzeichnisses (A9).

Tabelle 9.4: Adoptionsziele der Einführungsphase

Die KI-Zitationsrate verdient Erläuterung: In einem standardisierten Audit werden gängigen KI-Assistenten zehn typische Fragen zu TYPO3 und Agent Skills gestellt und protokolliert, ob das Verzeichnis als Quelle genannt wird. Da horizontale Kataloge wie skills.sh von Sprachmodellen ingestiert werden [5], publiziert das Verzeichnis dorthin weiter — mit kanonischen Rückverweisen, sodass die dominante TYPO3-Präsenz in den Volumenkatalogen auf die kuratierte Vertikale einzahlt. Nach der Kapazitätsrevision (Abschnitt 9.4) läuft dieses Audit quartalsweise und geskriptet. Verfehlte Zielwerte lösen keine Beschönigung aus, sondern die in Kapitel 10 beschriebene Neubewertung des Betreibermodells; eine Wiederausweitung der reduzierten Verpflichtungen erfolgt erst, wenn das Kapazitätsdefizit nachweislich geschlossen ist.

9.6 Zwischenfazit

Die Einführungsstrategie besetzt die Kategorie der kuratierten Vertikale, bevor sie ein anderer Akteur benennt, und nutzt dafür die natürlichen Fixpunkte des TYPO3-Kalenders von der Privaten Beta im Juli 2026 über den Soft-Launch auf den T3DD26 [21] bis zur Version 1.0 zur T3CON. Kanäle und Contributor-Gewinnung setzen konsequent auf vorhandene Community-Strukturen; das Verified-Publisher-Programm verwandelt potenzielle Mitbewerber in Beitragende. Der wissenschaftlich zentrale Befund ist jedoch die Kapazitätsanalyse: Das ursprüngliche Programm überstieg die Kapazität der Gründungsperson um den Faktor ~2,7 und wurde per dokumentierter Priorisierung, Deputy-Rolle und Bus-Faktor-Absicherung auf ein tragfähiges Maß revidiert. Für den Entwurf folgt daraus, dass Vertrauenszusagen wie Review-Fristen (A7) und Rückruffähigkeit (A6) nur so belastbar sind wie die Kapazität dahinter — ein Prinzip, das die Evaluation in Kapitel 10 und die ökonomische Tragfähigkeit (A12) in Kapitel 8 unmittelbar verbindet.

---

10 Evaluation und Risikoanalyse: Belastbarkeit des Entwurfs

Kernaussagen dieses Kapitels

• Der Entwurf wurde einer adversarialen Gap-Analyse unterzogen; vier materielle Lücken wurden identifiziert und in den Entwurf zurückgeführt: planmäßiger Vertrauensverfall, Eigentumswiderspruch, außervertragliche Haftung und Kapazitätsdefizit.
• Das strukturell schwerste Risiko ist der planmäßige Verfall der Kompatibilitätsnachweise im TYPO3-LTS-Rhythmus; eine vollständige menschliche Re-Zertifizierung des Katalogs ist wirtschaftlich nicht tragfähig und wird durch Freshness-Status, ein Core-Certified-Tier und ereignisgetriebene Eval-Sweeps ersetzt (A11).
• Die Anforderungsmatrix zeigt: Alle zwölf Anforderungen A1–A12 sind durch benennbare Mechanismen adressiert, aber keine ohne Restrisiko — insbesondere A4 (Prüftiefe), A7 (Review-SLA) und A12 (Betreiberkapazität) bleiben von der personellen Ausstattung abhängig.
• Der Entwurf ist eine Ex-ante-Konzeption ohne Feldevaluation; seine Belastbarkeit stützt sich auf Präzedenzfall-Validierung, nicht auf Betriebsdaten.

10.1 Methodik: adversariale Gap-Analyse als Evaluationsinstrument

Design-Science-Artefakte, die noch nicht im Feld betrieben werden, lassen sich nicht empirisch messen — wohl aber systematisch angreifen. Die vorliegende Arbeit evaluiert den Entwurf daher mit einer adversarialen Gap-Analyse (Completeness-Critique): Der Gesamtentwurf aus den Kapiteln 5 bis 9 wurde gezielt auf innere Widersprüche, ungedeckte Kostenpfade und stillschweigende Annahmen hin befragt, ergänzt um eine Präzedenzfall-Validierung gegen dokumentierte Erfolgs- und Schadensfälle vergleichbarer Registries (Kapitel 3). Maßstab der Kritik war der kanonische Anforderungskatalog A1–A12 aus Kapitel 4: Eine Lücke gilt als materiell, wenn sie eine Anforderung dauerhaft unerfüllbar macht oder ihre Erfüllung nur unter unbenannten Kosten möglich wäre.

Das Verfahren identifizierte vier materielle Lücken. Entscheidend für die Bewertung des Artefakts ist, dass alle vier in den Entwurf zurückgeführt werden konnten: Sie führten zu konkreten Entwurfsänderungen (Freshness-Modell, Endorsed-Operator-Struktur, Badge-Umformulierung, Deputy-Modell), nicht nur zu Fußnoten. Die Abschnitte 10.2 bis 10.5 dokumentieren jeweils Befund, Rückführung und verbleibendes Restrisiko.

10.2 Risiko 1: Planmäßiger Vertrauensverfall durch LTS-Zyklen

Das Kernversprechen des Verzeichnisses — versionierte, datierte Kompatibilitätsaussagen je Skill (A2) — trägt ein Ablaufdatum in sich. TYPO3 folgt einem etwa 18-monatigen LTS-Rhythmus [22], [23]; mit jeder Hauptversion entwerten sich Nachweise, die gegen die Vorgängerversion erbracht wurden. Die Analyse der historischen Breaking-Changes-Profile zeigt, dass pro Hauptversion mit inhaltlichem Überarbeitungsbedarf bei etwa 50–60 % der TYPO3-spezifischen Skills zu rechnen ist — nicht nur mit dem Aktualisieren von Versionsangaben. Ein im Herbst 2026 startendes Verzeichnis stünde bereits wenige Monate später vor dem Beginn des nächsten Zyklus.

Die Kostenseite ist quantifizierbar. Eine vollständige menschliche Re-Zertifizierung des Startkatalogs von 137 Skills [1] wurde nach Aufwandsklassen geschätzt:

Tabelle 10.1: Geschätzte Re-Zertifizierungskosten je LTS-Zyklus für den Startkatalog (Quelle: eigene Aufwandsschätzung)

Rund 31.000 € alle 18 Monate sind für einen kleinen Betreiber nicht tragfähig; die Anforderung A2 wäre ohne Gegenmaßnahme nur im ersten Zyklus erfüllbar. Die Rückführung in den Entwurf erfolgt dreistufig und begründet die Anforderung A11 (Alterungstransparenz): Erstens bleibt jeder Nachweis als datierte, versionsbezogene historische Tatsache erhalten; ein berechneter Freshness-Status (aktuell, veraltet, überholt) wird im Index geführt, nicht im Badge gespeichert — herabstufen mit Kontext statt löschen. Zweitens wird der Katalog gestuft: Ein Core-Certified-Tier von rund 40 Skills erhält eine garantierte menschliche Re-Zertifizierung binnen 30 Tagen nach LTS-Release, was die garantierten Kosten auf etwa 10.000–12.000 € je Zyklus begrenzt; der Rest fällt unter die publizierte Verfallsregel. Drittens ersetzen ereignisgetriebene automatisierte Eval-Sweeps — ausgelöst durch erste Release, Release Candidate und LTS einer neuen Hauptversion — die laufende Vollprüfung; ergänzend kommen Contributor-Re-Zertifizierung mit sichtbarer Namensnennung und eine Förderung über das TYPO3 Community Budget für einen öffentlichen Revalidierungs-Sprint in Betracht [26]. Restrisiko: Die Terminprojektion der nächsten Hauptversion ist unbestätigt, und der Ertrag aus Community-Beiträgen (realistisch 20–30 % des Katalogs) ist nicht garantiert.

10.3 Risiko 2: Eigentumswiderspruch — Moat gegen Community-Gut

Die zweite Lücke ist ein innerer Widerspruch: Das Betreibermodell (Kapitel 8) begründet den Aufwand mit dem Wert des Verzeichnisses als Reputations- und Akquisekanal, während die Einführungsstrategie zugleich Nähe zur TYPO3 Association sucht. Eine Übergabe an die Association würde den kommerziellen Anreiz des Betreibers eliminieren; eine Finanzierung des Verzeichnisses über das Community Budget scheidet ohnehin aus, weil dessen Regeln Vorhaben mit direktem Erwerbszweck ausschließen [26] — ein Antrag wäre disqualifizierend und reputationsschädigend.

Die Auflösung liefert die Präzedenzfall-Analyse aus Kapitel 3: Die erfolgreichsten Community-Indizes wurden nie übereignet. Packagist wird bis heute von einer privaten Gesellschaft betrieben, die kommerzielle Dienste darüber anbietet [24]; HACS blieb im Home-Assistant-Ökosystem in Community-Hand und erhielt Anerkennung und Ressourcen über eine Foundation-Partnerschaft statt über einen Eigentumsübergang [25]. Der Entwurf übernimmt daher das in Kapitel 8 entwickelte Endorsed-Operator-Modell: offener Index mit neutraler, publizierter Listing-Politik im Eigentum einer separaten Betreibereinheit, kombiniert mit einer angestrebten Markenlizenz und einem Beirat mit Community-Sitzen; eine Übertragungsoption — nicht -pflicht — bleibt verhandelbar. Voraussetzung ist eine wortmarkenfreie Domain, da die Trademark-Policy der Association die Verwendung von „TYPO3" in Domains untersagt [17], [18]. Restrisiko: Das Modell hängt von einer Verhandlung ab, deren Ausgang offen ist; verweigert die Association die Anerkennung, bleibt der Index legitim, aber ohne offiziellen Halo.

10.4 Risiko 3: Haftung außerhalb vertraglicher Kanäle

Die dritte Lücke betrifft den rechtlichen Rahmen (Kapitel 7): Wer Skills über Ein-Kommando-Installation, Git-Klon oder Agent-Mechanismen bezieht [11], [12], sieht keine Nutzungsbedingungen — es kommt kein Vertrag zustande, und Haftungsbegrenzungen binden niemanden. Die Exposition läuft dann über außervertragliche Vertrauenshaftung: Gerade die kuratierenden Qualitätsaussagen des Verzeichnisses („geprüft", „getestet") sind geeignet, ein haftungsbegründendes Sonderverhältnis zu erzeugen, das ein bloßes GitHub-Repository nicht erzeugen würde. Hinzu tritt die EU-Produkthaftungsrichtlinie, die Software als Produkt erfasst und deren Umsetzungsfrist am 9. Dezember 2026 endet [19]; die Ausnahme für freie Software greift nur außerhalb kommerzieller Tätigkeit — eine Kopplung an das kommerzielle Angebot des Betreibers kann nicht abdingbare Haftung wiederaufleben lassen.

Die Rückführung bestätigt und verschärft die Anforderung A10: Badges formulieren Prozess- statt Ergebnisaussagen („prozessgeprüft am Datum X für Version Y" statt „sicher"), sind datiert, versionsgebunden und mit publizierten Kriterien verknüpft; personenbezogene Reviewer-Badges entfallen. Disclaimer werden in alle fünf Bezugskanäle eingebettet — Skill-Datei, Lizenz, Installer-Ausgabe, Agent-Beschreibung, Badge-Detailseite —, da sie zwar keine Haftung deckeln, aber Vertrauenstatbestände abschwächen. Neu aufgenommen wurde ein Versicherungs-Workstream (IT-Berufshaftpflicht mit Vermögensschadendeckung), der im ursprünglichen Entwurf fehlte. Restrisiko: Der Versicherungsmarkt entwickelt derzeit KI-Ausschlussklauseln; ob eine Deckung für kuratierende Aussagen über KI-ausgeführte Anleitungen zu tragfähigen Prämien erhältlich ist, ist zum Untersuchungszeitpunkt offen. Der Entwurf löst dieses Problem nicht — er benennt es und definiert einen Entscheidungspunkt (Entitätentrennung statt Versicherung).

10.5 Risiko 4: Kapazität und Bus-Faktor

Die vierte Lücke ist die banalste und zugleich existenziellste: Die Summe aller Workstreams — Aufbau, Kuratierung, Kommunikation, Vorträge, Eval-Betrieb, Sicherheitsprozesse — übersteigt in der Startphase die realistische Verfügbarkeit einer einzelnen Gründungsperson um ein Mehrfaches; selbst ruhigere Monate bleiben deutlich überzeichnet. Zugleich konzentrieren sich sicherheitskritische Funktionen (Security-Eingang, Yank-Befugnis, Signaturschlüssel, Organisations- und Domainzugänge) auf eine Person — ein klassischer Single Point of Failure, der die in Kapitel 6 zugesagten Sicherheitsprozesse (A4, A6, A7) im Krankheits- oder Überlastungsfall aushebelt.

Die Rückführung in die Einführungsstrategie (Kapitel 9) umfasst vier Elemente: eine vertraglich gebundene Stellvertretung mit dokumentierten Yank- und Merge-Rechten; einen Break-Glass-Runbook nebst geteiltem Credential-Vault und zweiter Organisationsinhaberschaft; eine ehrlichere Formulierung des Review-SLA (Bestätigung binnen zwei Werktagen statt ambitionierterer Zusagen), solange keine zweite Responder-Person aktiv ist; sowie eine Reduktion der Kommunikations- und Veranstaltungszusagen auf ein tragfähiges Maß. Restrisiko: Das Modell bleibt personenzentriert; es reduziert den Bus-Faktor von eins auf zwei, nicht mehr.

10.6 Externe Bedrohungen

Neben den inneren Lücken wurden externe Bedrohungen bewertet und gerankt. (1) Eine offizielle TYPO3-Initiative — analog zum offiziellen Drupal-Skills-Projekt [8] — würde über Nacht auf Legitimität gewinnen; die Mitigation ist Kooperation statt Konkurrenz, für die das Endorsed-Operator-Modell den Rahmen bietet. Dass Community-Registries neben offiziellen Kanälen bestehen können, wenn sie ihren Status ehrlich ausweisen und schneller sind, zeigt der HACS-Präzedenzfall [25]. (2) Eine Expansion des kuratierten Netresearch-Marktplatzes [9] ist zugleich Bedrohung und Chance: webconsulting führt bereits Attributionen dieser Skills; frühe Partnerschaft und gemeinsame Governance schlagen ein gespaltenes Ökosystem zweier Agenturen. (3) Horizontale Verzeichnisse wie skills.sh [5] oder SkillsMP [6] können jederzeit einen TYPO3-Tag anbieten und gewinnen sofort auf Volumen; sie können jedoch strukturell nicht testen — die Differenzierung liegt in geprüfter LTS-Kompatibilität, nicht in Listenlänge. (4) Anthropic selbst bleibt mit seinem Beispielkatalog und der Plugin-Infrastruktur horizontal ausgerichtet [4], [11]; das direkte Risiko ist gering, zu beachten sind aber die Namensbeschränkungen rund um die Marke des Anbieters — die Positionierung erfolgt über den offenen Spezifikationsbegriff [2].

10.7 Anforderungsabdeckung: Matrix A1–A12

Die zusammenfassende Evaluation prüft, ob jede Anforderung durch einen benennbaren Mechanismus gedeckt ist und welches Restrisiko verbleibt.

Tabelle 10.2: Abdeckung des Anforderungskatalogs A1–A12 mit verbleibenden Restrisiken

Das Bild ist konsistent: Keine Anforderung ist ungedeckt, keine ist risikofrei erfüllt. Die Restrisiken konzentrieren sich auf zwei Achsen — Zeit (A2/A11: Verfall) und Personen (A4/A7/A12: Kapazität) — und genau dorthin lenkt der Entwurf seine Gegenmaßnahmen.

10.8 Limitationen der Arbeit

Drei Limitationen begrenzen die Aussagekraft. Erstens ist die Arbeit eine Einzelfallstudie: Der Entwurf ist auf das TYPO3-Ökosystem zugeschnitten; ob die Mechanismen auf andere vertikale Ökosysteme übertragbar sind, wird plausibilisiert, aber nicht gezeigt. Zweitens handelt es sich um einen Ex-ante-Entwurf ohne Feldevaluation: Es liegen keine Betriebsdaten zu Installationszahlen, Review-Durchsätzen oder tatsächlichen Sicherheitsvorfällen des Verzeichnisses vor; die Evaluation stützt sich auf adversariale Kritik und Präzedenzfälle, nicht auf Messung. Drittens ist die Quellenlage die eines sehr jungen Ökosystems: Zentrale Belege sind Blogposts, Herstellerdokumentationen und Repositorien statt begutachteter Literatur, und Kennzahlen wie der Anteil sicherheitsproblematischer Skills [7] beruhen auf einzelnen Erhebungen. Schließlich ist intellektuelle Ehrlichkeit geboten bei dem, was der Entwurf nicht löst: Er beseitigt die außervertragliche Haftungsexposition nicht, sondern mindert sie; er garantiert weder Versicherbarkeit noch den Verhandlungserfolg mit der TYPO3 Association; und er kann eine offizielle, gut ausgestattete Ökosystem-Initiative nicht überbieten, sondern ihr nur ein anschlussfähiges Kooperationsangebot machen.

10.9 Zwischenfazit

Die adversariale Gap-Analyse hat den Entwurf an vier Stellen materiell verändert und dadurch gestärkt: Alterungstransparenz statt stillschweigend verfallender Nachweise, Endorsed-Operator statt Eigentumsillusion, Prozess-Badges samt Versicherungs-Workstream statt ungeprüfter Haftungsannahmen und ein Deputy-Modell statt eines Bus-Faktors von eins. Die Anforderungsmatrix zeigt vollständige, aber nirgends risikofreie Abdeckung; die verbleibenden Risiken sind benannt, datiert und mit Entscheidungspunkten versehen. Für den Entwurf folgt daraus: Seine Belastbarkeit hängt weniger von der Architektur als von Kapazität, Verhandlungsergebnissen und der Disziplin ab, publizierte Verfalls- und Governance-Regeln auch gegen sich selbst gelten zu lassen. Eine Feldevaluation im laufenden Betrieb bleibt der notwendige nächste Schritt und wird in Kapitel 11 als Ausblick konkretisiert.

---

11 Fazit und Ausblick

Kernaussagen dieses Kapitels

• Alle vier Forschungsfragen lassen sich beantworten; die tragende Erkenntnis ist institutioneller Natur: Vertrauen muss als geprüfter, datierter und widerrufbarer Prozess organisiert werden, nicht als Behauptung.
• Die Arbeit liefert sechs übertragbare Beiträge – vom Anforderungskatalog A1–A12 bis zum Betreibermodell „Endorsed Operator" – die sich auf andere vertikale Ökosysteme übertragen lassen.
• Offen bleiben Feldevaluation, Standardisierung von Trust-Metadaten und die automatisierte Erkennung von Prompt Injection in Prosa – drei konkrete Anschlussarbeiten.

11.1 Beantwortung der Forschungsfragen

F1 – Defizite bestehender Verteilwege und Lehren etablierter Registries. Die Analyse in Kapitel 2 und 3 zeigt eine strukturelle, keine graduelle Lücke: Horizontale Verzeichnisse können prinzipbedingt nicht leisten, was Vertrauen in einer Vertikale erfordert – fachliche Prüfung gegen eine konkrete Plattformversion, Provenienz, Rückruf. Die Registry-Geschichte liefert dafür fünf belastbare Lehren (L1–L5): Discovery und Distribution entkoppeln; Maintainer:innen statt Einzelartefakte prüfen; Publisher-Kompromittierung als Normalfall einplanen; Prosa als Angriffsfläche behandeln; Governance vor dem Wachstum schriftlich fixieren.

F2 – Anforderungen der Stakeholder. Aus den Perspektiven nutzender Entwickler:innen, beitragender Autor:innen und des Betreibers ergibt sich der Katalog A1–A12 (Kapitel 4). Sein Kern ist ein doppeltes Vertrauensversprechen: Nutzer:innen verlangen belegte, datierte Kompatibilitäts- und Sicherheitsaussagen; Autor:innen verlangen faire, transparente und planbare Aufnahmeprozesse. Beide Seiten verlangen, dass das Verzeichnis auch im Fehlerfall handlungsfähig bleibt (Yank, Advisories).

F3 – Gestaltung des Verzeichnisses. Der Entwurf beantwortet die Frage in drei Dimensionen. Technisch: Git-first-Architektur mit statischem Index als öffentlichem Vertrag, CI-Qualitäts-Gates einschließlich Eval-Harness gegen reale TYPO3-Projekte, Distribution über alle etablierten Kanäle (Kapitel 5). Organisatorisch: vierstufige Review-Pipeline, verdiente Namensräume, Sicherheitsprozess nach dem Vorbild des TYPO3 Security Teams [15] (Kapitel 6). Rechtlich: markenrechtlich saubere Benennung [17], SPDX-basierte Lizenzarchitektur, DSA-konforme Meldewege [20] und – als zentrale Konsequenz der Haftungsanalyse – Badge-Semantik als datierte Prozessaussagen statt Ergebniszusicherungen (Kapitel 7).

F4 – Tragfähigkeit des Dauerbetriebs. Die ökonomische Analyse (Kapitel 8) ist eindeutig: In einem Nischen-Ökosystem trägt sich das Verzeichnis nicht als Produkt, wohl aber als strategische Infrastruktur – kostenloser Kernkatalog, Erlöse aus Workshops, Sponsoring und später privaten Registries. Das Betreibermodell folgt dem Packagist-Präzedenzfall [24]: privater Betrieb mit neutraler, veröffentlichter Listing-Policy und angestrebtem Endorsed-Operator-Status. Die betriebliche Grenze ist real (Kapitel 9): Ohne Stellvertretung und Priorisierung überfordert das Programm eine einzelne Betreiberperson um ein Mehrfaches.

11.2 Beiträge der Arbeit

Tabelle 11.1: Beiträge der Arbeit und ihre Übertragbarkeit

Der rote Faden durch alle sechs Beiträge ist dieselbe Einsicht: Ein Verzeichnis verkauft keine Skills, sondern geprüfte Aussagen über Skills. Alles am Entwurf – Architektur, Governance, Recht, Ökonomie – dient der Belastbarkeit dieser Aussagen über die Zeit.

11.3 Limitationen

Die wesentlichen Grenzen der Arbeit sind in Kapitel 10 ausgewiesen und seien hier nur benannt: Es handelt sich um eine Einzelfallstudie am Beispiel TYPO3; der Entwurf ist ex ante und ohne Feldevaluation; die Quellenlage eines sehr jungen Ökosystems ist teilweise grau (Blogposts, Herstellerangaben) und wurde, wo möglich, durch Primärquellen abgesichert. Zahlenangaben – etwa zur Review-Ökonomie – sind begründete Schätzungen, keine Messungen.

11.4 Ausblick

Drei Anschlussarbeiten drängen sich auf:

1. Feldevaluation. Der Launch-Plan (Kapitel 9) erzeugt ab August 2026 reale Nutzungsdaten [21]. Die Adoptionsmetriken aus Kapitel 4 und die Kostenmodelle aus Kapitel 8 und 10 sind dann empirisch prüfbar – einschließlich der Frage, ob die Freshness-Mechanik (A11) das Vertrauen über den TYPO3-v15-Zyklus tatsächlich erhält.
2. Standardisierung von Trust-Metadaten. Kompatibilitäts-, Prüf- und Provenienzaussagen sind heute verzeichnisspezifisch. Ihre Aufnahme in die offene Spezifikation [2] würde geprüfte Skills portabel machen – ein naheliegender Beitrag für die Standardisierungs-Community.
3. Automatisierte Prompt-Injection-Erkennung in Prosa. Die Sicherheitsanalyse zeigt, dass Textinhalte die eigentliche Angriffsfläche sind [7]. Heuristische Linter, wie in Kapitel 5 entworfen, sind ein Anfang; belastbare, evaluierte Detektionsverfahren für natürlichsprachliche Anweisungstexte sind ein offenes Forschungsfeld.

Ob das TYPO3-Ökosystem sein Skills-Verzeichnis von dieser Arbeit, von einer offiziellen Initiative oder von einem Zusammenschluss mehrerer Agenturen erhält, ist zweitrangig. Entscheidend ist, dass es eines erhält, das seine Vertrauensaussagen belegen, datieren und widerrufen kann. Die vorliegende Arbeit zeigt, dass und wie das gebaut werden kann – der Rest ist Gemeinschaftsarbeit.

---

Anhang A: Glossar

---

---

Literaturverzeichnis

Alle Online-Quellen wurden zuletzt im Juli 2026 abgerufen und auf Erreichbarkeit geprüft.

[1] webconsulting: webconsulting-skills – Kuratierte Agent-Skills-Bibliothek (137 Skills). GitHub. https://github.com/dirnbauer/webconsulting-skills

[2] Agent Skills: Specification. agentskills.io. https://agentskills.io/specification

[3] Agent Skills: agentskills/agentskills – Referenz-Repository der Spezifikation. GitHub. https://github.com/agentskills/agentskills

[4] Anthropic: anthropics/skills – Kuratierter Beispielkatalog. GitHub. https://github.com/anthropics/skills

[5] Vercel: skills.sh – Agent-Skills-Verzeichnis. https://www.skills.sh/

[6] SkillsMP: Skill-Marktplatz (GitHub-Scraper). https://skillsmp.com/

[7] Snyk: ToxicSkills – Malicious AI Agent Skills. Snyk Blog. https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/

[8] Drupal.org: Agentic Skills (ai_skills). Projektseite. https://www.drupal.org/project/ai_skills

[9] Netresearch DTT GmbH: claude-code-marketplace. GitHub. https://github.com/netresearch/claude-code-marketplace

[10] Aikido Security: VS Code Extension GitHub Breach (Nx-Vorfall). https://www.aikido.dev/blog/vs-code-extension-github-breach

[11] Anthropic: Claude Code – Plugin Marketplaces. Dokumentation. https://code.claude.com/docs/en/plugin-marketplaces

[12] Vercel Labs: skills – CLI (npx skills add). GitHub. https://github.com/vercel-labs/skills

[13] Model Context Protocol: MCP Registry. https://registry.modelcontextprotocol.io/

[14] TYPO3: Composer Repository (TER) – Deprecation-Hinweis. https://get.typo3.org/misc/composer/repository

[15] TYPO3: Security Team – Prozessdokumentation. docs.typo3.org. https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Security/SecurityTeam/Index.html

[16] Drupal.org: Goodbye Project Applications, Hello Security Advisory Opt-in. https://www.drupal.org/drupalorg/blog/goodbye-project-applications-hello-security-advisory-opt-in

[17] TYPO3 Association: Trademark Usage Policy. docs.typo3.org. https://docs.typo3.org/m/typo3/guide-policy/main/en-us/Association/TrademarkUsagePolicy.html

[18] typo3.org: TYPO3 Trademark Usage – What's Allowed and What's Not. https://typo3.org/article/typo3-trademark-usage-whats-allowed-and-whats-not

[19] Europäische Union: Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte. EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L2853

[20] Europäische Kommission: The Digital Services Act. https://digital-strategy.ec.europa.eu/en/policies/digital-services-act

[21] TYPO3 GmbH: TYPO3 Developer Days 2026 (T3DD26). https://t3dd.typo3.com/home

[22] TYPO3 GmbH: TYPO3 CMS Development Roadmap. https://typo3.com/typo3-cms/development-roadmap/roadmap

[23] endoflife.date: TYPO3 – Release- und Support-Zyklen. https://endoflife.date/typo3

[24] Packagist Conductors GmbH: About. https://packagist.com/about/

[25] Home Assistant: HACS – The Best Way to Share Community-Made Projects. Blog, 21.08.2024. https://www.home-assistant.io/blog/2024/08/21/hacs-the-best-way-to-share-community-made-projects/

[26] TYPO3 Association: First Call for Community Budget Ideas in 2026. news.typo3.com. https://news.typo3.com/article/first-call-for-community-budget-ideas-in-2026

[27] TYPO3 Association: Membership. https://typo3.org/association/membership

---