devetai/better-plugin-gen

Better Plugin Generator (better-plugin-gen)

Dieses Skill hilft Benutzern, ein Plugin zu erstellen: ein Verzeichnis, das mehrere Komponenten (wie Skills, Agents, Hooks, MCP-Server) bündelt, um sie mit einem Befehl in einen Coding-Agenten zu installieren. Das Skill unterstützt drei Hosts (Agent-Tools, die Plugins laden): Claude Code, Codex, Antigravity. Jeder Host hat sein eigenes Manifest; das Skill verwendet das gemeinsame Verzeichnis skills/ und generiert Manifests für jeden ausgewählten Host.

Alle Pfade wie template.md, references/, examples/, scripts/ beziehen sich auf das Verzeichnis, das diese SKILL.md-Datei enthält.

---

1. Kernprinzipien

1. Erst fragen, dann generieren. Alle Entscheidungen werden dem Benutzer mit strukturierten Abfragen gestellt (sofern der Kontext dies zulässt); andernfalls werden nummerierte Optionen aufgelistet, die empfohlene Option wird hervorgehoben, und es wird auf eine Antwort gewartet. Vor jeder Frage wird kurz erklärt: Was das Plugin tun soll, was die Frage beinhaltet und warum sie gestellt wird. Es werden keine Annahmen getroffen und Dateien generiert, bevor Unklarheiten beseitigt sind.
2. Keine Host-Spezifikationen erraten. Dateipfade, Manifest- und MCP-Formate richten sich nach references/hosts.md. Punkte, die als „nicht verifiziert“ markiert sind, müssen dem Benutzer gemeldet werden.
3. Hauptlogik im Skill. Das Skill ist die einzige Komponente, die auf allen drei Hosts läuft. Agents, Commands, Hooks und LSP werden nur hinzugefügt, wenn der Benutzer sie benötigt und der Host sie unterstützt.
4. Minimal funktionierendes Grundgerüst. Jede erzeugte Komponente muss sofort lauffähig, aber kurz sein. Wenn das Projekt über ein Skill better-skill-gen oder better-agent-gen verfügt, wird dem Benutzer empfohlen, diese zu verwenden, um Skills oder Agents nach der Plugin-Erstellung zu verfeinern.
5. Selbstvalidierung. Das Plugin wird nur übergeben, wenn scripts/validate.sh mit Exit-Code 0 beendet wird.
6. Keine externen Seiteneffekte. Das Skill schreibt nur in das Zielverzeichnis des Plugins (und in die Marketplace-Datei im Repository-Stamm, falls gewählt). Es führt kein git commit, git push aus, installiert keine Plugins und ändert keine Host-Konfigurationen des Benutzers; es gibt lediglich die Befehle zur manuellen Ausführung aus.

---

2. Eingaben

• Erforderlich: Zweck des Plugins (ein Satz genügt) oder der Pfad zu einem vorhandenen Plugin, wenn Komponenten hinzugefügt werden sollen. Wird aus der Benutzeranforderung extrahiert.
• Bei Fehlen nachfragen: Ziel-Host, Verzeichnis, Komponentenliste, Marketplace-Erstellung, Plugin-Name, Autor, Lizenz.
• Fehlende Informationen: Gemäß Abschnitt 3, Schritt 2 abfragen; ohne Antwort wird auf Eingabe gewartet.

---

3. Ablauf

Schritt 1: Modus und aktuellen Zustand bestimmen

• Neuerstellung: Der Benutzer beschreibt das Plugin, es existiert noch kein Verzeichnis.
• Komponente/Hinzufügen eines Hosts: Der Benutzer gibt einen Pfad mit .claude-plugin/plugin.json, .codex-plugin/plugin.json oder plugin.json an. Alle vorhandenen Manifests werden gelesen, die enthaltenen Komponenten aufgelistet, und das Shell-Skript bash scripts/validate.sh <dir> wird ausgeführt, um vorhandene Fehler vor der Bearbeitung zu erkennen.
• Marketplace-Erstellung: Der Benutzer hat bereits ein Plugin und möchte es nur veröffentlichen. Das Plugin wird wie oben gelesen, dann zu Schritt 6 übergegangen.
• references/hosts.md lesen. Wenn das „Verifizierungsdatum“ älter als 30 Tage ist oder das Plugin eine Funktion benötigt, die noch nicht in der Datei enthalten ist: die Quellen in Abschnitt 6 dieser Datei im Web einsehen, die Datei und das Verifizierungsdatum aktualisieren und den Benutzer über die Änderungen informieren.

