Ein Plugin bündelt, was Sie bereits geschrieben haben — Befehle, Subagenten, Skills, Hooks — in einem Ordner, den andere installieren können. Das Manifest ist klein und unstrittig, und genau deshalb sind seine Fehler so ärgerlich: eine Version, die keine ist, ein Name mit Großbuchstaben, eine Website ohne Schema. Keiner davon verhindert gültiges JSON, und alle machen später Ärger. Dieser Builder füllt die Felder, prüft die mit Regeln und zeigt die Struktur, die das Manifest erwartet — denn das Manifest allein tut nichts: geladen werden die Ordner daneben.
Funktionen
Name gegen die Namensregeln geprüft
Version als semantische Version geprüft, Vorabversionen inklusive
Autorname und E-Mail korrekt verschachtelt statt flachgeklopft
Website auf ein Schema geprüft
Leere Felder entfallen, statt leer geschrieben zu werden
Die Ordnerstruktur neben dem Manifest
Schlagwörter zeilenweise eingegeben
Lädt als plugin.json herunter
So verwendest du Plugin-Manifest
Benennen Sie das Plugin und geben Sie eine Startversion
Beschreiben Sie, was es bündelt
Ergänzen Sie Autor, Website und Lizenz beim Teilen
Laden Sie plugin.json in den Ordner .claude-plugin
Beispiel
Eingabe
"version": "1.0"
Ausgabe
Error: not a semantic version — use major.minor.patch
Zweiteilige Versionen sind die häufigste Ablehnung.
Häufige Fehler & Fehlerbehebung
Die Version wird abgelehnt. — Semantische Versionen haben drei Teile: 1.0.0, nicht 1.0. Ein Vorabsuffix wie 1.0.0-beta.1 ist in Ordnung.
Das Plugin wird nach der Installation nicht gefunden. — Das Manifest gehört nach .claude-plugin/plugin.json im Plugin-Ordner, nicht in dessen Wurzel. Die Struktur unter der Ausgabe zeigt, wo alles liegt.
Der Name wird abgelehnt. — Kleinbuchstaben, Ziffern und einfache Bindestriche. Er dient als Bezeichner, also fallen Großbuchstaben und Leerzeichen weg.
Nichts lädt, obwohl das Manifest gültig ist. — Das Manifest beschreibt das Plugin nur. Befehle, Agenten, Skills und Hooks werden aus den Ordnern daneben geladen — ein leeres Plugin mit perfektem Manifest tut nichts.
Häufig gestellte Fragen
Was kann ein Plugin enthalten?
Jede Kombination aus Slash-Befehlen, Subagenten-Definitionen, Skills und Hooks, jeweils im eigenen Ordner neben dem Manifest. Alles ist optional: Ein Plugin mit einem nützlichen Befehl ist ein völlig taugliches Plugin.
Welche Felder sind wirklich Pflicht?
In der Praxis der Name. Der Rest sind Metadaten, die es für andere nutzbar machen: eine Beschreibung, damit klar ist, was es ist, eine Version, damit Änderungen erkennbar sind, und eine Website, damit die Quelle auffindbar ist.
Wie sollte ich versionieren?
Beginnen Sie bei 0.1.0, solange sich noch viel bewegt, und behandeln Sie die erste Zahl als Kompatibilitätsversprechen. Einen Befehlsnamen zu ändern oder eine Skill zu entfernen ist für Nutzende ein Bruch.
Brauche ich das Lizenzfeld?
Nur beim Teilen. Und wenn Sie teilen, spart die ausdrückliche Angabe ein Gespräch: Ein Repository ohne Lizenz ist rechtlich unangenehm nachzunutzen, selbst wenn es offensichtlich dafür gedacht ist.
Kann ich ein Plugin aus Vorhandenem bauen?
So fängt es meist an. Befehle und Skills, die schon funktionieren, wandern unverändert in die passenden Ordner; das Manifest ist die einzige neue Datei.
Verwandte Tools
Slash-Befehl-Builder — Bauen Sie einen eigenen Befehl, mit Argumenten und einer Tool-Liste.
Subagent-Builder — Erstellen Sie die Definitionsdatei eines Subagenten samt Tools und Modell.
Skill-Builder — Schreiben Sie eine SKILL.md, deren Frontmatter beim Tippen geprüft wird.
Hooks-Builder — Bauen Sie settings.json-Hooks und finden Sie Matcher, die nie auslösen.