OpenClaw Tutorial Teil 5: Skills & Tools erweitern

Ein Skill liegt im Workspace, die Konfiguration ist gültig – und der Agent kennt ihn trotzdem nicht. Das ist kein Prompt-Problem. Entscheidend sind Ladeort, Name, Voraussetzungen und die Frage, ob der konkrete Agent den Skill sehen darf.

Skills beschreiben, wann und wie ein Agent vorhandene Tools für eine Aufgabe nutzt.¹² Ein Tool führt eine konkrete Fähigkeit aus, etwa einen Shell-Befehl oder Web-Abruf. Ein Plugin erweitert die OpenClaw-Runtime und kann dabei Tools oder Skills bereitstellen.³

In diesem Teil legst du einen kleinen, lesenden GitHub-Skill an. Dabei prüfst du jeden Schritt so, dass du nicht auf Verdacht neu startest.

Voraussetzungen prüfen

Du brauchst eine funktionierende OpenClaw-Installation, Zugriff auf den Workspace und einen Agenten mit einem erlaubten Shell-/Exec-Werkzeug. Das GitHub-Beispiel benötigt zusätzlich die GitHub CLI gh und eine gültige GitHub-Anmeldung.

Finde zuerst die aktive Konfigurationsdatei und prüfe, ob sie dem Schema entspricht:⁴

openclaw config file
openclaw config validate

Für die Skills-Einstellungen steht ein geführter Konfigurationsbereich zur Verfügung:

openclaw config --section skills

Eine erfolgreiche Validierung heißt nur: Die Konfiguration ist formal gültig. Ob ein Skill geladen und für deinen Agenten sichtbar ist, prüfst du später mit openclaw skills list.

Welche Skills OpenClaw lädt

OpenClaw sucht Skills in einer festen Reihenfolge. Bei gleichem Skill-Namen gewinnt die weiter oben stehende Quelle.¹

Priorität	Quelle
1	<workspace>/skills
2	<workspace>/.agents/skills
3	~/.agents/skills im Standard-State
4	verwaltete oder lokale Skills im State-Verzeichnis
5	mitgelieferte Skills
6	skills.load.extraDirs sowie Plugin-Skills

Für einen projektspezifischen Skill ist dieser Pfad der Normalfall:

<dein-workspace>/skills/<skill-name>/SKILL.md

Dafür brauchst du keinen Eintrag unter skills.load.extraDirs: Der Workspace-Pfad wird bereits mit der höchsten Priorität durchsucht.¹ extraDirs ist für bewusst zusätzliche Verzeichnisse gedacht und hat die niedrigste Priorität.⁵

Das ist relevant bei Namenskollisionen. Ein Workspace-Skill namens github-issues-watch überdeckt einen gleichnamigen Skill aus einem Plugin oder einem zusätzlichen Verzeichnis.

Erst Vorschlag prüfen, dann anwenden

Wenn aus wiederkehrender Arbeit ein Skill werden soll, bietet OpenClaw mit Skill Workshop einen kontrollierten Weg: Der Agent erstellt einen Vorschlag, aktiv wird er erst nach Prüfung und Apply.⁶

Zeige die offenen Vorschläge an:

openclaw skills workshop list

Prüfe einen Vorschlag mit seiner Kennung:

openclaw skills workshop inspect <proposal-id>

Übernimm ihn erst, wenn Inhalt, verwendete Tools und benötigte Berechtigungen zum vorgesehenen Einsatz passen:

openclaw skills workshop apply <proposal-id>

Ein Workshop-Vorschlag ist damit keine ungeprüfte Änderung am aktiven Skill-Bestand. Für einen kleinen, lokal nachvollziehbaren Skill kannst du die SKILL.md auch direkt schreiben; der folgende Abschnitt zeigt diese unterstützte Variante.²

Sichtbarkeit für einen Agenten festlegen

Ladeort und Sichtbarkeit sind getrennte Dinge. Eine Skill-Allowlist entscheidet, welche Skills ein Agent im Prompt, in der Slash-Command-Auswahl und in seinem Skill-Snapshot sieht.⁵