Schritt 2: Benutzer befragen

Zusammenfassen, was verstanden wurde (was das Plugin tut, wer es nutzt, wann es ausgeführt wird), dann erste Fragerunde; Fragen weglassen, die der Benutzer bereits klar beantwortet hat:

Frage	Typ	Optionen (Empfehlung zuerst)
Auf welchem Host soll das Plugin laufen?	Mehrfachauswahl	Claude Code; Codex; Antigravity. Empfehlung: alle drei, wenn das Plugin nur aus Skill und MCP besteht; nur Claude Code, wenn Hooks, LSP oder userConfig benötigt werden
Wo soll das Plugin abgelegt werden?	Einfachauswahl	Eigenes Repo, Plugin im Stamm (./<name>/); in einem Marketplace-Repo (plugins/<name>/); im aktuellen Projekt zum Testen
Aus welchen Komponenten besteht das Plugin?	Mehrfachauswahl	Skill; Agent; Hook; MCP-Server; Command; LSP; userConfig
Soll ein Marketplace erstellt werden?	Einfachauswahl	Ja, für die ausgewählten Hosts; Nein, nur lokal testen

Zweite Runde (falls nötig): Plugin-Name (Vorschlag in Kebab-Schreibweise aus der Beschreibung), Autor und GitHub-Repository, Lizenz, Details zu jeder Komponente (was macht das Skill? Welche Tools verwendet der Agent? Bei welchem Ereignis läuft der Hook? Welcher MCP-Server wird benötigt, und werden Tokens benötigt?).

Regeln beim Fragen:

• Der Benutzer wählt Hooks zusammen mit einem anderen Host als Claude Code: auf den Konflikt in references/hosts.md Abschnitt 4 hinweisen, fragen, ob der Hook beibehalten werden soll.
• Plugin benötigt Tokens oder Passwörter: nach der Bereitstellungsmethode fragen (Claude Code: userConfig mit sensitive: true; andere Hosts: Umgebungsvariablen in der README dokumentieren). Niemals geheime Werte in Dateien schreiben.
• Name entspricht einem gesperrten Namen von Claude Code (references/hosts.md Abschnitt 2.1): einen anderen Namen vorschlagen.
• Zielverzeichnis enthält bereits Dateien: die zu überschreibenden Dateien auflisten und vor dem Schreiben um Erlaubnis fragen.

Schritt 3: Design festlegen

Eine Zusammenfassung im Chat verfassen: Name, Host, Speicherort, zu erstellende Verzeichnisstruktur (mit Markierung, welcher Host für welche Datei zuständig ist), welche Komponente auf welchem Host läuft, vom Agenten selbst gesetzte Werte, noch nicht verifizierte Punkte. Wenn die Antwort neue Unklarheiten aufwirft, nachfragen; keine Dateien generieren.

Schritt 4: Dateien generieren

1. template.md (Vorlage für jede Datei) und references/components.md (Format jeder Komponente) lesen. examples/sample.md lesen, um den gewünschten Detaillierungsgrad zu verstehen.
2. Manifeste für jeden ausgewählten Host schreiben. name, version, description sind in allen Manifesten identisch.
3. Komponenten im Stammverzeichnis des Plugins ablegen, nicht in .claude-plugin/ oder .codex-plugin/:
   • Skill: skills/<name>/SKILL.md, Frontmatter nur name, description, damit es von jedem Host gelesen werden kann.
   • MCP: .mcp.json für Claude Code, Codex; mcp_config.json für Antigravity (entfernte Server verwenden serverUrl). Beide Dateien enthalten dieselbe Serverliste.
   • Hook: hooks/hooks.json, umschlossen vom Schlüssel "hooks", immer mit matcher, Skriptaufruf mit "${CLAUDE_PLUGIN_ROOT}" (Variable von Claude Code). Skript in scripts/ ablegen, mit Shebang.
   • Agent, Command, LSP, userConfig: gemäß references/components.md.
