Chapter Overview  

Summary  

AI coding agents like Claude Code, Cursor, or Gemini CLI increasingly source specialist knowledge via Agent Skills – portable Markdown knowledge packages based on an open specification supported by around 30 agents. Today, the distribution of these skills predominantly takes place via horizontal directories that optimise for volume rather than verification: a security analysis by Snyk found critical issues in around 13% of the investigated, publicly listed skills – ranging from prompt injection to malware. At the same time, established CMS ecosystems such as TYPO3 lack a curated, vertical alternative.

Following the Design Science paradigm, this work designs a curated Agent Skills directory for the TYPO3 ecosystem. A catalogue of requirements (A1–A12) is derived from an analysis of registry precedents (TER/Packagist, Drupal.org, npm, VS Code Marketplace, HACS) and a stakeholder study. Based on this, four artefacts are designed: a Git-first architecture with a static index and multi-channel distribution, a governance model with a four-stage review pipeline and active recall mechanism, a legal framework (trademark law, licence architecture, Digital Services Act, EU product liability) with legally secure badge semantics, and an operator model based on the Packagist archetype ('Endorsed Operator').

The evaluation via an adversarial gap analysis identifies four material risks – planned erosion of trust over LTS cycles, ownership conflicts, non-contractual liability, and operator capacity limits – and feeds them back into the design. Core finding: A vertical directory is defensible against horizontal catalogues if and only if it organises trust as a verified, dated, and revocable process – not as an assertion.

Keywords: Agent Skills, AI-assisted software development, software registries, curation, trust infrastructure, TYPO3, Design Science Research, supply chain security

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 optimised 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 organises 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

How to Read This Work  

This work is designed for readability. Three conventions help with navigation:

• Each chapter begins with a Key Takeaways box and ends with an interim conclusion. Those short on time can read just these elements along with Chapters 10 and 11.
• The requirements catalogue A1–A12 (Chapter 4) and the lessons L1–L5 (Chapter 3) are used as reference points throughout the entire work; the coverage matrix in Chapter 10 brings both together.
• Numerical source references in the text refer to the bibliography at the end of the work.

1 Introduction 

1.1 Problem Statement  

Software development with AI coding agents is an everyday reality in 2026. Tools like Claude Code, Cursor or Gemini CLI handle implementation, migration and verification tasks largely autonomously – provided they have the correct specialist knowledge. This knowledge is increasingly delivered to agents in the form of Agent Skills: versionable Markdown knowledge packages based on an open specification supported by around 30 agents. A skill can teach an agent how to correctly migrate a TYPO3 extension to the current LTS version, how accessibility checks are conducted, or what conventions a project requires .

With this widespread adoption comes a distribution problem that is well known from the history of software registries – along with a new, more severe twist. The pattern is familiar: where packages become centrally discoverable, catalogues emerge; where catalogues optimise for growth, vetting erodes. What is new is the attack surface: an Agent Skill does not require executable code to cause harm. Even the prose of a SKILL.md can guide an agent towards unwanted behaviour through prompt injection. An analysis by Snyk found critical security vulnerabilities in around 13% of the publicly listed skills investigated . Nevertheless, the dominant horizontal directories continue to index them without verification , – with one explicitly stating that it does not certify security .

For a vertical software ecosystem like TYPO3 – an agency-driven enterprise CMS with a strong foothold in the German-speaking region – this situation is doubly unsatisfactory. Firstly, there is a total lack of technical verification: no horizontal directory tests whether a skill actually works with TYPO3 v14.3 LTS . Secondly, there is no institutional response: unlike the Drupal ecosystem, which already has a CI-validated skills project on its official platform , TYPO3 lacks a curated directory. This gap is simultaneously a risk and an opportunity to actively shape the landscape.

1.2 Research Questions  

The thesis answers four successive research questions:

Table 1.1: Research questions and their mapping within this work

1.3 Methodology  

This work follows the design science research paradigm: knowledge is generated through the design and critical evaluation of an artefact intended to solve a real-world problem. The research process is structured into four steps:

1. Problem identification through the analysis of the skill distribution landscape and documented security incidents (Chapters 2–3).
2. Requirements elicitation from a stakeholder analysis of the TYPO3 ecosystem, consolidated into an explicit catalogue of requirements A1–A12 (Chapter 4).
3. Artefact design in four dimensions: architecture (Chapter 5), governance (Chapter 6), legal (Chapter 7), and operating model (Chapters 8–9).
4. Evaluation in two forms: first, through precedent validation – each key design decision is tested against documented successes and failures of established registries; second, through an adversarial gap analysis that systematically examines the overall design for contradictions and blind spots (Chapter 10).

The empirical basis consists of publicly accessible primary sources (specifications, guidelines, incident reports, official documentation; as of July 2026) as well as the actual initial catalogue of 137 curated skills with provenance and audit tooling . A field evaluation of the operated registry lies outside the scope of this study; the resulting limitations regarding the validity of the findings are detailed in Chapter 10.

1.4 Delimitation  

Three boundaries clarify the subject matter. Firstly, this work addresses the distribution of skills, not their authorship: how to write a technically sound skill is not the subject of this investigation. Secondly, no new skill format is designed; the design deliberately remains within the open specification , in order not to jeopardise portability (Requirement A1). Thirdly, the artefact is a curated directory – not a marketplace with payment processing; the economic analysis in Chapter 8 justifies this limitation.

1.5 Structure of the Thesis  

Chapter 2 establishes the foundations of agent skills and the TYPO3 ecosystem. Chapter 3 analyses registry precedents and distils five transferable lessons (L1–L5). Chapter 4 gathers stakeholder requirements and formulates the catalogue A1–A12. Chapters 5 to 7 design the artefact in its three dimensions of technology, organisation, and law. Chapter 8 clarifies the operating model and viability, while Chapter 9 addresses the integration into the ecosystem, including the operator's capacity limits. Chapter 10 evaluates the overall design and identifies its limitations. Chapter 11 answers the research questions, highlights the contributions of this thesis, and outlines future prospects.

1.6 Interim Conclusion  

The starting position can be summarised in a single sentence: agent skills have become the relevant knowledge infrastructure of AI-assisted development; their distribution has not kept pace with this development. The documented curation gap in horizontal directories meets a TYPO3 ecosystem without its own response – a classic design science problem: real, relevant, and designable. The following chapters show that the solution is less a technical and more of an institutional design task.

2 Foundations: Agent Skills and the TYPO3 Ecosystem 

2.1 Agent Skills: Format, Specification, and Operating Principle  

An Agent Skill is a folder containing a central SKILL.md file: a knowledge package written in Markdown that an AI coding agent — i.e. a tool like Claude Code, Cursor, or Gemini CLI — can load into its working context. The structure follows an open, vendor-independent specification maintained at agentskills.io , with its reference implementation publicly accessible . The core of the format is a frontmatter block in YAML, a machine-readable header section of the file: only the name and description fields are mandatory; optionally, license, compatibility, allowed-tools, and a freely assignable metadata mapping of string to string can be added . This very open metadata mapping is central to this paper, as it allows directory-specific details — such as versioned TYPO3 compatibility statements in the sense of Requirement A2 (the requirements catalogue A1–A12 is derived in Chapter 4) — to be accommodated without violating the portability of the format (Requirement A1). In addition to SKILL.md, a skill folder can contain additional directories such as scripts/, references/, assets/, or examples/; the conformity of a skill structure can be automatically validated using the skills-ref tool , .

The operating principle of the skills is progressive disclosure: the agent initially only sees the name and brief description of all installed skills. Only when a task matches the described purpose does it load the full instruction text, and referenced additional files are only loaded on demand . This principle preserves the limited context window of the language model, making it practicable in the first place to install dozens of skills in parallel — a characteristic that is fundamental for a directory with over a hundred entries .

Skills must be clearly distinguished from two closely related mechanisms. An MCP server is a running service that provides concrete tools to an agent via the Model Context Protocol — a standardised interface protocol — and can be found via its own registry . A CLI tool is an executable program that the agent launches via the command line. A skill, on the other hand, does not have its own runtime environment: it acts declaratively, with its prose guiding the agent's behaviour. This results in a security-specific peculiarity, which Chapter 3 explores in more detail: the primary attack surface of a skill is the text itself, since the instructions alone can contain a prompt injection — i.e. hidden instructions that entice the agent into undesirable behaviour — meaning malicious impact does not require any scripts . Table 2.1 summarises the distinction.

Table 2.1: Distinction between Agent Skills, MCP servers, and CLI tools

2.2 AI Coding Agents and the Distribution Landscape  

Within a short period, the specification has established itself as the common denominator in the tool landscape: around 30 AI coding agents read the SKILL.md format, including Claude Code, Cursor, GitHub Copilot, Gemini CLI, and Codex , . This breadth is the commercial foundation of any directory — and at the same time the justification for requirement A5, which demands a single-command installation across common agents: a skill that only works in a single client misses the core of the open format.

By contrast, the distribution of skills has developed in a significantly more fragmented manner. From a single directory in December 2025, the landscape grew to between eight and twelve competing offerings by mid-2026. Three archetypes can be distinguished. First, curated example catalogues: with anthropics/skills, Anthropic operates a deliberately small-scale exemplary catalogue that explicitly does not aim to be a marketplace . Second, horizontal directories, i.e. cross-topic catalogues: skills.sh by Vercel indexes skills across all domains, offering installation statistics and command-line installation via npx skills add , ; SkillsMP operates as a GitHub scraper with a minimal popularity filter and explicitly states that it makes no security claims regarding the listed skills . Third, decentralised self-management: any Git repository with a manifest file can serve as a plugin marketplace for Claude Code, without any central infrastructure . Table 2.2 categorises these paths.

Table 2.2: Overview of distribution paths for agent skills (as of July 2026)

The pattern is clear: scrapers compete on volume, curators on trust — and so far, no provider covers the technical depth of an individual software ecosystem. The risk of unverified volume is shown by an analysis from Snyk, according to which around 13 per cent of publicly listed skills exhibit critical security issues . Chapter 3 systematically addresses these findings and the resulting lessons; for now, it suffices to state that the gap between horizontal reach and vertical inspection depth is precisely the space that the vertical directory designed in Chapter 5 is intended to fill.

2.3 The TYPO3 Ecosystem as a Subject of Study  

TYPO3 is an open-source enterprise content management system with a clear niche profile: it does not dominate the global market, but is firmly anchored in the German-speaking world — Germany, Austria, and Switzerland — where it is primarily used by specialised agencies for public authorities, universities, and medium-sized enterprises. This agency-centric focus shapes the culture of the ecosystem: professional service providers drive further development, organised via the TYPO3 Association as a member organisation , which also funds projects with no direct commercial purpose through a community budget .

Two structural features are crucial for this study. Firstly, the predictable release cycles: TYPO3 is released in Long-Term Support (LTS) versions with defined maintenance windows; the current LTS is v14.3 from April 2026 , . This timing makes compatibility a dateable, verifiable statement — the basis of requirements A2 and A11, which demand versioned compatibility specifications and transparency of obsolescence across LTS cycles. Secondly, the community's registry experience: with the TYPO3 Extension Repository (TER), the ecosystem has had a central extension registry for decades, including namespace allocation via extension keys. The distribution function of the TER has now largely transitioned to Composer and Packagist; the TER's own Composer repository is officially marked as deprecated . Remarkably, however, what remains: the TER continues to exist as a trust, discoverability, and brand layer. This decoupling of discovery and distribution is one of the most important precedents for the system design and is explored in greater depth in Chapter 3.

