plugin-forge

Überblick über den plugin-forge Skill

plugin-forge ist ein Build-und-Wartungs-Skill für Autorinnen und Autoren von Claude Code Plugins, die eine saubere Ordnerstruktur, korrekte Manifest-Dateien und eine funktionierende Marketplace-Registrierung brauchen, ohne den Workflow jedes Mal neu zu erfinden. Die eigentliche Aufgabe ist nicht einfach „etwas JSON schreiben“, sondern „ein Plugin ausliefern, das korrekt scaffolded ist, konsistent versioniert wird und sich in einem marketplace-basierten Workflow installieren lässt“.

Für wen sich plugin-forge am besten eignet

Nutze den plugin-forge Skill, wenn du:

• ein neues Claude Code Plugin von Grund auf erstellst
• Plugin-Bestandteile wie commands/, agents/, skills/ oder hooks/ ergänzt
• .claude-plugin/plugin.json und Marketplace-Metadaten gemeinsam aktualisieren willst
• Plugins lokal testen möchtest, bevor du sie veröffentlichst
• ein Plugin-Repository im Marketplace-Stil mit mehreren Plugins pflegst

Besonders nützlich ist plugin-forge für Entwicklerinnen und Entwickler, die reproduzierbare Strukturen wollen und nicht nur eine einmalige Prompt-Ausgabe.

Was plugin-forge von einem generischen Prompt unterscheidet

Ein generischer Prompt kann zwar ein Plugin-Grundgerüst entwerfen, aber plugin-forge bringt praktische Leitplanken mit:

• ein fest definiertes Plugin-Verzeichnislayout
• klare Manifest-Pfade und konkrete Erwartungen an Felder
• eine Referenz für das Marketplace-Schema
• einen Workflow für lokale Installation und Tests
• Automatisierungsskripte für Scaffolding und Versions-Bumps

Diese Kombination ist wichtig, weil die häufigste Fehlerursache bei Plugins meist nicht schlechter Code ist, sondern eine inkonsistente Struktur oder nicht zueinander passende Metadaten.

Was der Skill tatsächlich abdeckt

Die Repository-Inhalte zeigen, dass plugin-forge sich vor allem auf Folgendes konzentriert:

• scripts/create_plugin.py zum Scaffolden eines neuen Plugins
• scripts/bump_version.py für synchronisierte Versionsupdates
• references/plugin-structure.md für Ordner- und Manifest-Layout
• references/marketplace-schema.md für Regeln zu Marketplace-Einträgen
• references/workflows.md für den Ablauf von Erstellung, Test und Veröffentlichung

Damit ist plugin-forge eher ein Umsetzungsleitfaden mit Hilfstools als ein breit angelegtes Theoriedokument.

Wann plugin-forge besonders gut zu Code Generation passt

plugin-forge für Code Generation ist besonders dann nützlich, wenn das Modell Dateien erzeugen soll, die in der richtigen Plugin-Form landen müssen, zum Beispiel:

• ein neues Plugin-Skelett mit gültigen Metadaten
• ein neuer Command oder Skill in einem bestehenden Plugin
• Änderungen an plugin.json plus passende Anpassungen am Marketplace-Eintrag
• Release-Vorbereitung inklusive semantischer Versionsanhebung

Wenn du vor allem reine Business-Logik in einem bereits funktionierenden Plugin brauchst, hilft plugin-forge weniger als ein domänenspezifischer Coding-Skill.

So verwendest du den plugin-forge Skill

Installationskontext für plugin-forge

Das vorgelagerte SKILL.md veröffentlicht keinen eigenen Installationsbefehl, daher hängt die Installation davon ab, wie du Skills in deiner Umgebung lädst. Wenn du das Skill-Bundle des Repositories nutzt, ist ein typisches Muster:

npx skills add softaworks/agent-toolkit --skill plugin-forge

Danach solltest du plugin-forge immer dann einsetzen, wenn es um Plugin-Erstellung, Manifeste, Marketplace-Registrierung, lokale Tests oder Versionsverwaltung geht.

