Today we published our concept for a curated Agent Skills registry for TYPO3 – Agent Skills are knowledge packages for AI coding assistants like Claude Code. Following this, we developed the strategy into a detailed scientific paper (monograph): complete with research questions, a catalogue of requirements, an analysis of comparable cases, and a critical risk assessment specifically designed to find weaknesses in our own design.
The result is around 20,000 words across eleven chapters. This article summarises the work: the four research questions and their answers, the core thesis, the transferable tools, and the four risks identified by the analysis of our own design.
"Trust Infrastructure for AI-Assisted Software Development: Designing a Curated Agent Skills Registry for Vertical Software Ecosystems Using the Example of TYPO3" – eleven chapters, glossary, 27 verified sources. You can read the full research article in our Research section – also available as an HTML version and as Markdown source code. Transparency: The work is a design-science study from practical application in a dissertation style – AI-supported, editorially reviewed, and not submitted to any university.
Four Research Questions, Four Answers
The study follows the Design Science Research approach: insights are generated by designing something concrete and evaluating it critically – in this case, the registry concept. The paper is structured around four research questions. Here are the answers, each in a single sentence:
| No. | Research Question | Answer in a single sentence |
|---|---|---|
| F1 | What deficits do existing distribution channels for Agent Skills have? | There is a lack of curation: Large horizontal registries only list skills but do not verify them – Snyk found critical issues in around 13% of the examined skills. |
| F2 | What do stakeholders of a CMS ecosystem demand? | A dual promise of trust: proven, dated compatibility and security statements for users, and fair, predictable onboarding processes for authors. |
| F3 | How must a curated registry be designed? | Git-first architecture with a static index, a four-stage review pipeline with a recall mechanism – and badges describing dated verification processes instead of legally risky guarantees. |
| F4 | When is continuous operation self-sustaining? | As a strategic infrastructure with a free core catalogue – not as a product business; operated on the Packagist model with a goal of community recognition. |
The study is based on real-world data: our catalogue of 137 curated skills , the open Agent Skills specification with around 30 supporting agents , the documented security situation of public registries such as skills.sh – and a comparison with Drupal, which already has a CI-validated skills project .
The Core Thesis
The value of a curated registry lies not in the skills themselves, but in verified statements about skills. This trust must be organised as a process: proven (tested on a real TYPO3 project), dated (verification date visible, ageing transparent), and revocable (compromised versions are actively recalled).
All parts of the design – architecture, governance, badge semantics, and also the business model – are designed to ensure that these statements remain resilient over time. Registries that focus solely on quantity cannot deliver this. This is the advantage of a curated, specialised registry.
Five Lessons from 25 Years of Registry History
The study examines every design decision against documented successes and failures of established registries – from TER to npm to the Home Assistant Community Store (HACS). This yields five lessons upon which the design is built:
- Decouple layers. Discovery and trust can be separated from the distribution channel – TER survived as a trust layer while delivery migrated to Composer/Packagist .
- Verify people instead of individual projects. Drupal.org vets maintainers thoroughly once and then marks projects with visible badges – this approach scales .
- Anticipate account takeovers. If a trusted account is compromised, content verification alone no longer helps – as shown by supply chain incidents like Nx. What is needed is proof of origin (provenance) and a recall mechanism .
- Even plain text is an attack surface. Agent Skills can attack via natural language alone (prompt injection); therefore, reviews must inspect both prose and scripts equally .
- Governance before growth. Namespace, dispute, and hand-over rules should be published before they are needed. A path towards community recognition also prevents concentration of power – HACS and the Open Home Foundation demonstrate how this works .
Twelve Requirements, Four Areas
The core of the study is the catalogue of requirements A1–A12. It is derived from the perspectives of users, authors, and the operator, and grouped into four areas:
Verified, Dated Statements
Security as a Process
Fairness for Contributors
Operation and Longevity
The security process deliberately adopts a proven model from our own ecosystem: a central reporting point (intake), coordinated security advisories, and a recall procedure patterned after the TYPO3 Security Team . The coverage matrix in Chapter 10 of the study shows that all twelve requirements are addressed – though none without residual risk.
Four Risks Identified by the Gap Analysis
The methodologically most important part is the critical completeness review. It systematically searched for contradictions and gaps in our own design and identified four problems. All four led to modifications of the design:
What the Study Does Not Solve
The work has clear limitations: it is a single case study based on the example of TYPO3, a design without real-world telemetry, and the sources are sparse because the ecosystem is still very young. The design reduces liability risks but does not eliminate them . Should a well-funded official initiative emerge, this project would have little to counter it – though it could offer a partnership. The trademark issue also remains unresolved: the wordmark "TYPO3" belongs to the TYPO3 Association and may not be used in product or domain names without permission .
Conclusion
The study validates the strategy and has measurably improved it in four areas. The catalogue of requirements A1–A12 and lessons L1–L5 are deliberately designed to be transferable to other ecosystems – such as Drupal, Shopware, or an internal platform team. However, the study notes that this transferability is plausible but unproven. The operating model follows proven precedents , and community funding remains strictly separated .
The complete monograph is freely available, and the strategic analysis can be found in the accompanying article. This study is a draft, not a product announcement – we welcome feedback via our contact form.