In the field of Agent Skills, there is currently no official TYPO3 initiative. The closest activity is the curated marketplace by the agency Netresearch with around 40 skills relating to TYPO3, PHP, and related topics . By comparison, the Drupal community already operates an official, specification-compliant skills project on its central platform — proof that CMS communities are actively occupying this space. For TYPO3, this position is still vacant; the strategic consequences of this are addressed in Chapters 6 and 9.

2.4 The Initial Catalogue as an Empirical Basis  

Design science projects require an artifact foundation on which requirements and design decisions can be concretised. This role is assumed here by the webconsulting-skills initial catalogue: a publicly accessible, curated library of 137 skills, structured into 13 topic clusters . The largest cluster, containing 31 skills, is TYPO3-specific and covers, among other things, Content Blocks, testing, extension upgrades, security, accessibility, and Solr search; the skills target TYPO3 v14.x, with some also covering v13 . Thus, the catalogue serves as both a proof of concept and research material: it allows us to test whether curation on this scale can be sustained with reasonable effort.

Three characteristics of the catalogue are particularly instructive for the subsequent design. First, specification compliance: all skills follow the open SKILL.md format, including a progressive disclosure standard for authors, and are validated using skills-ref , — the practical anticipation of requirement A1. Second, provenance tooling: a machine-readable source directory documents the origin of each skill, a CI check (Continuous Integration, i.e. automated test runs on every change) prevents the removal of attribution blocks, and a three-stage audit script checks structure, provenance drift, and optimisation gaps . Twelve skills in the TYPO3 cluster are demonstrably adapted from Netresearch and attributed accordingly , — requirement A3 in action. Third, the multi-client installation: an installation script links the skills to five clients — Cursor, Claude Code, Gemini CLI, OpenAI Codex, and Windsurf — and an update script synchronises upstream changes while preserving attribution ; this already demonstrates requirement A5 on a small scale. This is complemented by a shared licensing model — MIT for code, CC-BY-SA-4.0 for content, with third-party licences preserved —, the legal implications of which are examined in Chapter 7.

The catalogue is therefore more than just a collection: it is the empirical prototype of the directory. What it lacks — published review criteria (A7), a recall mechanism (A6), protected namespaces (A8), and dated compatibility proofs (A2) — marks exactly the gap that the requirements analysis in Chapter 4 systematises and the system design in Chapter 5 closes.

2.5 Interim Conclusion  

Agent skills are an open, declarative format whose strength — portability across around 30 agents — is at the same time its weakness: the prose itself is an attack surface, and existing horizontal directories index without verifying , , , . Conversely, the TYPO3 ecosystem brings precisely those characteristics that foster trust-building curation: dateable LTS cycles, agency-driven professionalisation, and, with the TER, a proven registry culture , , , . The launch catalogue proves that specification-compliant curation with proof of provenance works practically on a relevant scale . For the design, it follows that: the directory must preserve the openness of the format (A1, A5), institutionalise the verification and provenance practice of the catalogue (A3, A4), and make the TYPO3-specific version logic the key distinguishing feature (A2, A11) — the precedents for this are analysed in the following Chapter 3.

3 Registries as Trust Infrastructure: Precedents and Related Systems 

Design science research does not derive its validity solely from the artefact itself, but from the knowledge base upon which it is built. This chapter therefore analyses registries and directories that have already solved comparable trust issues — or have failed because of them. The selection includes TYPO3's own extension ecosystem (Section 3.1), the governance model of Drupal.org (3.2), documented security incidents in package and extension ecosystems (3.3), skill-specific incidents (3.4), horizontal skill directories (3.5), and the coexistence model of HACS in the Home Assistant ecosystem (3.6). Section 3.7 condenses the findings into five lessons, which are referenced by the requirements analysis in Chapter 4 and the design in Chapters 5 to 8.

3.1 TER and Packagist: Decoupling Discovery, Trust and Distribution  

The TYPO3 Extension Repository (TER) is the most obvious precedent because it addresses the same target audience as the designed directory. Historically, the TER established itself through two mechanisms: for a long time, it was the sole distribution channel for extensions, and by issuing extension keys, it provided a central namespace that guaranteed uniqueness and clear attribution. However, with the establishment of Composer as the standard tool in the PHP world, the TER lost its role as a distribution channel: the canonical resolution of packages shifted to Packagist, which handles the technical delivery as a professionally operated infrastructure . The TER's own Composer repository has since been marked as deprecated; the official documentation recommends obtaining packages directly via Packagist .

Crucially, the TER retained something despite this loss of function: it remained the ecosystem's layer of visibility, trust and branding — with links to Packagist and automated publishing via tools from the TYPO3 ecosystem. Discovery and trust on one hand, and distribution on the other, proved to be decouplable layers. For the design, this directly leads to requirement A5 formulated in Chapter 4: the directory does not need to deliver the packages itself, but can delegate the installation to existing mechanisms of AI coding agents and focus on curation, metadata and discoverability. Similarly, the extension key mechanism supports requirement A8: a reliably managed namespace was an essential part of the TER's trust capital.

3.2 Drupal.org: Vetting Maintainers Instead of Project Reviews  

Drupal.org faced a scaling issue known to every curated directory: a thorough human review of every single project creates long queues and discourages contributors. The response was to switch from project-based admission reviews to Security Advisory Opt-in: individuals are vetted once before they are allowed to publish stable releases with security coverage; after that, they decide on a project-by-project basis whether to opt into security coverage, which is communicated as a visible, binary badge and supported by a volunteer security team . The expensive vetting step is thus shifted from the rapidly growing volume of artifacts to the more slowly growing number of authors.

Furthermore, it is noteworthy that Drupal has already begun transferring this model to agent skills: with the official "Agentic Skills" project, a catalogue exists on Drupal.org that follows the open specification and automatically validates contributions in continuous integration . For the first time, a CMS ecosystem is organising skill curation institutionally — proof that vertical specialist communities step in to handle this task when horizontal services fail to deliver. For the design, this precedent establishes the requirements A3 and A7: provenance depends on vetted individuals and organisations, and the evaluation criteria, along with processing commitments, must be published for the badge to mean something.

3.3 Security Incidents in Package and Extension Ecosystems  

The history of package registries reads like a catalogue of breaches of trust. In the npm ecosystem, four incidents each represent a distinct class of vulnerability: left-pad (2016) showed that the uncontrolled unpublishing of packages breaks entire dependency chains — prompting restrictive unpublish rules; event-stream (2018) demonstrated the handover of a trusted project to malicious maintainers; ua-parser-js (2021) the hijacking of a legitimate account; and finally, the Shai-Hulud worm (2025) self-replicating compromise along the supply chain. The countermeasures — mandatory two-factor authentication for high-impact accounts, signed provenance records, secured publication pathways — all target the act of publication, rather than subsequent content inspection.

The Visual Studio Code Marketplace provides the most recent and, for badge semantics, most instructive case: in 2025 alone, over a hundred malicious extensions had to be removed there, and in May 2026, the Nx Console extension — with around 2.2 million installations, bearing a Verified Publisher badge — was trojanised via the compromised account of an employee . The badge merely confirmed domain ownership of the publishing organisation, not the safety of the content; it was precisely this gap between perceived and actual security guarantees that generated misplaced trust. In addition, the WordPress plugin directory illustrates a governance failure class without external attackers: in 2024, the directory operator itself took over the namespace of a third-party plugin in the course of a commercial dispute — concentration of power without pre-published, neutral dispute resolution rules constitutes a risk in its own right. For the design, these cases substantiate the requirements A4 and A6 (review prior to publication, active recall via "yank" with warning sent to installed clients), A8 (protected namespaces with published dispute resolution rules), and A10 (badges that make precise statements about processes rather than sweeping claims about outcomes).

3.4 Skill-Specific Incidents: ToxicSkills and Prose as an Attack Surface  

That the vulnerability classes of the package world transfer to agent skills — and are exacerbated there — has now been empirically proven. The Snyk study ToxicSkills analysed publicly listed skills from an uncurated catalogue and found critical security issues in around 13%, including skills acting as infostealers that harvest credentials and key material . The structural exacerbation compared to classic packages lies in the nature of the format: at its core, a skill is a natural language instruction to an AI coding agent. Prompt Injection — the smuggling of manipulative instructions into content that the agent treats as trustworthy — thus already works in pure prose, completely without executable code . A review process that only statically analyses scripts consequently checks the wrong half of the artefact.

For the design, this is the most immediate finding of the chapter: Requirement A4 explicitly demands the checking of prose and scripts prior to publication, and the review pipeline designed in Chapter 5 must include a systematic check of the instruction texts for injection patterns alongside static code analysis. At the same time, this finding supports transparency requirement A7: a registry promising security must disclose its verification methodology so that the validity of the check can be assessed by third parties.

3.5 Horizontal Skill Directories and the Structural Curation Gap  

Since the end of 2025, a rapidly growing landscape of horizontal skill directories has emerged. Two representatives mark the poles: Vercel's skills.sh combines an install ranking with a single-command installation method and lists a number of skills in the high five-figure range, but lacks any content review or a discernible business model . According to its own data, SkillsMP, acting as a GitHub scraper, indexes over two million skills, filtering them only based on a minimum level of repository popularity and explicitly stating that it makes no security assurances . This confirms the pattern already outlined in Chapter 2.2: scrapers compete on volume, not on trust.

The curation gap of these offerings is not a matter of negligence, but is structural. A horizontal directory can list and count skills, but it cannot evaluate them functionally: it possesses neither the domain expertise nor the infrastructure to validate a TYPO3 skill against a real TYPO3 installation, or to make a dated compatibility statement for each LTS version — precisely the services described in requirements A2 and A11. A generic topic tag ‘typo3’ is no substitute for a verified LTS matrix. The curated library of 137 skills introduced in Chapter 2, 31 of which are TYPO3-specific , as well as the curated catalogue from Netresearch show that this gap has so far been filled by individual agencies — distributed, without common governance and without shared testing standards. It is precisely this gap that defines the market position of the designed vertical directory.

3.6 HACS and the Open Home Foundation: Co-existence as an Operating Model  

The Home Assistant Community Store (HACS) answers a question that the proposed directory will face in relation to the TYPO3 Association: Can a community-driven directory permanently co-exist alongside official structures? HACS has succeeded in doing this for years because it meets two conditions: it is faster and has a lower barrier to entry than the official channel, and it communicates its status honestly — content is clearly flagged as "not officially supported", preventing any false assumption of authority . The organisational link to the Open Home Foundation also demonstrates a path for how an initially private community project can be transferred into neutral, non-profit stewardship . For the operating model in Chapter 8 and the roll-out strategy in Chapter 9, HACS is therefore the central reference case: co-existence is possible when clarity of status and speed come together — and a subsequent handover to an ecosystem institution is factored in from the very beginning.

3.7 Five Transferable Lessons  

From the analysed precedents, five lessons can be derived, which are referenced as L1 to L5 in the remainder of this work:

1. L1 — Decouple Layers: Discovery and trust are separable from the distribution channel; the registry occupies the trust layer and delegates delivery to existing installation paths of AI coding agents (TER/Packagist , ; basis for the architecture in Chapter 5 as well as A1 and A5).
2. L2 — Vet People, Badge Artefacts: One-time vetting of maintainers scales better than individually checking every single artefact; project-specific badges make the coverage visible (Drupal.org , ; basis for the governance model in Chapter 6 as well as A3 and A7).
3. L3 — Account for Account Compromise: The takeover of trusted accounts beats any content check; what is needed are secured publication paths, proof of provenance, re-evaluation of every version, and an active recall mechanism (npm incidents, Nx Console ; basis for the security processes in Chapter 6 as well as A4 and A6).
4. L4 — Prose is an Attack Surface: Skills can already attack via natural language instructions; review must cover instruction texts and scripts equally and disclose the methodology (ToxicSkills ; basis for the review pipeline in Chapter 5 and the badge semantics in Chapter 7 according to A4 and A10).
5. L5 — Governance Before Growth: Namespace, dispute, and handover rules must be published before growth, and a path into a neutral, community-aligned custodianship prevents concentration of power (WordPress namespace conflict, HACS/Open Home Foundation ; basis for Chapters 6 and 8 as well as A8 and A12).