Diese Dateien solltest du zuerst lesen

Für einen schnellen Einstieg beginne in dieser Reihenfolge:

1. skills/plugin-forge/SKILL.md
2. skills/plugin-forge/references/plugin-structure.md
3. skills/plugin-forge/references/marketplace-schema.md
4. skills/plugin-forge/references/workflows.md
5. skills/plugin-forge/scripts/create_plugin.py
6. skills/plugin-forge/scripts/bump_version.py

So bekommst du zuerst das „Was“, dann das erwartete Dateilayout, danach den Marketplace-Vertrag und schließlich die direkt nutzbaren Hilfsskripte.

Welche Eingaben plugin-forge von dir braucht

plugin-forge funktioniert am besten, wenn du konkreten Repository- und Veröffentlichungskontext mitgibst, nicht nur „mach mir ein Plugin“. Mindestens angeben solltest du:

• Plugin-Name in kebab-case
• Root-Pfad des Marketplace
• Zweck des Plugins
• Name und E-Mail der Autorin oder des Autors
• anfängliche Keywords
• Kategorie
• ob du commands, agents, skills, hooks oder MCP-Konfiguration brauchst
• ob es sich um ein neues Plugin oder ein Update für ein bestehendes handelt

Ohne diese Angaben kann das Modell zwar weiterhin Dateien entwerfen, aber die Ausgabe braucht dann meist manuelle Nacharbeit.

So machst du aus einem groben Ziel einen guten plugin-forge Prompt

Schwacher Prompt:

Create a Claude Code plugin for my project.

Stärkerer Prompt:

Use plugin-forge to scaffold a new Claude Code plugin named schema-audit inside /repos/internal-marketplace. Author is Jane Doe <jane@example.com>. Description: “Validate JSON and OpenAPI schemas in CI.” Keywords: schema,openapi,json,validation. Category: developer-tools. Include commands/ and skills/, but no hooks yet. Generate the expected folder layout, plugins/schema-audit/.claude-plugin/plugin.json, the matching .claude-plugin/marketplace.json entry, and a short README. Follow the marketplace and plugin structure references.

Der zweite Prompt gibt plugin-forge genug Informationen, um Dateien zu erzeugen, die deutlich näher an einer direkt nutzbaren Lösung liegen.

Nutze das Scaffolding-Skript, wenn du schnell vorankommen willst

Wenn deine Metadaten bereits feststehen, nutze lieber das Hilfsskript, statt den initialen Baum manuell aufzubauen:

python scripts/create_plugin.py plugin-name \
  --marketplace-root /path/to/marketplace \
  --author-name "Your Name" \
  --author-email "your.email@example.com" \
  --description "Plugin description" \
  --keywords "keyword1,keyword2" \
  --category "productivity"

Das ist der schnellste Weg, wenn dir ein korrekter Setup wichtiger ist als ein individuell von Hand gebautes Scaffolding.

Nutze das Versionsskript, um Manifest-Drift zu vermeiden

Einer der praktischsten Teile von plugin-forge ist die synchronisierte Versionierung. Der Skill enthält scripts/bump_version.py, um beide Dateien gleichzeitig zu aktualisieren:

• plugins/<plugin-name>/.claude-plugin/plugin.json
• .claude-plugin/marketplace.json

Beispiel:

python scripts/bump_version.py plugin-name patch \
  --marketplace-root /path/to/marketplace

Das ist wichtig, weil Versionsabweichungen zwischen diesen Dateien ein häufiger Wartungsfehler sind.

Folge dem tatsächlichen plugin-forge Workflow

Ein praxisnaher plugin-forge Ablauf sieht so aus:

1. Plugin scaffolden
2. generiertes plugin.json prüfen
3. Marketplace-Eintrag in .claude-plugin/marketplace.json verifizieren
4. Komponenten wie Commands oder Skills ergänzen
5. lokal über den Marketplace-Installationsfluss testen
6. iterieren
7. vor dem Release die Version erhöhen

