Wenn jemand sagt, man solle ein Plug-in für ein KI-Tool entwickeln, denken die meisten an SDKs, an Boilerplate-Code, an Dokumentationen, die man erst dreimal lesen muss, bevor man den Einstiegspunkt findet. Ich hatte dieselbe Erwartung, als ich mich vor ein paar Wochen entschieden habe, ein Plug-in für Claude Code zu bauen. Claude Code ist Anthropics Kommandozeilen-Tool für KI-gestützte Softwareentwicklung, und seit einiger Zeit lassen sich dafür eigene Plug-ins entwickeln und über einen Marketplace verteilen.

Das Plug-in, das ich gebaut habe, bindet EventSourcingDB an, eine Datenbank, die speziell für Event Sourcing konzipiert ist. Der Vollständigkeit halber: EventSourcingDB ist ein Produkt meines Unternehmens, der the native web GmbH. Dieser Blogeintrag ist jedoch kein Text über die Datenbank, sondern über das, was ich beim Entwickeln des Plug-ins gelernt habe. Die Datenbank dient lediglich als konkretes Beispiel, an dem sich die Erkenntnisse nachvollziehen lassen.

Was Claude-Code-Plug-ins eigentlich sind

Bevor ich auf das Plug-in selbst eingehe, lohnt sich eine kurze Einordnung. Denn Claude-Code-Plug-ins sind nicht das, was man vielleicht erwartet, wenn man den Begriff „Plug-in“ hört.

In der Welt der KI-gestützten Entwicklungstools hat sich in den vergangenen Monaten vor allem ein Standard etabliert: das Model Context Protocol, kurz MCP. MCP-Server stellen einem KI-Modell Werkzeuge zur Verfügung, die es aufrufen kann. Das Modell entscheidet selbst, wann welches Werkzeug sinnvoll ist, und ruft die entsprechende Funktion auf. Für EventSourcingDB gibt es bereits einen solchen MCP-Server. MCP-Server sind mächtig, erfordern aber eine gewisse Infrastruktur: Man braucht einen laufenden Serverprozess, eine Transportschicht und eine Tooldefinition im JSON-Schema-Format.

Claude-Code-Plug-ins verfolgen einen anderen Ansatz. Sie erweitern Claude Code nicht durch laufende Prozesse, sondern durch sogenannte Skills (genau genommen kann ein Plug-in neben Skills noch andere Dinge enthalten, aber für mein Beispiel beschränke ich mich auf sie). Ein Skill ist dabei im Kern eine Textdatei, die Claude Code erklärt, wie es eine bestimmte Aufgabe erledigen soll. Das klingt zunächst unspektakulär, ist aber bemerkenswert effektiv. Statt einer programmatischen Schnittstelle erhält das Modell eine natürlichsprachliche Anleitung, die es interpretiert und umsetzt. Plug-ins lassen sich über einen Marketplace installieren und verteilen, sodass andere Entwicklerinnen und Entwickler sie einfach nutzen können.

Die Anatomie eines Plug-ins

Was mich am meisten überrascht hat, war die Struktur eines Plug-ins. Oder besser gesagt: wie wenig Struktur nötig ist. Die Verzeichnisstruktur des EventSourcingDB-Plug-ins sieht beispielsweise folgendermaßen aus:

/
  .claude-plugin/
    marketplace.json
  plugins/
    esdb/
      .claude-plugin/
        plugin.json
      skills/
        ping/
          SKILL.md
        write-events/
          SKILL.md
        read-events/
          SKILL.md
        ...

Das ist die gesamte Struktur. Kein SDK, kein Framework, kein Build-Schritt. Im Kern besteht ein Plug-in aus zwei Dingen: einer Plug-in.json und einer Sammlung von SKILL.md-Dateien.

Die plugin.json ist das Manifest. Sie definiert den Namen, die Version und eine kurze Beschreibung. Das sieht für das EventSourcingDB-Plug-in in etwa so aus:

{
  "name": "esdb",
  "version": "1.0.0",
  "description": "Interact with EventSourcingDB using its HTTP API",
  "author": {
    "name": "the native web GmbH",
    "email": "hello@thenativeweb.io"
  }
}

Jeder Skill liegt in einem eigenen Unterverzeichnis und besteht aus einer eigenen SKILL.md-Datei. Diese Datei beginnt mit einem Frontmatter-Block, der den Namen und eine Beschreibung enthält, gefolgt von den eigentlichen Anweisungen in natürlicher Sprache:

---
name: ping
description: Check whether an EventSourcingDB instance is reachable.
---

# Ping

Send a GET request to $ESDB_URL/api/v1/ping to check whether
the EventSourcingDB instance is reachable. No authentication
is required for this endpoint. A successful response returns
HTTP 200 with the text "OK".

Das ist, in vereinfachter Form, der gesamte Ping-Skill. Claude Code liest diese Beschreibung und setzt sie eigenständig um. Es generiert den HTTP-Aufruf, sendet ihn und interpretiert die Antwort. Die eigentliche Logik steckt nicht in ausführbarem Code, sondern in einer präzisen Beschreibung. Die Qualität des Plug-ins hängt damit nicht von der Qualität des Codes ab, sondern von der Qualität der Beschreibung.