4. README.md aus Vorlage Datei 8 schreiben, mindestens 40 Wörter, mit einer Tabelle der Komponenten nach Host und Installationsbefehlen pro Host (references/publishing.md Abschnitt 5).
5. Modus „Komponente hinzufügen“: Nur neue Dateien hinzufügen und die entsprechenden Schlüssel in den Manifesten ändern; version (Patch) in allen Manifesten erhöhen, wenn das Plugin bereits veröffentlicht wurde.

Schritt 5: Selbstvalidierung

1. Shell-Befehl ausführen: HOSTS="<ausgewählte Hosts" bash scripts/validate.sh <plugin-oder-repo-verzeichnis>. Beispiel: HOSTS="claude codex antigravity".
2. Das Skript führt check_plugin.py aus (überprüft Manifeste, Namen, Pfade, MCP, Hooks, Skills, Agents, Marketplace, Platzhalter, geheimnisähnliche Zeichenfolgen), dann claude plugin validate und agy plugin validate, falls diese Befehle auf dem System verfügbar sind.
3. Bei [FAIL] oder Fehlermeldungen der CLI: Dateien korrigieren und erneut ausführen, bis Exit-Code 0 erreicht ist.
4. Jede [WARN] lesen: korrigieren, wenn möglich; falls beibehalten (z. B. Warnung vor Multi-Host-Hook, die dem Benutzer bereits mitgeteilt wurde), den Grund im Übergabebericht dokumentieren.
5. Temporäre Dateien im vom Benutzer angegebenen temporären Verzeichnis ablegen, ansonsten im systemweiten temporären Verzeichnis; nach Abschluss der Prüfung sofort löschen.

Schritt 6: Marketplace (falls gewählt)

• Claude Code: .claude-plugin/marketplace.json im Stamm des Repos (Vorlage Datei 9).
• Codex: .agents/plugins/marketplace.json im Stamm des Repos (Vorlage Datei 10).
• Antigravity: keine Datei erforderlich; README enthält den Befehl agy plugin install mit der GitHub-Repo-URL, z. B. https://github.com/phucbui/pr-review-kit.
• Schritt 5 mit dem Stammverzeichnis des Repos erneut ausführen, um auch den Marketplace zu validieren.

Schritt 7: Übergabe

Einen Bericht gemäß der Vorlage „Übergabebericht“ am Ende von template.md ausgeben: Verzeichnis, Host, Validierungsergebnis, Dateitabelle, noch nicht verifizierte Punkte, lokale Testbefehle, Befehle zur Veröffentlichung (die der Benutzer selbst ausführen muss) gemäß references/publishing.md Abschnitte 3 bis 6. Wenn better-skill-gen oder better-agent-gen im Projekt vorhanden sind, einen kurzen Hinweis geben, wie diese zur Verfeinerung der Komponenten verwendet werden können.

---

4. Einschränkungen

• Erforderlich:
  • Vor der Dateierstellung nach Host, Speicherort, Komponenten und Marketplace fragen; keine unklaren Punkte selbstständig entscheiden.
  • Nur in das Plugin-Zielverzeichnis und die Marketplace-Datei im Repository-Stamm schreiben; keine anderen Beispieldateien erstellen. Beispiele befinden sich ausschließlich im examples/-Verzeichnis dieses Skills.
  • Keine git commit, git push, claude plugin install, agy plugin install, codex plugin marketplace add ausführen; nur die Befehle anzeigen.
  • Keine Tokens, Passwörter oder API-Schlüssel in Dateien schreiben.
  • Übergabe nur, wenn scripts/validate.sh mit Exit-Code 0 beendet wird.
• Empfohlen:
  • Plugin-, Skill- und Agent-Namen in Kebab-Schreibweise; erste Version 0.1.0.
  • Plugin auf einen Zweck konzentrieren; bei unzusammenhängenden Anforderungen mehrere Plugins vorschlagen.
  • In der README klar angeben, welche Komponente auf welchem Host läuft.
• Nicht empfohlen:
  • SKILL.md mit für Claude Code spezifischen Feldern nicht in Plugins für Codex oder Antigravity kopieren.
  • Keine absoluten Pfade oder .. in Manifesten, Hooks oder MCP verwenden.
  • Keine CLAUDE.md im Stammverzeichnis des Plugins ablegen; Anweisungen, die geladen werden müssen, in das Skill integrieren.