Table 3.1: Registry precedents, their governance models, and the derived lessons L1–L5.

3.8 Interim Conclusion  

The precedent analysis shows that the trust issues of a skill directory are not new, but have been repeatedly experienced in package and extension ecosystems — and that skills expand the known classes of errors to include the attack surface of prose . None of the investigated horizontal directories closes the curation gap for a CMS ecosystem; at the same time, Drupal proves that vertical specialist communities can take on this task institutionally . The five lessons L1 to L5 thus form the empirical bridge of this thesis: they feed into Chapter 4 as the justification for requirements A1 to A12, structure the architectural decisions in Chapter 5, the governance model in Chapter 6, and the operating model in Chapter 8. Consequently, the design does not have to start from scratch, but can transfer proven mechanisms — separation of layers, maintainer vetting, mandatory provenance, prose scanning, and pre-published governance — to the skill context.

4 Requirements Analysis: Stakeholders, Use Cases and Trust Needs 

Chapter 2 introduced Agent Skills as portable markdown knowledge packages according to an open specification , Chapter 3 showed that existing horizontal directories such as skills.sh and SkillsMP operate without verification barriers , and that established registries such as the TER have built up their trust function over years , . This chapter systematically derives from this what requirements a curated, vertical directory for the TYPO3 ecosystem must fulfil. Methodologically, the analysis follows the design science approach: first, the stakeholder groups are characterised with their tasks and objections (4.1–4.3), then use cases are played out along an adoption funnel (4.4), and finally, the requirements catalogue A1–A12 is consolidated (4.5).

4.1 Developer Users: Tasks, Objections, Trust Requirements  

The primary target group of the directory is developers working on TYPO3 projects using AI coding agents such as Claude Code or Cursor. The analysis distinguishes between four developer personas and a secondary editorial persona. For each persona, the Job-to-be-done — the specific task for which the directory is consulted — is contrasted with the key objections.

Table 4.1: User-side personas with jobs-to-be-done and objections

Three patterns of objection run through all personas. Firstly, the security issue: the finding that around 13% of publicly listed skills have critical security vulnerabilities is not an abstract risk for tech leads, but a tangible barrier to procurement — a skill is an instruction file that controls the behaviour of an agent with access to client code. Secondly, the confidentiality issue: agencies work under non-disclosure agreements (NDAs) and must be able to prove that an installed skill does not create any additional data leakage. The design's answer is that skills are local Markdown files read by the agent already in use; the directory does not add any data path of its own, and skills with executable scripts receive a visible label and are vetted line-by-line. Thirdly, the issue of up-to-dateness: TYPO3 knowledge ages alongside the LTS cycles , ; a compatibility statement without a date and version reference is worthless for project decisions. These patterns directly lead to the requirements for security review (A4), provenance (A3), compatibility matrix (A2), obsolescence transparency (A11), and privacy-compliant telemetry (A9) — the latter being a standalone argument in the DACH region, the core territory of the TYPO3 ecosystem, rather than just a tick-box exercise.

4.2 Contributing Authors and Agencies  

The second stakeholder group consists of those who submit skills: individual authors, TYPO3 agencies, and existing skill maintainers such as Netresearch, whose marketplace already serves as a precedent . Since skill authors are almost exclusively developers, they expect a submission path via pull requests rather than web forms: diff-based reviews, public discussion threads, and CI checks are familiar to them and generate provenance as a by-product. Anthropic's own curated example catalogue operates on this same pattern of manual review , whereas skills.sh dispenses with any security checks — this very gap represents the market opportunity for the present draft.

Contributors voice three expectations. Firstly, predictability: published acceptance criteria and binding processing deadlines (review SLAs, i.e. promised response times) are themselves an incentive to contribute because they make submissions predictable (A7). Secondly, recognition: attribution must be maintained throughout the entire lifecycle, even when orphaned skills are taken over; author profiles and installation statistics make contributions visible (A3). Thirdly, namespaces: agencies want to publish under a verified name (such as netresearch/typo3-solr-tuning), whereas generic slugs like typo3-seo are assigned to the first accepted, working submission — earned rather than reserved. This avoids the squatting of extension keys known from the TER, whilst at the same time carrying over its proven rule that transfers of ownership require the consent of the previous owners (A8); Chapter 6 regulates the details. Namespaces that suggest endorsement by TYPO3 GmbH or the TYPO3 Association remain reserved, as the project's trademark policy prohibits the use of "TYPO3" in product and domain names without permission , ; trademark protection is covered in Chapter 7.

4.3 Operator Perspective: Curation Effort and Review Scaling  

Curation is by definition human work, and human work does not scale infinitely. The effort estimation from the operator analysis allocates 60–90 minutes for a complete review of a new submission — dominated by the functional test against a real TYPO3 v14.3 project. As submission volumes grow, the weekly effort increases from a few hours to a level that requires additional category maintainers, an expedited track for trusted authors, and ultimately paid editorial capacity; the detailed dimensioning according to operational stages is provided in Chapter 6.3 (Table 6.2).

For the requirements catalogue, this has two implications. Firstly, the security check must be two-tiered: Automated checks — secret scanners, allowlists for outbound URLs, deny patterns against destructive commands, and prompt injection strings, i.e. manipulation instructions hidden in prose aimed at the agent — filter what is machine-detectable before human reviews assess the content of prose and scripts (A4). A directory that reviews every line solely manually does not scale; one that only checks automatically fails to meet the standard of curation. Secondly, operations must be sustainable in the long term without putting the public core catalogue behind a paywall — the TYPO3 community values open infrastructure, and funding models such as the TYPO3 Association's Community Budget require the core service to be non-profit , (A12); Chapter 8 develops the operating model. The security process itself is also an operator requirement: Following the model of the TYPO3 Security Team , the directory requires a reporting channel, coordinated advisories, and an active recall mechanism (A6), which Chapter 6 elaborates as a yank process.

4.4 Usage Scenarios Along the Funnel  

Stakeholder needs can be condensed into a six-stage usage funnel that links each phase of adoption with a system function.

Discover. Users find the directory via search engine pages for each skill, through listings in horizontal directories and via TYPO3-proprietary channels (Slack, Camps, typo3.org). The prerequisite is that skills are available in a portable standard format, ensuring they remain compatible everywhere (A1) , .

Evaluate. The skill detail page is the central hub for building trust: curation badge with date and named reviewer, TYPO3 compatibility matrix (A2), provenance and licence (A3) as well as the freshness status, which indicates how up-to-date the compatibility verification is across LTS cycles (A11) . Crucially, the badge must document the review process, not guarantee error-free results — a legally significant distinction in light of the new EU product liability rules for software , which Chapter 7 explores in greater depth (A10). The design deliberately dispenses with star ratings: with niche reach, they are statistically meaningless and open to manipulation; linked issues are the more reliable signal.

Install. Analysis of the client landscape reveals five different installation semantics — ranging from skill folders in Claude Code to plugin marketplace manifests and clients that only read reference files. This heterogeneity must be hidden behind a single canonical command, as enabled across different agents by the skills CLI (A5); around 30 agents support the underlying specification .

Activate. Initial success must be achievable within ten minutes — for example: checking a TYPO3 extension for v14 compliance in read-only mode. Forgoing write operations during initial contact defuses the objection "Will the AI destroy the project?" constructively rather than rhetorically.

Retain. A monthly digest communicates compatibility changes alongside TYPO3 releases ; update mechanisms check a signed revocation list during each synchronisation and warn about withdrawn versions (A6) — a mechanism that horizontal directories do not yet offer .

Contribute. Every skill page leads into a contribution ladder, ranging from bug reports and pull requests to co-maintainership; transparent criteria (A7) and earned namespaces (A8) make progression predictable.

4.5 The Canonical Requirements Catalogue A1–A12  

The findings from 4.1 to 4.4 condense into twelve requirements. They form the evaluation benchmark for the system design (Chapter 5), the governance model (Chapter 6), the legal framework (Chapter 7), and the operating model (Chapter 8), and are drawn upon in Chapter 10 to evaluate the overall design.

Table 4.2: Canonical requirements catalogue A1–A12 with stakeholder evidence and sources

The catalogue is deliberately designed for trust: not a single requirement aims at catalogue breadth or growth. This structurally distinguishes the designed directory from horizontal directories, whose competitive logic is based on volume , , and positions it in the tradition of the registries analysed in Chapter 3, which derive their raison d'être from verified quality.

4.6 Interim Conclusion  

The requirements analysis reveals a consistent picture: all three stakeholder groups primarily articulate trust-related needs — security and confidentiality on the user side, predictability and recognition on the contributor side, and scalability of the verification work on the operator side. The usage funnel translates these needs into concrete functions and reveals that the critical gaps of existing directories lie in the evaluation, recall, and ageing phases, not in the discovery phase. The resulting catalogue A1–A12 forms the linchpin of this work: Chapter 5 designs the architecture against these requirements, Chapters 6 to 8 operationalise governance, law, and operations, and Chapter 10 measures the overall design against them. For the design, the guiding decision resulting from this is to consistently prioritise depth of curation over catalogue breadth.

5 System Design: Architecture of the Curated Directory 

This chapter translates the requirements gathered in Chapter 4 and the precedent lessons distilled in Chapter 3 into a technical design artefact. The guiding principle is deliberate simplicity: every component that maintains state or manages permissions increases the attack surface, operating costs, and governance effort. The architecture therefore starts as statically as possible and only grows where requirements compel it.

5.1 'Git-first' Design Principle: Monorepo, Static Index, Phased Rollout  

The source of truth is a Git monorepo in which all skills are stored as directories containing SKILL.md and optional additional folders — the initial catalogue comprises 137 curated skills, 31 of which are TYPO3-specific . External authors contribute either directly via pull request (curated path) or via a reference to their own repository, which is periodically imported by a synchronisation job (federated path).

From this repository, the CI generates a static index with every change: a consolidated index.json file (under 500 KB for the initial catalogue), an individual JSON file for each skill, tarball artefacts per release, and an Atom feed for change notifications. This index acts as the directory's public contract. The read API of the first development phase consists simply of these files — such as GET /api/v1/index.json and GET /api/v1/skills/<vendor>/<name>.json —, open via CORS, highly cacheable using content-addressed URLs, and documented by an OpenAPI specification so that third-party clients and the subsequent MCP server consume them in the same way.

This phased approach is deliberate. Firstly, static files maintain no server-side state, are trivial to mirror, and minimise the attack surface. Secondly, every index state is reproducible from a Git commit; provenance and attribution thus remain fully traceable (A3). Thirdly, operating costs remain so low that continuous operation without a paywall becomes realistic (detailed in Chapter 8). A database with a slim write API will only be added if authenticated self-service publishing, significantly more than around 500 skills, ratings, or user-specific tokens are required — and even then, the API will write to the index, which remains the public read path. This corresponds to lesson L1 from Chapter 3: the TER lost its distribution role to Composer and Packagist but persisted as a trust and discovery layer ; those who decouple discovery and distribution can delegate distribution to existing Git infrastructure.

