Die meisten Veröffentlichungsfehler sind nicht spektakulär. Sie sind langweilig. Falscher Owner. Fehlende Metadaten. Ein Skill, der eine Env-Var liest, aber eine andere deklariert. Ein Plugin-Paket mit falschem Scope. Und danach wundern sich Leute, warum das Release nicht dort auftaucht, wo es sollte.
Die Kurzfassung: ClawHub Publishing ist eine Validierungsstrecke, kein dummer Datei-Upload. Es prüft, wer du bist, was du hochlädst, ob die Metadaten glaubwürdig sind und ob das Release schon sichtbar sein sollte.
Was der Veröffentlichungsablauf wirklich macht
Die offiziellen ClawHub Publishing Docs beschreiben einen Ablauf, bei dem ClawHub Owner-Zugriff, Paket-Identität, Version, Dateien und Source-Informationen validiert, bevor das Release gespeichert und automatische Sicherheitsprüfungen gestartet werden. Wenn die Validierung scheitert, wird nichts veröffentlicht. Wenn sie gelingt, kann das Release trotzdem noch aus normalen Install-Flächen herausgehalten werden, bis das Review fertig ist.
Genau deshalb fühlt sich Publishing hier weniger nach „Ordner in Dropbox werfen“ an und mehr nach internationalem Paketversand. Etikett, Absender, Inhalt und Papiere müssen zusammenpassen.
Skills und Plugins laufen auf verschiedenen Spuren
Das ist die erste Unterscheidung, die sitzen muss. Ein Skill ist ein Ordner rund um SKILL.md. Ein Plugin ist ein Paket mit plugin-spezifischen Metadaten und Kompatibilitätsfeldern. Gleiche Registry, andere Form.
| Frage | Skills | Plugins |
|---|---|---|
| Hauptweg zur Veröffentlichung | clawhub sync oder clawhub skill publish | clawhub package publish |
| Zentrale Einheit | Ordner mit SKILL.md | Paket plus Plugin-Metadaten |
| Typischer Fehler | Schwache oder ungenaue Skill-Metadaten | Falscher Owner oder Package-Scope |
| Bester erster Sicherheits-Schritt | clawhub sync --dry-run | clawhub package publish <source> --dry-run |
Wenn du diese beiden Spuren vermischst, wird es früh verwirrend und später unnötig teuer.
Die praktische Veröffentlichungs-Reihenfolge
Wenn du sauber arbeiten willst, denk in vier Stufen: anmelden, prüfen, Dry-Run, dann veröffentlichen.
- Anmelden, damit die CLI weiß, unter welchem User- oder Org-Kontext du veröffentlichen darfst.
- Paketform prüfen, bevor du die Registry überhaupt berührst.
- Dry-Run ausführen, um zu sehen, was ClawHub glaubt, dass du gerade veröffentlichen willst.
- Erst dann echt veröffentlichen, wenn die Vorschau langweilig aussieht.
Langweilig ist hier gut. Publishing sollte sich unspektakulär anfühlen, wenn die Metadaten gesund sind.
Skill-Workflow
clawhub login
clawhub sync --dry-run --owner <owner>
clawhub sync --all --owner <owner>Laut Doku scannt sync nach Ordnern mit SKILL.md, vergleicht sie mit ClawHub und veröffentlicht neue oder geänderte Skills, sobald du das Dry-Run-Flag weglässt.
Plugin-Workflow
clawhub package publish <source> --family code-plugin --dry-run
clawhub package publish <source> --family code-pluginGenau diese Vorschau ist wichtiger, als viele denken. Sie lässt dich Kompatibilitätsfelder, Source-Zuordnung und Upload-Plan prüfen, bevor daraus ein echtes Release wird.
Welche Metadaten bei Skills wirklich zählen
Die offiziellen Skill-Format Docs machen eines sehr klar: Die Registry liest nicht nur deinen Fließtext. Sie extrahiert Laufzeit-Erwartungen aus deiner Frontmatter.
description: die Zusammenfassung, die Nutzer in UI und Suche sehenmetadata.openclaw.requires.env: Env-Vars, ohne die der Skill wirklich nicht laufen kannenvVars: reichere Deklarationen pro Variable, auch für optionale Werterequires.binsund Install-Spezifikationen: was auf dem System vorhanden sein musshomepageund unterstützende Dateien: nützlicher Kontext für Vertrauen und Review
Genau hier sabotieren sich viele Einsteiger still selbst. Sie behandeln SKILL.md wie Marketing-Text. ClawHub behandelt es eher wie einen Frachtbrief. Wenn dein Frachtbrief lügt, wird der Rest der Reise unerquicklich.
---
name: my-skill
description: Short summary of what this skill does.
version: 1.0.0
metadata:
openclaw:
requires:
env:
- TODOIST_API_KEY
bins:
- curl
primaryEnv: TODOIST_API_KEY
envVars:
- name: TODOIST_API_KEY
required: true
description: Todoist API token.
---Betrachte diesen Block wie die Zoll-Erklärung deines Skills. Er sagt ClawHub, was drin ist und was der Skill nach der Installation vom System verlangen wird.
Die Plugin-Falle: Owner und Scope müssen zusammenpassen
Plugin-Publishing hat seinen ganz eigenen Klassiker. Package-Scopes sind keine Dekoration. Sie sind Besitzansprüche.
Wenn dein Paket @openclaw/dronzer heißt, brauchst du Publish-Zugriff auf den Owner @openclaw. Wenn du nur einen anderen Owner kontrollierst, musst du das Paket vor dem Publishing umbenennen, damit der Scope passt. ClawHub blockiert Scope-Owner-Mismatch absichtlich.
Das ist ein gutes Schutzgeländer, keine Bürokratie. Ohne diese Regel könnte jeder versuchen, in einen Org-Namespace zu veröffentlichen, den er gar nicht kontrolliert.
Häufige Publishing-Fehler
1. Dry-Run überspringen, weil der Ordner „gut aussieht“
Genau so überleben vermeidbare Probleme bis zum Release-Moment. Dry-Run ist deine billige Generalprobe. Nutze sie.
2. Metadaten deklarieren, die nicht zur Realität passen
Wenn der Skill Env-Vars oder Binaries nutzt, die in der Frontmatter nie auftauchen, wird das Review zäh und das Nutzervertrauen sinkt. Ehrliche Metadaten sind Teil des Produkts, nicht Papierkram nach dem Produkt.
3. Unter dem falschen Owner veröffentlichen
Das passiert oft in Org-Repos. Dass der angemeldete User existiert, heißt noch lange nicht, dass unter dem richtigen Owner-Handle veröffentlicht wird.
4. Vergessen, dass Sichtbarkeit zeitversetzt sein kann
Ein Release kann existieren und trotzdem noch nicht in normalen Install- oder Such-Flächen auftauchen. Das bedeutet nicht automatisch, dass das Publishing gescheitert ist. Es kann schlicht noch durch Prüfungen laufen.
Dry-Run ist nicht optional, wenn du dein zukünftiges Ich magst
Es gibt diese alte Handwerker-Regel: zweimal messen, einmal schneiden. Der ClawHub Dry-Run ist die Registry-Version davon. Nicht glamourös, aber sehr gut darin, private Fehler daran zu hindern, öffentlich zu werden.
Gerade bei Katalog-Repos liefert dir Dry-Run mehr als Beruhigung. Er liefert einen prüfbaren Plan. Teamkollegen können Owner-Wahl, Skill-Pfad und Metadaten also gegenlesen, bevor aus der Theorie eine echte Veröffentlichung wird.
Eine einfache Entscheidungsregel
- Du veröffentlichst einen oder mehrere Skills? Starte mit
clawhub sync --dry-run. - Du veröffentlichst ein Plugin-Paket? Starte mit
clawhub package publish ... --dry-run. - Du bist unsicher, ob die Metadaten stimmen? Kläre das zuerst, bevor du irgendetwas veröffentlichst.
📌 Action Step
→ öffne deinen Skill- oder Plugin-Ordner und prüfe die Metadaten wie ein Auditor, nicht wie ein stolzer Elternteil.
→ führe zuerst den Dry-Run aus und lies die Ausgabe langsam.
→ veröffentliche erst, wenn Owner, Scope, Version und Laufzeit-Anforderungen sauber zusammenpassen.
Need help from people who already use this stuff?
Du willst bald nach ClawHub veröffentlichen?
Bring deine Metadaten und den Dry-Run Output erst in die Community. Fünf Minuten Review sparen dir oft einen sehr öffentlich langweiligen Fehler.
FAQ
Veröffentliche ich Skills und Plugins mit demselben Befehl?
Nein. Skills laufen meist über `clawhub sync` oder `clawhub skill publish`, Plugins über `clawhub package publish`. Beide landen im selben Registry-System, aber die Paketregeln sind unterschiedlich.
Warum sollte ich zuerst einen Dry-Run machen?
Weil dir der Dry-Run den Upload-Plan zeigt, bevor du ein Release erzeugst. So findest du fehlende Metadaten, falsche Owner-Auswahl, schlechte Source-Zuordnung oder Scope-Probleme, solange der Fehler noch billig ist.
Was ist in SKILL.md vor der Veröffentlichung am wichtigsten?
Vor allem ehrliche Metadaten. Beschreibung, benötigte Umgebungsvariablen, Binaries, optionale Env-Vars und Homepage sollten zu dem passen, was der Skill wirklich nutzt. Wenn Deklaration und Verhalten auseinanderlaufen, wird Review mühsam und Vertrauen sinkt.
Was ist der häufigste Plugin-Veröffentlichungsfehler?
Unter dem falschen Owner oder mit falschem Package-Scope zu veröffentlichen. Wenn dein Paket `@openclaw/plugin-name` heißt, brauchst du Publish-Rechte für `@openclaw`, oder du benennst das Paket so um, dass Scope und Owner zusammenpassen.
Kann eine Veröffentlichung erfolgreich sein und trotzdem noch nicht in der Suche auftauchen?
Ja. Laut offizieller Publishing-Doku können neue Releases aus normalen Install- und Download-Flächen noch herausgehalten werden, bis Validierung, Sicherheitsprüfungen oder Review abgeschlossen sind.