Dieser Ablauf ist zuverlässiger, als das Modell mit einem einzigen riesigen Prompt alles auf einmal erledigen zu lassen.

Den lokalen Testablauf früh mit einplanen

Die Referenzen enthalten einen konkreten Pfad für lokale Tests:

/plugin marketplace add /path/to/marketplace-root
/plugin install plugin-name@marketplace-name

Das bedeutet: Du solltest Prompts so formulieren, dass plugin-forge installierbare Pfade und Metadaten erzeugt, nicht nur beschreibende Dateien. Wenn Source-Pfad oder Plugin-Name nicht konsistent sind, scheitert der Test sofort.

Wichtige Dateien, die plugin-forge häufig ändert

In der Praxis erstellt oder bearbeitet plugin-forge oft diese Dateien:

• plugins/<plugin-name>/.claude-plugin/plugin.json
• .claude-plugin/marketplace.json
• plugins/<plugin-name>/README.md
• plugins/<plugin-name>/commands/
• plugins/<plugin-name>/agents/
• plugins/<plugin-name>/skills/
• plugins/<plugin-name>/hooks/hooks.json
• plugins/<plugin-name>/.mcp.json

Das ist hilfreich für die Review-Planung, denn plugin-forge erzeugt häufig Änderungen über mehrere Dateien hinweg.

Praktische Tipps für bessere plugin-forge Ergebnisse

Bitte plugin-forge darum:

• bestehende Plugin-Namen und Pfade exakt beizubehalten
• alle Bezeichner in kebab-case zu halten
• Plugin-Manifest und Marketplace-Eintrag gemeinsam zu zeigen
• alle Pflichtfelder zu benennen, die nicht zuverlässig abgeleitet werden konnten
• „generierte Dateien“ klar von „manueller Nacharbeit“ zu trennen
• zu prüfen, ob Versionen und Namen über alle Manifeste hinweg übereinstimmen

Damit sinkt das Risiko einer ansprechend aussehenden, aber nicht installierbaren Ausgabe.

plugin-forge Skill FAQ

Lohnt sich plugin-forge, auch wenn ich schon gut prompten kann?

Ja, wenn dein Hauptrisiko in der strukturellen Korrektheit liegt. Der plugin-forge Skill ist nützlicher als ein normaler Prompt, wenn du konsistente Manifeste, Marketplace-Einträge und ein sauberes Verzeichnislayout brauchst. Wenn du nur Hilfe beim Schreiben einer einzelnen Command-Datei in einem bestehenden Plugin willst, ist der Vorteil kleiner.

Ist plugin-forge anfängerfreundlich?

Größtenteils ja. plugin-forge gibt Einsteigerinnen und Einsteigern einen konkreten Pfad durch Plugin-Erstellung und Tests. Der Haken ist: Man muss trotzdem den eigenen Marketplace-Root, die Namenskonventionen und die tatsächlich gewünschten Komponenten verstehen. Der Skill hilft stärker bei der Struktur als beim Produktdesign.

Wann solltest du plugin-forge nicht verwenden?

Verzichte auf plugin-forge, wenn:

• du kein Claude Code Plugin baust
• du keine Distribution im Marketplace-Stil nutzt
• du nur generische Python- oder JavaScript-Codegenerierung willst
• dein Repository ein bewusst abweichendes, eigenes Plugin-Layout hat

In solchen Fällen kann plugin-forge dich in die falsche Struktur lenken.

Übernimmt plugin-forge das Publishing automatisch?

Nicht vollständig. Der Skill deckt die Vorbereitung gut ab: Scaffolding, Manifeste, Marketplace-Registrierung, Hinweise für lokale Tests und Versionsupdates. Aber plugin-forge ist keine End-to-End-Release-Plattform. Du musst Dateien weiterhin prüfen, lokal testen und deinen eigenen Publishing- oder Distributionsprozess ausführen.

Was ist die größte Hürde bei der Einführung?

