TER for Agent Skills: Why the TYPO3 Ecosystem Needs a Curated Skills Registry Now

Agent skills are the new delivery channel for developer knowledge: Markdown folders that supply AI coding agents like Claude Code, Cursor, or Gemini CLI with specialised knowledge when required. The format is an open specification supported by around 30 agents – and the ecosystem is growing faster than anyone can verify what is actually being installed.

For TYPO3, this represents an opportunity: horizontal marketplaces do not test skills against real TYPO3 projects, their scrapers do not distinguish between v13 and v14 APIs, and an official TYPO3 registry does not yet exist. With 137 curated skills, we already operate one of the largest quality-assured skill catalogues focusing on TYPO3 . In this article, we describe in detail what a curated agent skills registry for the TYPO3 ecosystem could look like: architecture, governance, legal aspects, and long-term viability. This post is a strategic analysis and, at the same time, an invitation to the community to join the conversation.

Table of Contents  

The Current Situation: Many Skills, Barely Any Verification  

The skill landscape has evolved within a few months from a single reference repository to a dozen registries. Anthropic maintains a curated example catalogue , Vercel's skills.sh relies on install telemetry and leaderboards , SkillsMP indexes skills via GitHub scrapers – and explicitly states that it does not certify security . All of these providers compete on quantity; verified quality for a single CMS is currently not offered by anyone.

The security situation is not a sideshow but the central argument: Snyk's ToxicSkills analysis found everything from prompt injection to infostealers in public skill registries . Skills present a larger attack surface than traditional packages – the mere text of a SKILL.md can manipulate an agent, without any executable code.

Other CMS communities are already further ahead: on Drupal.org, there is already a CI-validated Agentic Skills project by the Drupal AI initiative . In the TYPO3 environment, Netresearch's curated Claude Code Marketplace provides a good building block, but not yet a shared, ecosystem-wide registry. Whoever fills this gap first with a solid offering is likely to significantly shape further development in the ecosystem.

What a Curated Registry Can Deliver  

Horizontal registries only list skills; they cannot test them. A registry specialising in TYPO3 can therefore make commitments that are out of reach for a scraper:

Trust badges must state exactly what they verify – and what they do not. The importance of this is demonstrated by recent supply-chain attacks: in the Nx incident, developer packages with millions of weekly downloads were trojanised via compromised publishing credentials . A badge that only verifies identity creates a false sense of trust in the content. That is why we rely on tiered, dated statements about the verification process:

Architecture: Git-First Instead of Platform Monolith  

The most important architectural lesson comes from our own ecosystem: TER has survived as a trust and discovery layer, while distribution has long since migrated to Composer/Packagist – TER's own Composer repository is deprecated . Discovery and distribution can therefore be decoupled. Our architecture is built on this principle: the registry is responsible for discovery and trust, while delivery is handled by existing channels.

The monorepo is the source of truth; a CI job generates a static index (JSON, Atom feed, checksums, provenance records) from it. A database is only introduced when self-service publishing actually requires it – until then, the static index also serves as the public read API. Registry-specific metadata remains spec-compliant in frontmatter fields with their own namespace :

name: typo3-solr
description: Configures and debugs Apache Solr for TYPO3 (EXT:solr).
license: CC-BY-SA-4.0
metadata:
version: "1.3.0"
typo3/core: "13,14"
registry/maturity: stable
registry/tested: "14.3@2026-07"
registry/agents: "claude-code,cursor,codex,gemini-cli,windsurf"

For distribution, we cover all paths that developers already use. A marketplace.json makes the repository directly installable in Claude Code via /plugin marketplace add . npx skills add reaches around 70 agents, utilizing automatic conversion where necessary for agents without native support for the specification . An MCP server with a verified namespace offers search and installation capabilities for agents , and a Composer plugin meets TYPO3 teams exactly where their projects live. Updates never go unnoticed: skills represent an attack surface for prompt injection, which is why every update displays its changelog before being applied.

Governance: Who Verifies, Who Maintains, Who Revokes?  

A registry is only as trustworthy as its review process and only as fair as its rules. Submissions are PR-based and follow a four-stage process:

1. Bot Triage: Completeness, DCO sign-off, one skill submission per pull request.
2. CI Gates: Schema validation, link and licence verification, secret scanning – plus a prompt injection linter that detects exfiltration instructions, hidden HTML comments, and destructive defaults.
3. Functional Review: A maintainer executes the skill against a real TYPO3 v14.3 project in DDEV and evaluates it according to a published rubric.
4. Editorial & Publish: Naming and overlap checks, provenance entry, publication with a documented review.

Namespaces cannot simply be reserved: the name typo3-seo is awarded to whoever provides the first accepted submission. Verified vendor namespaces like netresearch/* give agencies their own clearly assigned space; a public Verified Publisher profile makes their contributions visible and simultaneously supplies the registry with valuable content. Orphaned skills undergo an adoption process modelled after TER, rather than quietly growing obsolete.

For emergencies, we adopt the playbook of the TYPO3 Security Team : intake via a security email address, coordinated advisories with sequential numbering – and a signed yank feed that installers check during every sync. A revoked skill not only disappears from the index but actively warns everyone who has installed it. Currently, no horizontal registry offers this. As the registry grows, governance will follow the Drupal model: maintainers are audited thoroughly once, and their subsequent projects are then covered with minimal effort via a badge .

Legal Aspects: Trademark, Licences, Liability  

Three further legal areas determine how robustly the project is positioned:

Licences. Every skill declares its licence as an SPDX field in the frontmatter; the registry only hosts what permits redistribution – everything else is linked as a metadata entry instead of being mirrored. Attribution is a mandatory field: upstream credits, such as Netresearch's preliminary work, are preserved in a machine-readable format.

Platform obligations. As soon as the registry hosts third-party submissions, the basic hosting obligations of the Digital Services Act apply: a notice-and-action mechanism, statements of reasons for removals, and designated points of contact . For a micro-enterprise, this remains straightforward to implement – a 'Report a Skill' form with a documented takedown process covers the core requirements.

Product liability. The new EU Product Liability Directive classifies software as a product; the implementation deadline ends on 9 December 2026 . The open-source exemption only applies outside commercial activity – for an agency-run registry, this exemption is fragile. Consequently: badges describe verification processes rather than outcome guarantees, disclaimers appear in every installation channel (frontmatter, installer output, MCP description), and the appointment with the law firm happens before the launch, not after.

Erosion of Trust Over LTS Cycles  

An inconvenient reality remains for any such initiative: verification results inevitably grow outdated. TYPO3 delivers on an LTS schedule , and with every major release, tested skills age . We counter this with a published policy for the ageing of audits (decay policy): 'Tested on v14.3' remains as a dated, versioned statement, and a calculated freshness status (current / untested on new LTS / outdated) makes the ageing visible. A core of around 40 core-certified skills is guaranteed to be re-certified within 30 days of an LTS release; the rest is maintained by the community, with their verification status remaining visible.

How the Registry Sustains Itself in the Long Term  

A realistic assessment upfront: TYPO3 is a niche ecosystem with a few hundred relevant agencies, strongly focused on the DACH region. A paid skill marketplace would not be viable on this basis – nor does it need to be. The registry is not a product business, but a long-term strategic advantage for the operator: the public catalogue remains permanently free. Revenue is generated through accompanying offerings – team workshops on AI-assisted TYPO3 development, sponsorship once relevant reach is achieved, and later, hosted private registries for agencies with proprietary skills.

There are also proven models for the question of ownership: Packagist.org is still operated by a private GmbH to this day, yet remains the neutral registry for the PHP ecosystem . HACS became a partner of the Open Home Foundation without transferring ownership . This is the model we are aiming for: privately operated with a published, neutral listing policy, plus 'Endorsed Operator' status in partnership with the TYPO3 Association . The Association's Community Budget is only eligible for separable open infrastructure – the funding guidelines explicitly exclude ideas with a direct commercial purpose ; we respect this boundary from the outset.

Frequently Asked Questions  

Conclusion  

There is likely not much time left: the Agent Skills specification is established , horizontal registries have made the security problem visible , Drupal already has an official model – yet there is nothing comparable for TYPO3. Whoever brings curation, testing, and clear governance together now can become the reference point for the entire ecosystem.

We are bringing 137 skills, the verification tooling, and this concept to the table. For this, we need the community – just as they supported TER.