Die zuständigen Felder sind agents.defaults.skills für den geerbten Standard und skills innerhalb eines Eintrags in agents.list für einen einzelnen Agenten.⁵ agents.list ist eine Liste von Agenten-Einträgen; der Eintrag muss über id zu der Agenten-ID passen, die du tatsächlich nutzt.

{
  agents: {
    defaults: {
      skills: ["github-issues-watch"]
    },
    list: [
      {
        id: "research",
        skills: ["github-issues-watch"]
      },
      {
        id: "locked-down",
        skills: []
      }
    ]
  }
}

Fehlt agents.defaults.skills, beschränkt keine Allowlist die sichtbaren Skills. Ein Agent ohne eigenes skills-Feld übernimmt die Defaults. Sobald du beim Agenten eine nicht leere Liste setzt, ersetzt sie die Defaults vollständig. Mit skills: [] sieht dieser Agent keinen Skill.¹⁵

Nach einer Änderung prüfst du die Konfiguration:

openclaw config get skills
openclaw config validate

Einen lesenden GitHub-Skill erstellen

Wechsle nun in den Workspace, in dem der Skill liegen soll. Ersetze den Platzhalter durch den Pfad deines OpenClaw-Workspace:

cd <dein-workspace>
pwd

pwd muss genau diesen Workspace-Pfad ausgeben. Erst danach beziehen sich die folgenden ./skills-Pfade auf den richtigen Ort.

Prüfe anschließend, ob die GitHub CLI vorhanden und angemeldet ist:⁷

command -v gh
gh auth status

command -v gh muss einen Pfad ausgeben. Bei gh auth status erwartest du eine erfolgreiche Anmeldung. Wenn die Anmeldung fehlt, führt dich dieser Befehl durch den Login:

gh auth login

Lege danach den Skill im bestätigten Workspace an:

mkdir -p ./skills/github-issues-watch

Erstelle ./skills/github-issues-watch/SKILL.md mit diesem Inhalt:

---
name: github-issues-watch
description: Liest offene GitHub-Issues eines Repositorys und fasst sie zusammen.
metadata:
  openclaw:
    requires:
      bins:
        - gh
---

# GitHub Issues Watch

Nutze diesen Skill, wenn nach offenen Issues eines GitHub-Repositorys gefragt wird.

Frage nach einem Repository im Format `owner/repo`, falls es nicht genannt wurde. Prüfe vor dem Abruf mit `gh auth status`, ob die Anmeldung funktioniert.

Nutze für einen lesenden Abruf höchstens fünf offene Issues:

`gh issue list --repo <owner/repo> --state open --limit 5 --json number,title,labels,createdAt,url`

Fasse Nummer, Titel, Labels, Erstellungsdatum und URL zusammen. Führe keine Befehle aus, die Issues, Labels oder Repository-Inhalte verändern. Bei einem Fehler nenne knapp, ob `gh`, die Anmeldung, das Repository, fehlende Rechte oder die Netzwerkverbindung die wahrscheinliche Ursache ist.

Der Block metadata.openclaw.requires.bins sorgt dafür, dass OpenClaw diesen Skill nur lädt, wenn gh verfügbar ist.¹ Prüfe die Datei vor dem nächsten Schritt:

ls -l ./skills/github-issues-watch/SKILL.md
command -v gh
gh auth status

Den Skill laden und testen

Prüfe nun, ob OpenClaw den Skill erkennt:

openclaw skills list

In der Ausgabe muss github-issues-watch erscheinen. Fehlt der Eintrag, prüfe den Ordnernamen, das name-Feld in der Frontmatter und die Ausgabe von command -v gh. Prüfe außerdem die Allowlist des Ziel-Agenten.

Bei einer bestehenden Unterhaltung kann noch ein alter Skill-Snapshot aktiv sein. Starte daher eine frische Session mit /new. Falls du den Gateway neu laden musst, nutze:

openclaw gateway restart

Rufe den Skill anschließend explizit auf:

/skill github-issues-watch