Auf der Ebene darüber liegt die marketplace.json. Sie beschreibt, welche Plug-ins ein Marketplace anbietet. Claude Code hat einen offiziellen Marketplace, der von Anthropic verwaltet wird und geprüfte Plug-ins enthält. Darüber hinaus kann aber jede Person und jede Organisation einen eigenen Marketplace erstellen. Es genügt ein GitHub-Repository mit einer marketplace.json im Verzeichnis .claude-Plug-in. Das war für mich ein entscheidender Punkt: Man ist nicht auf eine zentrale Instanz angewiesen, sondern kann Plug-ins auch intern oder für die eigene Community bereitstellen, ohne einen Freigabeprozess durchlaufen zu müssen.

Für jemanden wie mich, der seit über zwanzig Jahren Software entwickelt, ist die Art der Plug-in-Entwicklung ein bemerkenswerter Perspektivwechsel. Statt in Funktionen und Klassen zu denken, denkt man in Erklärungen und Anleitungen. Statt eine API zu implementieren, beschreibt man eine API. Die Fähigkeit, präzise und unmissverständlich zu formulieren, wird zur eigentlichen Entwicklungskompetenz.

Vom leeren Verzeichnis zum funktionierenden Plug-in

Wie sah nun der praktische Weg aus? Ich habe mit einem leeren Repository und der Frage begonnen, welche Interaktionen mit EventSourcingDB ich abbilden wollte. Die Datenbank bietet eine HTTP-API mit einer überschaubaren Anzahl von Endpunkten: Events schreiben, Events lesen, Events beobachten, Subjects abfragen, Event-Typen auflisten, EventQL-Queries ausführen und Schemas registrieren. Dazu kommen administrative Funktionen wie Ping und die Verifikation des API-Tokens.

Für jeden dieser Endpunkte habe ich einen eigenen Skill angelegt. Das klingt nach viel Arbeit, war es aber nicht. Zum einen folgt nämlich jeder Skill demselben Muster: eine kurze Beschreibung des Zwecks, die relevanten API-Endpunkte mit ihren Parametern, Hinweise zur Authentifizierung und Beispiele für typische Aufrufe und Antworten. Die Markdown-Dateien sind jeweils zwischen rund 30 und 80 Zeilen lang. Zum anderen habe ich auch dazu wiederum Claude Code genutzt: Ich habe die Skills also nicht von Hand geschrieben, sondern Claude Code jeweils beschrieben, was ich erreichen möchte und die Skills anschließend generieren lassen.

Der erste Skill, den ich auf diesem Weg erstellt habe, war der einfachste: der oben bereits erwähnte Ping-Skill. Dieser Skill prüft, ob eine EventSourcingDB-Instanz erreichbar ist. Die zugehörige Beschreibung umfasst kaum mehr als den API-Endpunkt, die erwartete Antwort und einen Hinweis, dass keine Authentifizierung nötig ist. Innerhalb weniger Minuten war der Skill fertig, und Claude Code konnte ihn verwenden.

Was mich überrascht hat: Es funktionierte auf Anhieb. Kein Debugging, kein Trial-and-Error, kein stundenlanges Nachjustieren. Claude Code las die Beschreibung, verstand die Aufgabe und führte den HTTP-Aufruf korrekt aus. Ermutigt durch diesen schnellen Erfolg habe ich die weiteren Skills in rascher Folge geschrieben. Nach einem Nachmittag war das Plug-in vollständig.

Das soll nicht den Eindruck erwecken, es hätte keinerlei Herausforderungen gegeben. Die Beschreibung des Skills für das Beobachten von Events erforderte mehr Sorgfalt, weil hier eine langlebige HTTP-Verbindung mit NDJSON-Streaming im Spiel ist. Ich musste Claude Code erklären, dass die Verbindung offen bleibt und kontinuierlich Daten liefert. Aber auch das war eine Frage der richtigen Formulierung, nicht der richtigen Implementierung.

Was das Plug-in kann und wie es funktioniert

Das fertige Plug-in umfasst zehn Skills, die fast die gesamte HTTP-API von EventSourcingDB abdecken. Die Installation erfolgt in zwei Schritten. Zunächst fügt man den Marketplace hinzu:

/plugin marketplace add thenativeweb/claude-plugins

Anschließend installiert man das Plug-in:

/plugin install esdb@thenativeweb

Danach stehen die Skills zur Verfügung. Jeder Skill hat einen Namespace-Präfix, der sich aus dem Plug-in-Namen ergibt, und wird als Slash-Command aufgerufen. Um etwa die Erreichbarkeit einer EventSourcingDB-Instanz zu prüfen, genügt:

/esdb:ping

Für komplexere Interaktionen übergibt man Argumente in natürlicher Sprache. Ein Aufruf wie:

/esdb:write-events Schreibe ein Event vom Typ „io.eventsourcingdb.library.book-acquired“ für das Subject „/books/42“ mit den Daten title „2001“, author „Arthur C. Clarke“