5.2 Metadata Standard: Specification-Compliant Namespaced Frontmatter  

Skills remain fully compliant with the open Agent Skills Specification, which mandates name and description as well as optional license, compatibility, allowed-tools, and a free-form metadata mapping of strings . All registry-specific details migrate into namespaced keys within metadata. This ensures that the skills remain readable for the roughly 30 agents that support the specification — structurally securing requirement A1 rather than merely promising it.

---
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
---

The fields carry the registry's trust assertions: version follows Semantic Versioning; typo3/core specifies the supported major TYPO3 versions as an LTS matrix; registry/maturity adopts the maturity scale familiar from the TER (experimental, beta, stable, deprecated); registry/tested provides a dated record of the TYPO3 version against which the skill was last successfully tested. Consequently, compatibility assertions are versioned and dated (A2) while simultaneously forming the calculation basis for the freshness status across LTS cycles (A11, detailed in Chapter 6). registry/author links to an attribution block identifying the origin and adaptations of each skill (A3). Additionally, the standard requires a CHANGELOG.md, a licence reference, and optionally an evals/ folder containing one to three sample tasks for each skill. The entire schema is published as a JSON Schema named typo3-skills-metadata v1 and enforced in the CI — making the standard itself a verifiable artifact.

5.3 Quality Gates in the CI  

The Snyk analysis ToxicSkills found critical security issues in around 13% of publicly listed skills . Skills present a broader attack surface than classic packages: even the prose of a SKILL.md can control an AI coding agent via prompt injection, completely without executable scripts. The design therefore implements lesson L4 from Chapter 3 — prose and scripts are checked equally (A4) — and staggers the checks based on cost and latency.

Table 5.1: Three-tier quality gates of the CI pipeline with schedule and scope of checks.

The second level does not have to be built from scratch: with SkillSpector, NVIDIA has released an open-source security scanner specifically for agent skills (Apache-2.0), covering 68 detection patterns across 17 categories — including prompt injection, data exfiltration, privilege escalation, and supply chain risks. It works in two stages: a fast static analysis via regex, abstract syntax tree, and taint tracking, followed by an optional LLM-supported semantic evaluation . The scanner accepts Git repositories, URLs, ZIP archives, or individual SKILL.md files and delivers reports in terminal, JSON, Markdown, and SARIF formats with a risk score from 0 to 100 — a format that can be directly integrated into pull request gates. The design can adopt such a tool as the first stage of the security lint instead of maintaining the heuristics entirely in-house; the TYPO3-specific check (eval harness against v14.3) remains the task of the third level.

The third level is the functional unique selling point compared to horizontal directories like skills.sh or SkillsMP, which only index skills but cannot test them against a real target platform , . The ongoing operation of the eval harness is realistically calculated with a budget of around 50 to 150 euros per month. The automated gates do not replace human curation: initial admissions of external skills and changes to scripts also undergo a review by maintainers, whose criteria and deadlines are formalised as governance rules in Chapter 6 (A7).

5.4 Distribution Channels: Five Channels, One Index  

Single-command installation across popular AI coding agents (A5) does not require five separate systems, but rather five thin adapters built on top of the same index:

1. Proprietary Installer: install.sh/update.sh already serve multiple clients (Claude Code, Cursor, Gemini CLI, Codex, Windsurf) and will be refactored to read the published index instead of the local repository.
2. npx skills add: Vercel's CLI installs directly from public GitHub repositories ; the monorepo layout remains compatible, making the skills additionally visible in the horizontal directory skills.sh .
3. Claude Code Plugin Marketplace: A marketplace.json in the repository makes the catalogue subscribable via a single-liner ; the Netresearch Marketplace demonstrates the practical feasibility of this approach in the TYPO3 ecosystem .
4. Composer Plugin: composer require --dev installs selected skills into the skills directory of a TYPO3 project, configured via composer.json — meeting TYPO3 developers right where they are in their familiar environment.
5. MCP Server: A lightweight server exposes search, retrieval, and installation via the Model Context Protocol and is published with a verified reverse DNS namespace in the official MCP Registry .

Updates are processed via Semver comparison and content hash: the installer displays a change summary before every update. Silent auto-updates are strictly ruled out: skills present a potential attack surface for prompt injection, meaning changes must remain visible.

These five channels deliver skills to AI coding agents. For the TYPO3 ecosystem, SkillFlow also offers a consumption route that delivers skills directly to the TYPO3 backend rather than an external agent : the extension manages Anthropic-like skills as backend records, importing them from folders or repositories (GitHub, GitLab, Gitea, ZIP) — meaning a published directory would be directly usable as an import source — and executes them against pages in the current workspace, for example for SEO, tone-of-voice, or QA checks. Workspace stages can optionally trigger an assigned skill automatically. From a security perspective, SkillFlow aligns seamlessly with the design: execution is restricted to the local DDEV development context, credentials originate exclusively from environment variables rather than the database, and imported skills can optionally be validated using SkillSpector — meaning the automated validation at the point of consumption outlined in Section 5.3 comes into play once again. SkillFlow thus illustrates that the trust guarantees of the directory (A2 to A4) do not end at installation, but can extend all the way into editorial use within the CMS.

5.5 Supply Chain Security: Checksums, Attestations, Yanking, Name Protection  

Lesson L3 from Chapter 3 states: The compromise of a trusted publisher account beats any code review — the Nx Console incident even affected a verified publisher . The design addresses this in four ways. Firstly, the index publishes a SHA-256 checksum for each skill version, which all installers verify before unpacking. Secondly, the CI generates provenance attestations based on the SLSA model for release tags, cryptographically proving which commit and build process an artefact originated from; optional Sigstore signatures are added to this (A3).

Thirdly, the recall mechanism (A6): Yanking a version does not just remove it from the index, but enters it into a signed yank feed. Installing clients periodically match local content hashes against this feed and actively warn users — mere deletion does not reach already installed copies. The signature of the feed prevents a manipulated mirror from suppressing recalls. Fourthly, name protection: slugs are vendor-prefixed, typo3-* names are reserved for verified maintainers, and a Levenshtein check in the CI blocks typosquatting — analogous to the verified namespace model of the MCP Registry . Chapter 6 formulates the corresponding allocation rules (A8).

5.6 Operation: EU Hosting and Telemetry without Personal Data  

Because the site and index are pure files, keeping the operation compliant with data protection regulations is straightforward (A9). Hosting takes place within the EU — an origin server in Germany behind a European CDN. Web analytics are self-hosted, without cookies and without consent banners. Installation counting is done via an anonymous counting endpoint per skill: no IP storage, no user identification, and solely aggregated figures that flow back into the index. This produces download numbers as a relevance signal, similar to those established by the TER, without any personal tracking. The legal classification of these operational decisions is explored in greater depth in Chapter 7.

5.7 Mapping Design Decisions to Requirements and Precedent Lessons  

Table 5.2 summarises which design decision addresses which requirement from Chapter 4 and which lesson from Chapter 3 it is based on.

Table 5.2: Mapping of design decisions to requirements A1 to A6, A8 and A9, as well as lessons L1, L3 and L4.

5.8 Interim Conclusion  

The architecture is designed as a deliberately lean trust infrastructure: a Git monorepo provides traceability, a static index delivers a stable public contract, and together they keep operating costs and the attack surface small. The metadata standard operationalises the core trust assertions — version, TYPO3 compatibility, maturity level, audit date — within the open specification and without loss of portability. Quality gates, provenance attestations, and the signed yank feed translate the lessons learned from the analysed precedents into verifiable mechanics. At the same time, the design shows its limitations: schema checks and sandboxes cannot replace human judgement regarding initial admissions, naming, and recalls. The governance model in Chapter 6 defines which roles, criteria, and deadlines guide these judgements.

6 Governance Model: Curation, Namespaces, and Security Processes 

Chapter 5 designed the technical artefact; this chapter designs the organisational one. Governance decides whether the trust requirements identified in Chapter 4 are met in the long term — not the architecture alone. This is guided by two lessons from Chapter 3: L2 (thoroughly vet maintainers once, then certify skills cost-effectively, following the model of the Drupal security opt-in ) and L5 (codify governance rules in writing before growth forces them — the lesson learned from naming and takeover conflicts in other registries).

6.1 Submission Funnel: PR-Based with a Four-Stage Review Pipeline  

For the initial phase, submissions will be accepted exclusively as pull requests (proposed changes in the Git workflow) against the existing repository , rather than via a web form. The reasoning is pragmatic: the verification tools already exist in the repository (skill audit scripts, attribution guardrails, specification validation according to ), pull requests provide a diff view, provenance, and discussion threads at no extra cost, and skill authors are developers anyway. This approach mirrors Anthropic's curated example catalogue of around 20 manually reviewed skills — and differs deliberately from skills.sh, which publishes without security reviews . A web form as a thin wrapper that generates a pull request via the GitHub API is only planned for a later phase (cf. Chapter 9).

Each submission goes through four stages:

Table 6.1: Four-stage review pipeline of the submission funnel

The deny patterns of Stage 2 address the threat landscape documented in Chapter 3: Snyk found critical security issues in around 13% of publicly listed skills, including prompt injection in the prose itself . The pipeline therefore explicitly checks prose and scripts (A4) — automated in Stage 2, line-by-line by humans in Stage 3.

The acceptance rubric is published in full (A7) and assessed on a pass/fail basis per line: valid frontmatter with version and compatibility details (A1, A2), proven functionality through a test transcript and at least one reproduced happy path, no data exfiltration and no destructive defaults, declared and compatible licence with intact upstream attribution (A3), no violation of the TYPO3 trademark policy , (explored in depth in Chapter 7), target-group-appropriate description, and non-overlap with existing skills. Duplicates are rejected with reference to the existing skill. Published criteria and published processing deadlines are not only a matter of accountability, but an incentive in themselves: predictability lowers the barrier to submission.

6.2 Namespace Governance: Earned Slugs Instead of Squatting  

The namespace rules implement A8 and follow L5: they are set down in writing before the first conflict occurs. Three principles support this model.

Firstly: Earned flat slugs. A catalogue name like typo3-seo is assigned to the first accepted submission that passes review — not to the first registration. Name reservations without a functioning skill are excluded. This avoids the pattern known from the TER where extension keys are hoarded without any code ever being published.

Secondly: Verified vendor namespaces. Agencies and manufacturers receive prefixes such as netresearch/… or webconsulting/…, verified via domain email and commercial register extract, linked to a profile page. Netresearch is an obvious launch partner, as its curated marketplace with around 40 skills is the source of many already adapted skills and attribution in the catalogue is already maintained . The semantics are crucial here: verification proves identity, not code security — the case of the trojanised Nx Console extension with a Verified Publisher badge shows that this distinction must be explicitly communicated (cf. A10 and Chapter 7).

Thirdly: Reserved names. Patterns such as typo3-core-*, official-* and anything suggesting endorsement by the TYPO3 GmbH or the TYPO3 Association remain blocked and are reserved for a potential future partnership with the Association (cf. Chapter 9). Ownership transfers of a slug require the consent of the current owners — analogous to the TER extension key rule — with the exception for verifiably orphaned skills described in Section 6.4.

6.3 Maintainer Model in Three Maturity Levels  

Curation is human effort; its organisation must grow alongside submission volume. The design proposes three maturity levels:

1. Solo Curation (launch to approx. month 6): A single curator reviews all submissions and publishes decisions openly in the PR thread to document precedents.
2. Category Maintainers (from month 6): For each topic cluster — TYPO3 (with two people, given the 31 TYPO3-specific skills ), Marketing, Code Quality, Frontend — maintainers receive merge rights exclusively within their cluster. Recruitment is drawn from recurring contributors.
3. Trusted Author Fast-Lane (from month 9): Anyone with three accepted skills and six months of faultless contribution receives auto-merge for updates when the CI is green, supplemented by random post-publish audits (10% sample). New skills still go through Stage 3, but with a deadline of three working days.

The fast-lane operationalises L2: the complex review is applied to the person and carried out once; thereafter, individual artefacts are approved cost-effectively — secured by spot checks instead of full audits . The effort calculation estimates 60–90 minutes for the complete review of a new skill, 15–20 minutes for updates by known authors, and a second review round (+30 minutes) for around 30% of submissions:

Table 6.2: Effort dimensioning of reviews by submission volume

The table highlights the capacity limit: up to around 20 submissions per month, a volunteer-based model is sustainable; beyond that, paid capacity or funding, for example via the TYPO3 Community Budget , is required. The economic context is discussed in Chapter 8 (A12).

6.4 Lifecycle: Versioning, Deprecation, Orphanhood and Adoption  

Each skill follows Semantic Versioning (semantic versioning with major, minor and patch levels) in the frontmatter, supplemented by a changelog entry. The directory maintains a version history and a compatibility matrix across TYPO3 LTS versions and AI coding agents (A2, A11).

Deprecation: A skill is assigned the status deprecated with a superseded-by reference to its successor; after a six-month phasing-out period, it is removed from the standard catalogue. Installers issue a warning during this period.

Orphanhood and adoption follow the TER model, supplemented by an explicit fallback rule for actual absence: if maintainers do not respond within 90 days via two channels, the skill is marked as orphaned; this is followed by a public call for adoption lasting 30 days; after that, curation transfers the skill to adopters on a fork-based basis, with the original attribution retained in accordance with CC-BY-SA (A3). The original authors can reclaim the skill within twelve months, provided they are active again. This preserves the consensus principle of TER key transfer without orphaned skills making the directory obsolete.

6.5 Security Process: Intake, Advisories and Yank Mechanism  

The incident process is modelled on the documented procedure of the TYPO3 Security Team : reports are sent to a dedicated security address with an acknowledgement of receipt within 48 hours, followed by triage, confidential contact with the authors, and a coordinated release of the fix and advisory. If a fix is not forthcoming within a reasonable timeframe, the affected versions are removed and a bulletin with an uninstallation recommendation is published — exactly the process established in the TER. Advisories are numbered from the outset (schema WCS-SA-2026-001) and provided as JSON and RSS feeds.

Furthermore, skills require two additions. Firstly, the yank mechanism (A6): a recalled version disappears immediately from the index; in addition, installation and update scripts check a signed yanked.json feed during every synchronisation, warning against locally installed copies or removing them. This ensures that the recall also reaches already installed clients — a structural advantage over skills.sh, which has no such mechanism . Secondly, the differentiation between malicious and faulty: a faulty skill goes through the coordinated fix process; a malicious skill leads to the immediate yanking of all versions, the suspension of the authors, and an advisory with indicators of compromise — including details of what data might have been exfiltrated and which prompts affected users should search their transcripts for. This transcript dimension is skill-specific: since prose can manipulate the agent even without scripts , an advisory must include the instruction level (A4). The maintainer vetting from Section 6.3 complements this process preventively, following Drupal’s philosophy: a one-off identity check before granting extended rights reduces the risk of the fast lane itself becoming an attack vector .

6.6 Incentive System and Code of Conduct  

A directory without submissions is worthless; governance must therefore also motivate. The draft outlines an incentive ladder: Verified Author badge → installation and download statistics on the profile page → monthly contributor spotlight in the blog and newsletter → visibility at community events such as the TYPO3 Developer Days → and, in the longer term, revenue sharing for paid add-on skills, which remains deferred pending clarification of the legal and tax implications (cf. Chapters 7 and 8). The public core catalogue remains unaffected and freely accessible (A12).

The Contributor Covenant 2.1 is adopted as the code of conduct, culturally linked to the TYPO3 community's own Code of Conduct. Disputes — rejections, naming conflicts, adoption disputes — follow a three-stage process: decision by the responsible maintainers, written appeal to the curation team, and a publicly logged final decision. Here too, L5 applies: the process exists before the first conflict occurs.

6.7 Interim Conclusion  

The governance model translates the trust requirements from Chapter 4 into verifiable procedures: The four-stage review pipeline with a published rubric meets A4 and A7, earned namespaces with vendor verification meet A8, and the security process with a signed yank feed meets A6. At the same time, the effort calculation reveals the limits of the model: from around 20 submissions per month, curation requires paid or funded capacity, thereby passing the sustainability question to Chapter 8. The consistent alignment with the TER and the TYPO3 Security Team is not traditionalism but an adoption strategy: the target audience is already familiar with and trusts these procedures. The legal safeguarding of name, trademark, and liability issues remains open — this is the subject of Chapter 7.

7 Legal Framework: Trademark, Licences, Platform Obligations, and Liability 

This chapter analyses the legal framework of the designed directory from the perspective of an operator based in Austria under EU law. In line with the design-science approach, legal obligations are not referenced in isolation but are treated as design constraints: each identified obligation leads to a concrete architectural or governance decision that connects to Chapters 5 and 6. The presentation is deliberately kept accessible for non-lawyers; points requiring legal review are explicitly highlighted.

7.1 Trademark Law: The Wordmark "TYPO3"  

"TYPO3" is a registered trademark of the TYPO3 Association, based in Baar (Switzerland). Their Trademark Usage Policy prohibits all third parties — explicitly including paying members of the highest tiers — from using the wordmark in company names, product names, domain names, and social media handles; the policy cites a domain like "typo3hosting.com" as an example , . Only descriptive (nominative) use remains free: the statement "Agent Skills for TYPO3" is permissible, whereas a product name such as "TYPO3 Skills Directory" or a domain containing the element "typo3" is not allowed without written permission .

For the design, this results in a clear naming strategy: the directory is given an invented, neutral proper name and communicates its affiliation with the ecosystem exclusively in the descriptive subtitle ("the Agent Skills Directory for TYPO3"). Until written permission is obtained, the wordmark remains excluded from the logo, domain, app name, and the name of the GitHub organisation.

At the same time, a structured approval process exists: the policy provides a registration form for trademark use, and the published criteria — benefit to the community, open-source-compatible licensing, substantial involvement of contributors, no implied official status — largely align with the directory's objectives , . Strategically more attractive than a mere permission to use is the option developed in Chapter 9 to position the directory in the medium term as an official initiative of the TYPO3 Association, for example via a submission to the community budget process ; this would transform the trademark issue into a signal of trust. It should also be noted that paid advertising using the trademark requires a Gold or Platinum membership , . Legal counsel should assist with negotiating trademark approval.

7.2 Licence Architecture: SPDX, Redistribution and Contribution Terms  

The initial catalogue of 137 skills is heterogeneous in terms of licensing: platform code is licensed under the MIT License, skill prose by default under CC-BY-SA-4.0, and adopted third-party assets under Apache-2.0, MIT, ISC or — in isolated cases — under proprietary terms that do not permit free redistribution . The design addresses this with three rules.

Firstly, every skill declares its licence in a machine-readable format as an SPDX field in the frontmatter; the directory displays this information and makes it filterable. Secondly, a strict redistribution rule applies: the directory may only host or mirror content itself if the licence explicitly permits redistribution. For all other skills — such as those with "source-available" terms — a pure metadata listing is created, which links to the source repository. Thirdly, attribution is a mandatory field: the origin and authorship of each skill remain traceable, which simultaneously satisfies requirement A3. A CI check enforces these rules automatically — licence field present, attribution block intact, no CC-BY-SA prose copied into MIT-licensed code; this is part of the publication pipeline described in Chapter 6.

A particular boundary is drawn by the copyleft of the CC-BY-SA licence: anyone who modifies a CC-BY-SA skill must distribute the modified version under the same licence; relicensing third-party contributions is excluded. Skills under Apache-2.0 can coexist alongside them as independent works, but prose must not be merged across licence boundaries.

For inbound contributions, the design relies on the Developer Certificate of Origin (DCO) — i.e. a confirmation of origin via a sign-off per commit, combined with an "inbound = outbound" clause: contributions are licensed under the same licence as the file they modify. A Contributor License Agreement (CLA) is deliberately avoided, as it creates barriers to contribution in open-source-dominated ecosystems such as the TYPO3 environment; even the historical TER manages without a CLA. A submission checklist (authorisation to submit, attributed and licence-compatible third-party material, no confidential client code) complements the process. It remains to be legally reviewed whether the special licences of individual third-party skills permit mirroring at all.

7.3 Platform Obligations under the Digital Services Act  

As soon as the directory stores and publicly provides user-submitted skills, it constitutes a hosting service and is likely to be classified as an "online platform" within the meaning of the Digital Services Act (DSA) . As a micro-enterprise — fewer than ten employees, and an annual turnover under two million euros — the operator is exempt from special platform obligations: transparency reporting, an internal complaint-handling system, and the integration of trusted flaggers are not required .

However, the basic obligations for hosting services remain in place: the liability privilege for third-party content until actual knowledge is obtained (Art. 6), a notice-and-action mechanism for illegal content (Art. 16), an obligation to provide a statement of reasons to affected users when removing content (Art. 17), designated points of contact (Art. 11–13), and transparency regarding moderation rules in the terms of service (Art. 14) . These obligations can be implemented with minimal effort: a "Report Skill" form on each detail page, a documented take-down process, and a public moderation policy. The design deliberately links the take-down process to the recall mechanism from Chapter 6 (A6): the same pipeline that revokes a skill version for security reasons also handles DSA reports.

Deliberate risk minimisation is achieved through a staged roll-out: as long as Version 1 of the directory only stores metadata while the actual content remains on GitHub, the core hosting obligations fall on the respective provider there — an argument in favour of the "metadata-first" architecture established in Chapter 5. Additionally, it should be noted that a directory of pure prompt texts is neither an AI model nor an AI system; obligations under AI regulations for providers or operators only arise if the platform itself were to execute skills. The design dispenses with hosted execution and documents this limitation in the terms of service.

7.4 Liability: Product Liability, Reliance Liability and Badge Semantics  

Directive (EU) 2024/2853 explicitly extends product liability to software; member states must transpose it by 9 December 2026 . Free and open-source software is only exempt if it is provided outside of a commercial activity. This exemption is fragile: monetisation, an exchange of "data for access" or bundling with an agency's commercial offering can revive strict and mandatory liability . While it covers personal injury, consumer property damage and data loss, it does not cover pure economic loss between businesses — however, the very question of embedding makes it a structural issue for the operating model in Chapter 8. An implementation memo before the deadline and an assessment of separating the directory from the agency business (such as an association or a separate company) should be commissioned from legal counsel.

The second, practically more relevant liability risk is of a non-contractual nature. Users install skills via channels such as CLI installers, git clone, Composer or MCP connections — and never see the terms of use. Where no contract is concluded, "AS IS" clauses and liability caps bind no one. Liability is then governed by general civil law: although Section 1300 of the Austrian General Civil Code (ABGB) privileges advice provided free of charge (liability only for knowingly false advice), Austrian case law dictates that this privilege does not apply if the advice is given with self-interest — such as building the reputation of a commercial provider — within a special relationship; in this case, full liability for negligence applies under the expert standard of Section 1299 ABGB. It is precisely such circumstances of reliance that curation badges create when they guarantee results: a "security-reviewed, tested on v14.3" badge is a reliability-inducing quality claim that a simple GitHub repository does not make.