Gib dem Agenten danach ein konkretes Repository, etwa owner/repo. Eine erfolgreiche Ausführung prüft zuerst die GitHub-Anmeldung und liefert höchstens fünf offene Issues mit Nummer, Titel, Labels, Datum und URL. Für einen Test über die CLI kannst du außerdem eine neue Agenten-Anfrage senden:²

openclaw agent --message "Prüfe mit github-issues-watch die offenen Issues von owner/repo."

Ersetze owner/repo durch ein Repository, auf das dein GitHub-Konto zugreifen darf. Die konkrete Issue-Liste verändert sich mit dem Repository. Prüfen kannst du aber den begrenzten, lesenden Abruf und das vorgegebene Ausgabeformat.

Wenn der Skill fehlt oder nicht funktioniert

Erscheint der Skill nicht in openclaw skills list, kontrolliere zuerst mit pwd, ob du ihn im richtigen Workspace angelegt hast. Prüfe danach, ob die Datei exakt SKILL.md heißt und unter ./skills/github-issues-watch/ liegt. Ein fehlendes gh verhindert das Laden ebenfalls; das zeigt command -v gh.

Ein gleichnamiger Skill aus einer höher priorisierten Quelle kann deinen Workspace-Skill überdecken. Wenn der Skill zwar gelistet ist, dem Ziel-Agenten aber fehlt, kontrolliere dessen Allowlist: Eine nicht leere Liste enthält nur die dort genannten Skills. Ein häufiger Stolperstein ist ein Eintrag in agents.list, dessen id nicht zu der Agenten-ID passt, mit der du gerade arbeitest – dann greift weiter der Default aus agents.defaults.skills.

Kann der Skill keine Issues lesen, beginne mit gh auth status. Bei privaten Repositories braucht das angemeldete Konto Zugriff. Gib das Repository als owner/repo an. Wiederhole keinen schreibenden Befehl als Fehlerbehebung – dieser Skill ist auf den lesenden Abruf begrenzt.

Sicherheitsgrenzen richtig einordnen

Die Verbote in einer SKILL.md sind Arbeitsanweisungen für den Agenten. Sie ersetzen keine technische Zugriffskontrolle. Auch eine Skill-Allowlist ist keine Berechtigungsgrenze für Shell-Zugriffe, wenn derselbe Agent weiterhin ein Shell-Tool verwenden darf.¹

Sichere Schreibzugriffe deshalb außerhalb des Skill-Texts ab: mit Sandbox- und Tool-Policy, gezielten Exec-Freigaben, OS-Isolation und Zugangsdaten mit minimalen Rechten.⁸ Für externe Skills oder Plugins gilt derselbe Maßstab. Prüfe bei ClawHub Audit-Status, Risiko, Befunde, benötigte Credentials und die veröffentlichte Version. Ein Audit mit Status Pass ist ein Signal, aber keine Sicherheitsgarantie.⁹

Kernpunkte

Ein Skill ist einsatzbereit, wenn er in openclaw skills list auftaucht, der Ziel-Agent ihn sehen darf und sein Ablauf in einer frischen Session mit den vorgesehenen Rechten funktioniert. Der Ordner allein reicht dafür nicht.

Für die nächsten Schritte helfen dir auch diese Teile der Serie:

• OpenClaw Tutorial Teil 4: Telegram & WhatsApp verbinden
• OpenClaw Modelle konfigurieren – Teil 3: OpenAI, Anthropic, OpenRouter
• OpenClaw Tutorial Teil 6: Workspace einrichten

Footnotes

1. https://docs.openclaw.ai/tools/skills ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. https://docs.openclaw.ai/tools/creating-skills ↩ ↩² ↩³

3. https://docs.openclaw.ai/tools/plugin ↩

4. https://docs.openclaw.ai/cli/config.md ↩

5. https://docs.openclaw.ai/tools/skills-config ↩ ↩² ↩³ ↩⁴

6. https://docs.openclaw.ai/tools/skill-workshop ↩

7. https://cli.github.com/manual/gh_auth_status ↩

8. https://docs.openclaw.ai/gateway/security ↩

9. https://docs.openclaw.ai/clawhub/security-audits ↩