veranlasst Claude Code, den passenden HTTP-Request zu konstruieren und an die Datenbank zu senden. Das Modell interpretiert die natürlichsprachliche Beschreibung, bildet sie auf die API-Parameter ab und gibt das Ergebnis lesbar aus. Dasselbe gilt für EventQL-Queries, bei denen Claude Code die Abfrage auf Basis der Skill-Beschreibung in das richtige Format übersetzt.

Besonders aufschlussreich war die Arbeit an den Skills für das Lesen und Beobachten von Events. Beide nutzen denselben Endpunkt, unterscheiden sich aber in ihrem Verhalten: Lesen liefert eine endliche Menge von Events und schließt die Verbindung, Beobachten hält die Verbindung offen und streamt neue Events in Echtzeit. Diese Unterscheidung musste in der Beschreibung klar herausgearbeitet werden, weil Claude Code sonst nicht wüsste, wann es die Verbindung schließen soll und wann nicht.

Hier zeigt sich ein wichtiges Muster: Die Qualität eines Skills hängt davon ab, wie gut man die Semantik einer Aktion beschreiben kann. Es reicht nicht, die technischen Parameter eines API-Aufrufs aufzulisten. Man muss dem Modell das Warum und das Wann vermitteln, nicht nur das Wie. Das ist eine andere Art zu denken als beim klassischen Programmieren, und sie erfordert eine andere Art von Sorgfalt.

Die Konfiguration des Plug-ins erfolgt über Umgebungsvariablen. Die URL der EventSourcingDB-Instanz und der API-Token werden beim Start gesetzt, und die Skills referenzieren diese Werte in ihren Beschreibungen. Auch das ist bemerkenswert einfach: keine Konfigurationsdateien, keine verschachtelten Einstellungen, keine Initialisierungslogik.

Plug-ins als Brücke zwischen KI und Fachdomäne

Was lässt sich aus dieser Erfahrung verallgemeinern? Drei Beobachtungen erscheinen mir besonders relevant.

Erstens: Die Einstiegshürde für Claude-Code-Plug-ins ist bemerkenswert niedrig. Wer eine HTTP-API hat und sie in natürlicher Sprache beschreiben kann, kann ein Plug-in bauen. Es sind keine besonderen Programmierkenntnisse nötig, kein Verständnis von Compiler-Infrastruktur, keine Erfahrung mit Plug-in-Architekturen. Die einzige Voraussetzung ist die Fähigkeit, präzise zu formulieren, was eine Aktion tut, welche Eingaben sie erwartet und welche Ausgaben sie liefert. Das macht die Plug-in-Entwicklung zugänglich für eine breite Gruppe von Entwicklerinnen und Entwicklern.

Zweitens: Skills als natürlichsprachliche Beschreibungen sind ein ungewöhnlich mächtiges Konzept. Sie ermöglichen es, domänenspezifisches Wissen in ein KI-Tool einzubringen, ohne eine einzige Zeile ausführbaren Code zu schreiben. Das verschiebt die Kernkompetenz: Nicht die Implementierung ist entscheidend, sondern das Verständnis der Domäne und die Fähigkeit, dieses Verständnis klar auszudrücken. Für Teams, die mit fachlich komplexen Systemen arbeiten, ist das ein interessanter Ansatz, weil er die Brücke zwischen Fachexpertise und Werkzeugentwicklung verkürzt.

Drittens: Die Grenze zwischen Plug-ins und MCP-Servern verschwimmt, und das ist beabsichtigt. Plug-ins eignen sich gut für Szenarien, in denen ein KI-Tool eine bestehende API nutzen soll und die Interaktion über natürliche Sprache gesteuert wird. MCP-Server sind die bessere Wahl, wenn man programmatische Kontrolle braucht, etwa für komplexe Authentifizierungsflüsse, zustandsbehaftete Sitzungen oder bidirektionale Kommunikation. Beide Ansätze ergänzen sich, und für viele Systeme lohnt es sich, beides anzubieten.

Was mich persönlich am meisten beeindruckt hat, ist die Verschiebung der Perspektive. Ich bin es seit vielen Jahren gewohnt, Code zu schreiben, der Maschinen sagt, was sie machen sollen. Bei einem Claude-Code-Plug-in hingegen schreibe ich lediglich natürlichsprachlichen Text, der einem Sprachmodell erklärt, was es tun soll. Das klingt technisch nach einem kleinen Unterschied, fühlt sich aber nach einem großen an. Die Frage ist nicht mehr „Wie implementiere ich das?“, sondern „Wie erkläre ich das so, dass es verstanden wird?“. Das ist vergleichbar mit einer Erklärung, die man Kolleginnen und Kollegen gibt.

Wer das Plug-in ausprobieren möchte, findet den Quellcode auf GitHub. Die Installation in Claude Code erfordert lediglich die beiden oben genannten Befehle. EventSourcingDB lässt sich bis 25.000 Events kostenfrei nutzen, sodass dem Experimentieren nichts im Wege steht. Wer ein eigenes Plug-in für eine andere API bauen möchte, braucht dafür nicht mehr als ein leeres Verzeichnis und die Bereitschaft, präzise zu formulieren.

(rme)