This leads to the central design consequence of this chapter, defined as requirement A10: badges formulate process-based rather than outcome-based statements, and are dated and version-bound. Instead of "security-reviewed", it reads "Process review completed (2026-06)"; instead of "tested", "Eval suite passed on v14.3 sandbox". Each badge links to the published audit criteria (A7) and explicitly explains what it does not warrant; named reviewer badges are omitted to avoid personal liability risks for the auditors. The marketing value of curation is preserved, while the warranting nature is defused. The dating also links with the freshness status from requirement A11: an ageing review becomes visible instead of tacitly continuing to apply.

Outside of a contract, disclaimers cannot limit liability, but they can refute the reliance claim and lower the standard of care. The design therefore places them redundantly across all five channels: in the frontmatter and the first line of every SKILL.md, in the licence and README notice, in the installation output of the installers, in the MCP tool descriptions, and on the badge detail pages — in both German and English, with the core message: human review required before production use, dated process review for a specific TYPO3 version. For channels with an account or submission function, the design also provides a genuine consent gate to the terms of use. The drafting of channel-dependent disclaimers and liability clauses (limits of Section 6 of the Austrian Consumer Protection Act (KSchG) towards consumers, broader design leeway in B2B relations) requires legal advice; a one-off budget of approximately 4,000 to 8,000 euros should be estimated for this. In addition, IT professional indemnity insurance with financial loss cover must be obtained; since insurers are increasingly introducing AI exclusions, the documented human review process should be used as a negotiating point for a carve-back — the economic context is provided in Chapter 8.

7.5 Data Protection: Non-Personal Telemetry  

Requirement A9 demands privacy-compliant telemetry: the directory collects usage figures exclusively in an aggregated and non-personally identifiable form, hosted on EU infrastructure. Specifically, this means using European-operated web analysis without personal profiles instead of US-centric tracking services, truncating IP addresses for download statistics, as well as concluding Data Processing Agreements (DPAs) pursuant to Art. 28 GDPR with the host, mail service, and CDN. For a newsletter, the double opt-in requirement of § 174 TKG 2021 applies. Since no non-essential trackers are used, a consent banner is not required; a privacy policy remains mandatory. Additionally, Austrian information duties must be fulfilled: a legal notice (Impressum) under § 5 ECG and a disclosure (Offenlegung) under § 25 MedienG, the latter in its full scope including the editorial policy (Blattlinie) for editorial content (such as a blog). These components can be implemented using audited templates and do not require individual legal counsel.

7.6 Synthesis: From Legal Obligations to Design Decisions  

The following overview condenses the analysis. It demonstrates that none of the identified obligations block the design; each can be translated into an already planned architectural or governance decision.

Table 7.1: Legal areas, obligations, and risks, as well as the resulting design consequences for the directory

In summary, four points require legal review: the trademark negotiations with the TYPO3 Association, the redistribution rights of individual special licences, the terms of use including liability clauses and channel-dependent disclaimers, and the product liability memo, including the question of separating entities.

7.7 Interim Conclusion  

The legal framework proves to be manageable, rather than an obstacle. Trademark law enforces a neutral naming strategy with a descriptive TYPO3 reference while simultaneously opening up a path for approval and partnership , . Licence heterogeneity becomes manageable through SPDX declaration, redistribution rules, and metadata fallback; for a micro-enterprise, the DSA is achievable with a reporting form and documented takedown procedure . The most important insight concerns liability: because installation channels bypass the conclusion of a contract, protection of legitimate expectation must be built into the artefact itself — as dated process badges (A10) and cross-channel disclaimers, supplemented by product liability precautions before 9 December 2026 . This establishes the legal boundary conditions under which Chapter 8 develops the economic viability of the operator model.

8 Operator Model and Economic Viability 

8.1 Honest Market Assessment: TYPO3 as a Niche  

Every viability calculation must begin with the actual scale of the ecosystem, not with hopes of growth. TYPO3 holds a CMS market share of around 0.5 to 1.1 per cent, with approximately 38,000 recorded active domains and over 500,000 reported installations. Usage is heavily concentrated regionally: around 71 per cent of installations are in Germany, and over 85 per cent in the DACH region. The TYPO3 Association has over 1,000 members ; the commercial environment consists of an estimated 300 to 900 agencies and freelancers, of which realistically only 150 to 300 are large enough to even be considered as paying customers. These scales limit any revenue model.

At the same time, the horizontal skills market is already occupied. skills.sh, the directory launched by Vercel in January 2026, aggregates over 90,000 skills for 19 agents and dominates the cross-topic search segment ; SkillsMP, as a GitHub scraper, pursues a similarly broad approach . A vertical directory cannot compete on volume in this environment, but solely through vertical trust and curation. The Snyk analysis, which found critical security issues in around 13 per cent of publicly listed skills , provides the justification: The statement "every listed skill has been verified for TYPO3 v14 correctness and security" is the entire value proposition (cf. Chapters 4 and 6).

There are therefore three reasons against a paid skill marketplace. First, the volume is lacking: a two-sided market with a few hundred potential buyers cannot generate the necessary liquidity from supply and demand. Second, the "paid, verified skills" segment is already occupied horizontally by commercial marketplaces with revenue-sharing models. Third, the regulatory burden is disproportionate, as Section 8.2 shows.

8.2 Tiered Revenue Streams  

The draft organises revenue streams by activation thresholds: what generates income immediately is activated right away; everything else waits for measurable adoption. The basis is requirement A12 formulated in Chapter 4: the public core catalogue remains free of charge in perpetuity. Any paywall on the catalogue, search, installation scripts, or security audit reports would destroy the trust advantage — the sole competitive edge over horizontal directories , — of the platform.

Free core catalogue as a strategic competitive advantage. The primary economic function of the directory is not direct revenue, but authority: it is a permanent demonstration of competence in the field of "AI-assisted TYPO3 development". Comparable content-driven TYPO3 agencies convert this authority into project business. A plausible calculation after twelve months: 2,000 to 4,000 monthly visitors, 8 to 12 qualified enquiries per year, of which around a quarter are closed at an average project volume of 15,000 to 40,000 euros — resulting in 40,000 to 80,000 euros of annually attributable consulting revenue. This single item exceeds all subsequent revenue streams combined.

Workshops and enablement (immediately activatable). Team workshops on AI-assisted TYPO3 development can be sold without any adoption threshold, as they leverage the directory's credibility directly. Standard DACH market rates for specialised consulting justify 1,800 to 2,600 euros per workshop day, or 4,500 to 7,500 euros for a two-day enablement package including private skill creation. 8 to 15 workshop days in the first year — initiated through conference presentations, for example at the TYPO3 Developer Days — result in 15,000 to 35,000 euros. A certification programme is premature; a free badge programme will pave the way for it.

Sponsorship (from reach threshold). Sponsorship packages become realistic from around 1,000 monthly active users and about 20 external authors: founding sponsor at 2,500 to 4,000 euros per year, category sponsorship at 1,000 to 1,500 euros, and a small logo for 500 euros. Three to five sponsors in the first year (5,000 to 10,000 euros) and six to ten in the second year (10,000 to 20,000 euros) will cover cash costs, but never personnel costs.

Private registries as a subsequent SaaS option. The most plausible recurring revenue stream is hosted private registries, where agencies publish proprietary skills — client conventions, internal deployment playbooks — using the same installation, versioning, and CI validation infrastructure. The willingness to pay is proven: agencies already pay 50 to 200 euros per month for comparable internal tooling. With price points of 99 euros (Team) and 249 euros (Agency, with SSO and audit log) and an addressable market of 200 to 300 agencies, ten paying clients by the end of the second year are realistic — representing 12,000 to 30,000 euros in annual revenue. This does not sustain a company, but it deepens engagement. Development will only begin after securing at least three design partner pre-commitments.

Paid marketplace: deferred. In addition to the volume issue described in Section 8.1, tax compliance obligations for platforms argue against a marketplace: under VAT law, a platform that sells electronically supplied services, sets terms, and processes payments is irrefutably deemed the provider of the service (deemed supplier) and owes VAT in the member state of each buyer — involving quarterly OSS filings and additional DAC7 reporting requirements regarding authors' earnings (cf. Chapter 7). If ever implemented, this would only be done via a Merchant of Record who assumes these duties for a fee of around five per cent. Decision threshold: at the earliest once there are more than 10,000 installations per month and documented demand from authors.

Table 8.1: Tiered revenue streams with activation thresholds and scales

8.3 Cost Side and Break-Even Logic  

The cost structure is intentionally lean: the static site, search, and CI pipeline incur low infrastructure costs; the dominant item is human curation time (cf. Chapter 6), which is incurred as opportunity costs rather than cash outflows.

Table 8.2: Cost estimate for Year 1 and Year 2, separating total and cash costs

The break-even logic operates in two stages. Stage one concerns cash costs: these are already covered in the first year by three to four sponsors plus a grant from the TYPO3 Association's community budget process — which is allocating €160,000 for 2026 in quarterly rounds of around €40,000 each, with typical individual grants ranging from €5,000 to €15,000 . Important: An application must only concern the open infrastructure (validation tooling, security audit pipeline) and never the directory as a business asset, as the funding guidelines exclude direct commercial purposes (see Section 8.4). Stage two concerns the full opportunity costs: these are covered as soon as attributable consulting revenue (€40,000 to €80,000) and workshops (€15,000 to €35,000) are generated — which is realistic between months 12 and 18. The SaaS service only needs to cover its own infrastructure and maintenance, for which around ten customers are sufficient. The budget rule is: annual cash expenditures are capped at approximately €12,000 until sponsorship and workshops cover them.

8.4 The Question of Ownership and Neutrality  

The operating model contains an apparent contradiction: the directory is intended to act as a neutral trust infrastructure for the entire ecosystem (Chapter 3), whilst simultaneously serving as a lead generation asset for a single agency. Two verified findings resolve this conflict.

Firstly, the Association's Community Budget is the wrong instrument for transferring or funding the directory itself: the rules require that funded ideas must neither directly generate revenue for applicants nor open up commercial opportunities . An application for the directory alongside a concurrent business case based on attributable consulting revenue would be disqualifying and, if discovered, damaging to reputation. Secondly, the most successful precedent never relinquished the asset: Packagist.org, the central package index of the PHP ecosystem, still belongs to Packagist Conductors GmbH, which builds the commercial Private Packagist on top of it . The PHP ecosystem accepts a privately operated public index because the governance of the listings is neutral, even if the ownership is not. Analogously, HACS, the community store of Home Assistant, remained in the creator's hands and became a cooperation partner of the Open Home Foundation — endorsement and resources instead of transfer . Complete donation (precedents TER and Drupal.org) is the only model in which the commercial benefit for the initiators is completely eliminated.

Table 8.3: Option matrix on the question of ownership and neutrality

The recommendation of this paper is: start as Option B, actively negotiate towards Option C, with Option D as a fallback — never open with Option A. Private operation with a publicly published, neutral listing and namespace policy (cf. Chapter 6, Requirement A8) adopts the proven Packagist pattern ; the targeted Endorsed Operator status based on the HACS model provides the official environment without transferring ownership. Membership in the TYPO3 Association and a Community Budget application exclusively for separable open infrastructure credibly support this position. The prerequisite for credibility is the separation of entities: the index must belong to a separate company so that "the directory" and "the consulting business" are contractually separable — only this makes Option C acceptable to competing agencies as contributors.

8.5 Red Lines for Negotiations  

Before any contact with the Association — the trademark question opens the negotiation (cf. Chapter 7) — the following boundaries must be established:

• Domain without wordmark. The Trademark Usage Policy prohibits "TYPO3" in domains and product names ; usage permissions are processed via the official procedure . The project's identity must never depend on a name that the Association can revoke.
• Never transferable: the private registry service (SaaS), the workshop and training brand, as well as the proprietary review badge programme. These assets constitute the business model and are not open to negotiation under any circumstances.
• Transferable only as a package deal: Ownership of the index will transfer exclusively in conjunction with (a) a multi-year paid maintainer contract, (b) permanently secured attribution for the contributed skills (Requirement A3), and (c) a copy or joint licence of the telemetry data. Verbal commitments ("we will sort out the contract later") will not be accepted; all terms and conditions must be included in a single signed agreement.
• Telemetry from day one with the operator. Installation and usage data (privacy-compliant and aggregated in accordance with Requirement A9) shall belong to the operating company; this must be stated in the privacy policy from the very beginning.
• Community budget only for separable public deliverables (such as tutorials for authors, specification documentation), never for the directory itself .

If Option C fails, Option D (neutral association) will be offered first before making any concessions to Option A; Option A is only acceptable with a fully finalised package deal.

8.6 Interim Conclusion  

The analysis shows: the directory is a strategic competitive advantage for an agency, not an independent product business. The addressable market is too small and the horizontal competition , too fast for a viable paid marketplace, whose tax-related platform obligations would additionally consume the benefits. Instead, viability is achieved through the permanently free core catalogue (A12), which generates consulting and workshop revenue, while sponsorship and a community budget grant cover the low cash costs; a full break-even is plausible between months 12 and 18. On the question of ownership, the design follows the Packagist precedent : private operation with a neutral listing policy, a negotiated endorsed operator status based on the HACS model , and clearly defined red lines. For the rollout strategy in Chapter 9, this implies that community legitimacy must be built through published neutrality rules and open infrastructure contributions — not by giving away the asset.

9 Rollout Strategy: Community, Communication and Capacity 

9.1 Positioning: Category Leadership as a Curated Vertical  

Horizontal directories already exist: Vercel's skills.sh aggregates skills across various topics , SkillsMP populates its catalogue via GitHub scraping , and Anthropic maintains a curated sample catalogue . Competing on volume against these providers would be futile and strategically flawed. This work therefore positions the directory as a first-in-category: the first curated vertical for a single CMS ecosystem. The differentiator is not quantity, but vertical trust — every skill is validated against TYPO3 v14.3 LTS , , compliance-tested (A2, A4), and provided with clean attribution (A3). The Snyk analysis, which reveals that around 13% of publicly listed skills have critical security issues , provides the central selling point against unverified volume catalogues (cf. Chapter 3). The analogy, which is instantly understandable within the TYPO3 community, is: "TER, but for Agent Skills" .

The window of opportunity for this category pioneering is real but narrow — the analysis estimates six to twelve months before another player claims the category. Consequently, the guiding principle of the launch is: speed over perfection.

The core messages are differentiated by target audience (cf. the stakeholder analysis in Chapter 4):

• Agency Management — Margin and Speed: Junior staff achieve senior-level results in upgrades, Content Blocks, and WCAG audits; fixed-price projects become profitable again. This is proven through measured case studies, such as an extension upgrade from v12 to v14 in four hours instead of three days.
• Developers — Quality: Skills encode the conventions of the TYPO3 core team (Rector, testing, compliance), ensuring the AI coding agent no longer hallucinates outdated APIs.
• Freelancers — Leverage: With 137 curated skills and a single-command installation (A5) across the approximately 30 specification-compliant agents , a single individual can operate with the depth of tools of a small agency.

The naming question follows the trademark framework developed in Chapter 7: launching under a neutral domain, using the descriptive phrase "Agent Skills for TYPO3", and a parallel application for a trademark usage licence from the TYPO3 Association , .

9.2 Event-Driven Rollout  

The rollout would not be geared towards abstract quarters, but rather aligned with actual events on the TYPO3 calendar: developer conferences, T3CON, and regional TYPO3camps offer natural milestones and an already gathered audience. This paper deliberately does not establish a scheduled roadmap: specific dates, a trial phase, or a launch event would only be determined after confirmation of dates, calls for papers, and — crucially — the capacity analysed in Section 9.4. A logical sequence can be defined (closed testing → public presentation → stable version → scaling); its scheduling cannot. This restraint is not an oversight, but follows directly from the capacity findings in the next section.

9.3 Channels and Contributor Acquisition in the TYPO3 Ecosystem  

The communication channels are deliberately restricted to the TYPO3 ecosystem, where the target groups are already organised. Four channels bear the main load: first, a community article on typo3.org and news.typo3.com respectively; second, the TYPO3 Slack with channels for CMS discussion, milestones, and regional groups, prospectively supplemented by a dedicated agent-skills channel; third, talks at TYPO3camps and usergroup meetups as a repeatable 20-minute demo format; fourth, LinkedIn as the primary B2B channel in the DACH region, deliberately run via the founder's personal profile instead of a corporate profile. In addition, community podcast and newsletter formats, as well as short demo videos (prompt → result → installation command), serve to enhance visibility.

Strategically more significant than the channels is the mechanism of contributor acquisition: the Verified Publisher programme turns potential competitors into contributors. Agencies receive a verified profile with a logo, backlink, and their own skill portfolio page — free marketing for the agency, content and legitimacy for the directory. The Netresearch precedent, already the largest external contributor to the launch catalogue , , proves the viability of this model. The associated rule of conduct is simultaneously a governance principle (cf. Chapter 6): attribution is never removed; the CI check that enforces this is proactively communicated as a trust feature (A3).

To support this, the operator is joining the TYPO3 Association — as a signal of credibility and as a prerequisite for the trademark usage application. In the long term, the directory is to be proposed to the Association as a community initiative: the TER analogy makes it compatible with existing community structures , , and its status as ecosystem infrastructure with the founder as maintainer is the most effective protection against a competing fork (cf. Chapter 8 and Chapter 10).

9.4 Capacity Realism: The Capacity Model as an Evaluation Result  

The most methodologically insightful realisation of the rollout planning emerged not during the design, but during its validation: the aggregation of all workstreams across the planned phases revealed that the original programme exceeded the founder's available capacity by approximately 2.7 times. In terms of the design-science paradigm, this is a first-order evaluation result — the first artifact design of the rollout failed the feasibility test and was revised. Table 9.2 documents the capacity model.

Table 9.2: Aggregated capacity model of all rollout workstreams (hours per week)

The model shows two things. Firstly, the peak load is structural: particularly the months surrounding the major community conferences — the most resource-intensive phases of a rollout — require around 2.7 times the available time. Secondly, even in the "quiet" months, the demand exceeds the available capacity by around 60%. The plan in its original form was therefore not just ambitious, but unfeasible — regardless of the discipline or motivation of the founder.

Three consequences follow from this diagnosis. The first is a deputy role: a second person (internal or as a contractor at 10–15 hours/week, budgeted at approximately €1,500–2,500 monthly, cf. the operating model in Chapter 8) who can take over four clearly documented tasks — triage of the security inbox including acknowledgement of receipt, execution of a documented takedown or yank (A6), merging of low-risk skill pull requests based on a written checklist, and publication of the digest from a template.

The second consequence concerns the bus factor. A register of single points of failure identifies five critical dependencies on a single person: the security intake and yank authority (missed response times due to holiday or illness damage public trust), the signature and provenance keys (loss blocks publication, a leak would be a supply chain incident), control over the GitHub organisation, DNS, and registry namespaces (an account suspension would end the project), sole PR approval (the queue remains unprocessed during peak load phases), and the sole public voice. The countermeasures are unspectacular but binding: a shared inbox with a second responder, keys stored in a shared credential vault with offline backup and a rotation runbook, a second organisation owner, merge rights for the deputy, and a "break-glass" runbook with written instructions to freeze the ingestion of new skills if the founder is unavailable for more than 14 days, while maintaining the security response.

The third consequence is prioritisation: whatever does not fit into the capacity is cut, reduced, automated, or postponed — and done so transparently in writing, not silently. Table 9.3 summarises the revised list of commitments.

Table 9.3: Revised list of commitments after the capacity analysis

The revision of the security commitment is particularly noteworthy: instead of publishing an unsustainable response time and breaking it later, the more conservative commitment is published before anyone can rely on a more ambitious one. Transparent, published review commitments (A7) only build trust if they are backed by sufficient capacity — this connection is revisited in the risk analysis in Chapter 10.

9.5 Measurable Adoption Targets  

The rollout is not considered successful simply because it took place, but only when defined adoption metrics are met. Table 9.4 outlines the target values; the data basis is exclusively the privacy-compliant, aggregated telemetry of the directory (A9).

Table 9.4: Adoption targets of the rollout phase

The AI citation rate deserves explanation: in a standardised audit, ten typical questions about TYPO3 and agent skills are posed to popular AI assistants, and it is logged whether the directory is cited as a source. Since horizontal directories like skills.sh flow into the training and search data of language models , the directory continues to publish to them — with canonical backlinks, so that the dominant TYPO3 presence in these high-volume directories strengthens the curated vertical. Following the capacity revision (Section 9.4), this audit runs quarterly and is scripted. Missed target values are not glossed over, but instead trigger the reassessment of the operator model described in Chapter 10; any re-expansion of the reduced obligations will only take place once the capacity deficit has been demonstrably closed.

9.6 Interim Conclusion  

The launch strategy occupies the category of the curated vertical before another actor names it, and would use the natural fixed points of the TYPO3 calendar for this purpose without committing to specific dates (Section 9.2). Channels and contributor acquisition consistently build on existing community structures; the Verified Publisher programme turns potential competitors into contributors. However, the scientifically central finding is the capacity analysis: the original programme exceeded the capacity of the founding person by around 2.7 times and was revised to a sustainable level through documented prioritisation, a deputy role, and bus factor safeguarding. For the design, it follows that trust commitments such as review deadlines (A7) and recall capability (A6) are only as resilient as the capacity behind them — a principle that directly links the evaluation in Chapter 10 and economic viability (A12) in Chapter 8.

10 Evaluation and Risk Analysis: Resilience of the Design 

10.1 Methodology: Adversarial Gap Analysis as an Evaluation Tool  

Design science artefacts that are not yet operated in the field cannot be measured empirically — but they can, however, be systematically attacked. This paper therefore evaluates the design using an adversarial gap analysis (Completeness-Critique): the overall design from Chapters 5 to 9 was systematically examined for internal contradictions, uncovered cost paths, and tacit assumptions, supplemented by a precedent validation against documented success and failure cases of comparable registries (Chapter 3). The benchmark for the critique was the canonical requirements catalogue A1–A12 from Chapter 4: a gap is considered material if it makes a requirement permanently unachievable, or if its fulfilment would only be possible at unstated costs.

The process identified four material gaps. Crucial to the evaluation of the artefact is that all four could be incorporated back into the design: they led to concrete design changes (freshness model, endorsed operator structure, badge reformulation, deputy model) rather than merely footnotes. Sections 10.2 to 10.5 document the respective findings, their incorporation into the design, and the remaining residual risk.

10.2 Risk 1: Scheduled Loss of Trust due to LTS Cycles  

The core promise of the directory — versioned, dated compatibility statements per skill (A2) — carries an expiration date. TYPO3 follows an approximately 18-month LTS rhythm , ; with each major version, verifications established against the predecessor version are devalued. The analysis of historical breaking changes profiles shows that for each major version, content revision is to be expected for around 50–60% of TYPO3-specific skills — not just the updating of version details. A directory launching in autumn 2026 would face the beginning of the next cycle just a few months later.