Meist fehlender Repository-Kontext. plugin-forge setzt voraus, dass du weißt, wo dein Marketplace-Root liegt und wie dein Plugin kategorisiert werden soll. Wenn du diese Fragen nicht beantworten kannst, bleibt die Ausgabe eher auf Entwurfsniveau statt produktionsreif zu sein.

Wie schneidet plugin-forge im Vergleich zur manuellen Manifest-Bearbeitung ab?

Manuelle Änderungen funktionieren für einmalige Anpassungen, aber plugin-forge ist besser, wenn du Wiederholbarkeit willst oder Drift zwischen plugin.json und marketplace.json vermeiden musst. Die mitgelieferten Skripte sind hier der klarste praktische Vorteil.

So verbesserst du den plugin-forge Skill

Gib plugin-forge repository-nahe Eingaben

Die beste Verbesserung ist, exakte Pfade und aktuelle Dateien mitzugeben. Statt nach „einem Versions-Bump“ zu fragen, sage zum Beispiel:

Use plugin-forge to bump schema-audit in /repos/internal-marketplace from its current version using a minor change. Check both plugins/schema-audit/.claude-plugin/plugin.json and .claude-plugin/marketplace.json, then show the diff.

Damit lenkst du den Skill stärker in Richtung überprüfbarer Änderungen statt allgemeiner Ratschläge.

Verlange dateiweise Ausgabe statt nur einer Zusammenfassung

plugin-forge arbeitet besser, wenn du konkrete Deliverables anforderst:

• vollständiges plugin.json
• exakter Marketplace-Eintrag
• vorgeschlagener Verzeichnisbaum
• README-Startfassung
• Folgekommandos für lokale Tests

Das ist besonders wichtig bei plugin-forge für Code Generation, weil der eigentliche Wert in direkt anwendbaren Dateien liegt.

Vermeide die häufigsten Fehlerbilder

Achte bei plugin-forge Ausgaben besonders auf diese Punkte:

• Plugin-Name ist in Dateien nicht identisch
• Marketplace-source-Pfad passt nicht zum tatsächlichen Ordnerlayout
• Version wurde nur in einem Manifest aktualisiert, nicht im anderen
• optionale Komponenten sind in Metadaten referenziert, wurden aber nicht erzeugt
• die generierte Struktur enthält kein .claude-plugin/plugin.json

Ein kurzer Abgleich mit references/plugin-structure.md und references/marketplace-schema.md deckt die meisten dieser Probleme auf.

Nutze einen Zwei-Pass-Workflow für bessere plugin-forge Ergebnisse

Ein starker plugin-forge Leitfaden für die Praxis sieht so aus:

1. erster Durchlauf: Struktur und Manifeste erzeugen
2. zweiter Durchlauf: Plugin-Komponenten und README verbessern

Wenn du Scaffolding, Business-Logik, Dokumentation, Test-Setup und Publishing-Hinweise in einen einzigen Prompt presst, leidet die Qualität oft. plugin-forge ist am stärksten, wenn zuerst die Struktur steht.

Iteriere nach der ersten Ausgabe mit gezielten Korrekturen

Sag nicht einfach nur „fix this“. Gib präzise Reparaturanweisungen, zum Beispiel:

• „Regenerate marketplace.json entry so source points to ./plugins/schema-audit.”
• „Add skills/ to the tree and keep manifest fields unchanged.”
• „Update only version fields; do not rewrite descriptions or keywords.”
• „Align the plugin name to kebab-case everywhere.”

Solche gezielten, begrenzten Iterationen machen plugin-forge deutlich zuverlässiger.

Nutze plugin-forge zusammen mit den Referenzdokumenten, nicht an ihrer Stelle

Der beste Weg, plugin-forge Ergebnisse zu verbessern, ist, den Skill ausdrücklich auf die Repository-Referenzen zu verpflichten. Erwähne in Prompts:

• references/plugin-structure.md für Verzeichniserwartungen
• references/marketplace-schema.md für Marketplace-Felder
• references/workflows.md für Installations- und Testabläufe

So bleibt der Skill an den tatsächlichen Konventionen des Repositories verankert, statt auf generische Plugin-Annahmen zurückzufallen.