The cost side is quantifiable. A full human recertification of the initial catalogue of 137 skills was estimated by effort classes:

Table 10.1: Estimated recertification costs per LTS cycle for the initial catalogue (Source: own effort estimation)

Around €31,000 every 18 months is not sustainable for a small operator; without countermeasures, requirement A2 would only be achievable in the first cycle. The feedback into the design takes place in three stages and justifies requirement A11 (ageing transparency): Firstly, every verification remains preserved as a dated, version-related historical fact; a calculated freshness status (current, outdated, obsolete) is maintained in the index, not stored in the badge — demotion with context instead of deletion. Secondly, the catalogue is tiered: a Core Certified tier of around 40 skills receives guaranteed human recertification within 30 days of an LTS release, which limits the guaranteed costs to about €10,000–12,000 per cycle; the rest falls under the published expiration rule. Thirdly, event-driven automated eval sweeps — triggered by the initial release, release candidate, and LTS of a new major version — replace the ongoing full audit; in addition, contributor recertification with visible attribution and funding via the TYPO3 Community Budget for a public revalidation sprint are being considered . Residual risk: The schedule projection for the next major version is unconfirmed, and the yield from community contributions (realistically 20–30% of the catalogue) is not guaranteed.

10.3 Risk 2: Ownership Conflict — Business Value vs. Community Asset  

The second gap is an internal contradiction: the operator model (Chapter 8) justifies the effort based on the value of the directory as a reputation and acquisition channel, while the rollout strategy simultaneously seeks proximity to the TYPO3 Association. Transferring ownership to the Association would eliminate the operator's commercial incentive; funding the directory via the Community Budget is out of the question anyway, as its rules exclude projects with a direct commercial purpose — an application would be disqualifying and damaging to reputation.

The resolution is provided by the precedent analysis in Chapter 3: the most successful community indices were never signed over. Packagist is still operated today by a private company that offers commercial services through it ; HACS remained in community hands within the Home Assistant ecosystem and received recognition and resources through a foundation partnership rather than a transfer of ownership . The draft therefore adopts the Endorsed Operator model developed in Chapter 8: an open index with a neutral, published listing policy owned by a separate operating entity, combined with an intended trademark licence and an advisory board with community seats; a transfer option — rather than an obligation — remains negotiable. A prerequisite is a trademark-free domain, as the Association's trademark policy prohibits the use of "TYPO3" in domains , . Residual risk: the model depends on a negotiation whose outcome is uncertain; if the Association refuses recognition, the index remains legitimate but without official status.

10.4 Risk 3: Liability Outside of Contractual Channels  

The third gap concerns the legal framework (Chapter 7): Anyone who obtains skills via single-command installation, Git clone, or agent mechanisms , does not see any terms of use — no contract is concluded, and limitations of liability bind no one. Exposure then occurs via extra-contractual reliance liability: specifically, the directory's curatorial quality statements ('verified', 'tested') are capable of creating a special relationship that establishes liability, which a mere GitHub repository would not generate. In addition, there is the EU Product Liability Directive, which covers software as a product and whose implementation deadline ends on 9 December 2026 ; the exemption for free software only applies outside of commercial activity — coupling it with the operator's commercial offering can revive non-excludable liability.

This mapping back confirms and tightens requirement A10: Badges formulate process statements rather than outcome statements ('process-verified on date X for version Y' instead of 'secure'), are dated, version-linked, and associated with published criteria; personal reviewer badges are discontinued. Disclaimers are embedded in all five distribution channels — skill file, licence, installer output, agent description, badge detail page — because, while they do not cap liability, they weaken the basis for reliance. A new insurance workstream (IT professional indemnity with financial loss cover) has been added, which was missing from the original draft. Residual risk: The insurance market is currently developing AI exclusion clauses; whether cover for curatorial statements about AI-executed instructions is available at viable premiums remains open at the time of the investigation. The draft does not solve this problem — it identifies it and defines a decision point (separation of entities instead of insurance).

10.5 Risk 4: Capacity and Bus Factor  

The fourth gap is the most obvious and, at the same time, the most existential: the sum of all workstreams — setup, curation, communication, presentations, eval operations, security processes — exceeds the realistic availability of a single founding person several times over in the initial phase; even in quieter months, the demand significantly exceeds the available capacity. At the same time, security-critical functions (security inbox, yank authority, signature keys, organisation and domain access) are concentrated on a single person — a classic single point of failure that undermines the security processes promised in Chapter 6 (A4, A6, A7) in the event of illness or overload.

The integration into the roll-out strategy (Chapter 9) comprises four elements: a contractually bound deputy with documented yank and merge rights; a break-glass runbook alongside a shared credential vault and a second organisation ownership; a more realistic formulation of the review SLA (acknowledgement within two working days instead of more ambitious commitments) as long as no second responder is active; and a reduction of communication and event commitments to a sustainable level. Residual risk: The model remains person-centred; it reduces the bus factor from one to two, no more.

10.6 External Threats  

In addition to the internal gaps, external threats were evaluated and ranked. (1) An official TYPO3 initiative — analogous to the official Drupal skills project — would have an immediate legitimacy advantage; the counter-strategy is cooperation instead of competition, for which the Endorsed Operator model provides the framework. The HACS precedent demonstrates that community registries can coexist alongside official channels if they honestly declare their status and operate faster. (2) An expansion of the curated Netresearch marketplace is both a threat and an opportunity: webconsulting already lists attributions for these skills; an early partnership with shared governance is preferable to a split ecosystem of two agencies. (3) Horizontal directories such as skills.sh or SkillsMP can introduce a TYPO3 tag at any time and immediately gain a volume advantage; however, they cannot structurally test — the differentiation lies in verified LTS compatibility, not in list length. (4) Anthropic itself remains horizontally aligned with its showcase catalogue and plugin infrastructure , ; the direct risk is low, but naming restrictions around the provider's brand must be observed — positioning is achieved via the open specification concept .

10.7 Requirements Coverage: Matrix A1–A12  

The summary evaluation checks whether each requirement is covered by a designated mechanism and what residual risk remains.

Table 10.2: Coverage of the requirements catalogue A1–A12 with remaining residual risks

The picture is consistent: no requirement is left uncovered, and none is met risk-free. The residual risks are concentrated along two axes — time (A2/A11: decay) and people (A4/A7/A12: capacity) — and this is precisely where the design directs its countermeasures.

10.8 Limitations of this Work  

Three limitations restrict the validity of this work. First, the study is a single-case study: the design is tailored to the TYPO3 ecosystem; whether the mechanisms can be transferred to other vertical ecosystems is argued plausibly but not demonstrated. Second, it is an ex-ante design without field evaluation: no operational data regarding installation numbers, review throughput, or actual security incidents of the directory is available; the evaluation relies on adversarial criticism and precedents, rather than measurement. Third, the source material is typical of a very young ecosystem: key evidence consists of blog posts, developer documentation, and repositories rather than peer-reviewed literature, and metrics such as the proportion of security-critical skills are based on individual surveys. Finally, it is important to note what the design does not solve: it does not eliminate extra-contractual liability exposure, but merely mitigates it; it guarantees neither insurability nor successful negotiations with the TYPO3 Association; and it cannot outperform an official, well-resourced ecosystem initiative, but can only offer a compatible proposal for cooperation.

10.9 Interim Conclusion  

The adversarial gap analysis has materially changed and thereby strengthened the design in four areas: ageing transparency instead of silently expiring credentials, the Endorsed Operator model instead of an unresolved ownership question, process badges including an insurance workstream instead of unverified assumptions of liability, and a deputy model instead of a bus factor of one. The requirements matrix shows complete, but nowhere risk-free coverage; the remaining risks are named, dated, and provided with decision points. For the design, the implication is: its resilience depends less on the architecture than on capacity, negotiation outcomes, and the discipline to let published expiry and governance rules apply even against oneself. A field evaluation in live operation remains the necessary next step and is detailed as an outlook in Chapter 11.

11 Conclusion and Outlook 

11.1 Answering the Research Questions  

RQ1 – Deficits of existing distribution channels and lessons from established registries. The analysis in Chapters 2 and 3 reveals a structural gap, not a gradual one: by design, horizontal directories cannot deliver what trust in a vertical requires – expert evaluation against a specific platform version, provenance, and recall. The history of registries provides five robust lessons (L1–L5) for this: decoupling discovery and distribution; verifying maintainers rather than individual artefacts; planning for publisher compromise as a default scenario; treating prose as an attack surface; and codifying governance in writing before growth.

RQ2 – Stakeholder requirements. From the perspectives of consuming developers, contributing authors, and the operator, the catalogue A1–A12 emerges (Chapter 4). Its core is a double promise of trust: users demand verified, dated compatibility and security statements; authors demand fair, transparent, and predictable onboarding processes. Both sides require the registry to remain operational even in the event of an issue (yanking, advisories).

RQ3 – Design of the registry. The design answers this question in three dimensions. Technically: a Git-first architecture with a static index as a public contract, CI quality gates including an evaluation harness against real TYPO3 projects, and distribution via all established channels (Chapter 5). Organisationally: a four-stage review pipeline, earned namespaces, and a security process modelled on the TYPO3 Security Team (Chapter 6). Legally: trademark-compliant naming , an SPDX-based licence architecture, DSA-compliant reporting channels , and – as a key consequence of the liability analysis – badge semantics as dated process statements rather than assurances of results (Chapter 7).

RQ4 – Viability of long-term operations. The economic analysis (Chapter 8) is clear: in a niche ecosystem, the registry is not self-sustaining as a standalone product, but certainly is as strategic infrastructure – a free core catalogue, revenue from workshops, sponsorship, and later private registries. The operator model follows the Packagist precedent : private operation with a neutral, published listing policy and the goal of achieving Endorsed Operator status. The operational limit is real (Chapter 9): without delegation and prioritisation, the programme exceeds the capacity of a single operator several times over.

11.2 Contributions of the Work  

Table 11.1: Contributions of the work and their transferability

The common thread running through all six contributions is the same insight: The value of a curated directory lies not in the skills themselves, but in verified statements about skills. Everything about the design – architecture, governance, law, economics – serves the resilience of these statements over time.

11.3 Limitations  

The main limitations of this work are detailed in Chapter 10 and are only briefly outlined here: it is a single case study based on the example of TYPO3; the design is ex-ante and lacks field evaluation; the source material of a very young ecosystem partly consists of grey literature (blog posts, vendor specifications) and was, where possible, verified using primary sources. Figures – such as on the review economy – are reasoned estimates, not measurements.

11.4 Outlook  

Three areas of future work suggest themselves:

1. Field evaluation. With the launch of the directory (Chapter 9), real usage data will be generated. The adoption metrics from Chapter 4 and the cost models from Chapters 8 and 10 can then be empirically tested – including the question of whether the freshness mechanics (A11) actually maintain trust over the next TYPO3 LTS cycle.
2. Standardisation of trust metadata. Compatibility, verification, and provenance statements are currently directory-specific. Their inclusion in the open specification would make verified skills portable – an obvious contribution to the standardisation community.
3. Automated prompt injection detection in prose. The security analysis shows that text content is the actual attack surface . Heuristic linters, as outlined in Chapter 5, are a start; robust, evaluated detection methods for natural language instruction texts remain an open field of research.

Whether the TYPO3 ecosystem receives its skills directory from this thesis, from an official initiative, or from a consortium of several agencies is secondary. What is crucial is that it receives one that can substantiate, date, and revoke its trust statements. This thesis demonstrates that and how such a directory can be built – the rest is collaborative community work.

Appendix A: Glossary