Skills und Befehle

Wer einen Ablauf immer wieder gleich beschreibt, legt ihn in Claude Code als Skill ab. Ein Skill ist eine Datei SKILL.md mit Anweisungen. Claude benutzt ihn, wenn er zur Aufgabe passt, und man kann ihn selbst mit /name aufrufen (Skill-Doku (externe Seite, code.claude.com)).

Warum ein Verfahren besser in einem Skill steht als in der Projektanweisung, was ein Skill im Kontext kostet und wann ein Hook die bessere Wahl ist, erklärt Vibe-Coding / Agentic Engineering, Kapitel 12 im Pfad zum Vibe Coding. Was beim Start einer Sitzung schon im Fenster liegt, steht in Kapitel 05. Dieses Kapitel zeigt die Mechanik in Claude Code: wie ein Skill aufgebaut ist, wer ihn auslöst, wo er liegt und was beim Aufruf mit seinem Text geschieht.

Ein Skill ist ein Ordner

Jeder Skill liegt in einem eigenen Ordner, und darin steht die Datei SKILL.md. Sie hat zwei Teile. Oben stehen zwischen zwei Zeilen --- die Kopfdaten im Format YAML, die Claude sagen, wann der Skill passt. Darunter folgen die Anweisungen in Markdown, denen Claude beim Aufruf folgt. Ein kleines Beispiel, gespeichert als ~/.claude/skills/aenderungen/SKILL.md:

---
description: Fasst die nicht committeten Änderungen zusammen und nennt Risiken. Passt, wenn jemand fragt, was sich geändert hat.
---

## Aktuelle Änderungen
!`git diff HEAD`

## Auftrag
Fasse die Änderungen oben
in drei Punkten zusammen
und nenne die Risiken.

Der Name des Ordners wird zum Befehl, hier also /aenderungen. Ein Feld name in den Kopfdaten legt einen anderen Befehl fest, und der Name des Ordners ruft den Skill dann weiterhin auf. Die Beschreibung im Feld description hilft Claude bei der Entscheidung, wann es den Skill von selbst lädt. Die Zeile mit dem Ausrufezeichen führt Claude Code vor dem Aufruf aus. Was sie bewirkt, steht weiter unten im Abschnitt über den Aufruf.

Neben SKILL.md darf der Ordner weitere Dateien enthalten: ausführliches Nach­schla­ge­ma­te­rial, Beispiele, Skripte. SKILL.md nennt sie, und Claude öffnet sie erst, wenn es sie braucht. Die Doku rät, SKILL.md selbst kurz zu halten. Mehr als 500 Zeilen sollen es nicht werden.

Der Hinweis im Terminal spricht von Markdown-Dateien in .claude/skills/. Gemeint ist der Aufbau von oben: ein Ordner je Skill und darin die Datei SKILL.md.

Befehle und Skills sind eins

Eigene Befehle gab es lange vor den Skills. Seit Version 0.2.31 vom März 2025 wird jede Markdown-Datei im Ordner .claude/commands/ zu einem Befehl mit Schrägstrich, der ihren Text als Prompt ins Gespräch setzt (Versionsliste (externe Seite, code.claude.com)). Skills kamen mit Version 2.0.20 im Oktober 2025 dazu. Seit Version 2.1.3 vom 09.01.2026 sind beide zusammengelegt. Laut Versionsliste wird die Vorstellung davon dadurch einfacher, und am Verhalten ändert sich nichts.

Die Skill-Doku (externe Seite, code.claude.com) sagt es heute in einem Satz: Eigene Befehle sind in den Skills aufgegangen. Eine Datei .claude/commands/deploy.md und ein Skill unter .claude/skills/deploy/SKILL.md erzeugen beide den Befehl /deploy und arbeiten gleich. Vorhandene Befehlsdateien laufen weiter.

Die Befehlsdatei ist das ältere Format. Sie kennt dieselben Kopfdaten bis auf name und paths. Ein Skill bringt dazu einen Ordner für Begleitdateien mit, und für neue Arbeit rät die Doku deshalb zum Skill. Liegen ein Skill und eine Befehlsdatei mit demselben Namen nebeneinander, läuft laut der Tabelle zu gleichen Namen in der Skill-Doku (externe Seite, code.claude.com) der Skill.

Wer einen Skill auslöst

In der Voreinstellung können beide einen Skill auslösen, der Mensch und Claude (Skill-Doku (externe Seite, code.claude.com)).

Der Mensch tippt /name am Anfang einer Nachricht. Was dahinter steht, bekommt der Skill als Argument, etwa die Nummer eines Vorgangs bei /fix-issue 123. Claude Code setzt den Skill dann sofort ein.

Claude ruft einen Skill über das Werkzeug Skill auf, sobald die Beschreibung zur Aufgabe passt. Die Werkzeugreferenz (externe Seite, code.claude.com) führt es als Werkzeug, das einen Skill im Hauptgespräch ausführt. Dieser Weg ist älter als die Skills selbst. Seit Version 1.0.123 vom 23.09.2025 konnte Claude eigene Befehle über ein Werkzeug namens SlashCommand aufrufen (Versionsliste (externe Seite, code.claude.com)). Seit Version 2.1.108 vom 14.04.2026 findet Claude über das Werkzeug Skill auch einige eingebaute Befehle, etwa /init und /security-review.

Ein Name mitten im Satz liegt dazwischen. Steht /name nach anderem Text als eigenes Wort ohne angehängtes Satzzeichen, läuft nichts sofort. Der Name gilt dann als Erlaubnis für diese eine Nachricht: Claude darf den Skill beim Antworten aufrufen und entscheidet nach dem Wortlaut, ob man das wollte. Wer über einen Skill schreiben will, ohne ihn freizugeben, lässt den Schrägstrich weg.

Zwei Felder in den Kopfdaten engen die Voreinstellung ein:

• Ohne diese Felder rufen Mensch und Claude den Skill auf, und die Beschreibung steht immer im Kontext.
• disable-model-invocation: true: Nur der Mensch ruft ihn auf, die Beschreibung steht nicht im Kontext.
• user-invocable: false: Nur Claude ruft ihn auf, die Beschreibung steht immer im Kontext.

Wofür welche Einstellung gedacht ist, zeigt Vibe-Coding / Agentic Engineering, Kapitel 12 auf der zweiten Ebene. Versucht Claude trotz Sperre, einen Skill aufzurufen, hält Claude Code den Aufruf an. Claude bekommt die Anweisung, die Schritte des Skills nicht auf anderem Weg nachzubauen, und schlägt stattdessen vor, dass man ihn selbst startet.

Wo Claude Code Skills findet

Der Speicherort entscheidet, welche Sitzungen einen Skill laden.

• Organisation. Pfad: .claude/skills/<name>/SKILL.md im Ordner der verwalteten Einstellungen. Lädt in: Sitzungen aller Nutzer auf Rechnern, an die die Organisation ihn verteilt.
• Persönlich. Pfad: ~/.claude/skills/<name>/SKILL.md. Lädt in: allen eigenen Projekten auf diesem Rechner.
• Projekt. Pfad: .claude/skills/<name>/SKILL.md. Lädt in: Sitzungen in diesem Repository, nach dem Commit auch beim Team.
• Verschachtelt. Pfad: <unterordner>/.claude/skills/<name>/SKILL.md. Lädt in: Sitzungen, die dort oder darunter starten, sonst sobald Claude dort Dateien bearbeitet.
• Plugin. Pfad: <plugin>/skills/<name>/SKILL.md. Lädt überall, wo das Plugin eingeschaltet ist.
• Konto bei claude.ai. Die im Konto eingeschalteten Skills. Lädt in: Cowork, Cloud-Sitzungen und Sitzungen im Terminal mit diesem Konto.

Haben Skills an mehreren dieser Orte denselben Namen, gewinnt die Organisation vor dem persönlichen Skill und der persönliche vor dem des Projekts. Ein eigener Skill ersetzt auch einen mitgelieferten Skill gleichen Namens, dessen Aliasse aber nicht. Ein Skill code-review im Projekt übernimmt also /code-review, und der Alias /review startet den eigenen Skill nie. Einen eingebauten Befehl gleichen Namens ersetzt ein eigener Skill nur in einer Sitzung im Terminal auf dem eigenen Rechner, und auch dort bleiben die Aliasse beim eingebauten Befehl. Vor Skills aus Plugins steht der Name des Plugins als Vorsilbe, etwa /mein-plugin:review, und sie laufen deshalb neben allen anderen. Wie Plugins Skills verteilen, steht in Kapitel 19.

Eine Grenze betrifft Cowork und die Cloud. Cowork und Cloud-Sitzungen, auch Routines, lesen den Ordner ~/.claude/skills/ auf dem eigenen Rechner nicht. Wer einen persönlichen Skill dort braucht, schaltet ihn im Konto bei claude.ai ein. Für Cloud-Sitzungen reicht es auch, ihn ins Repository zu committen. Was eine Cloud-Sitzung sonst mitnimmt, steht in Kapitel 30.

Mitgelieferte Skills

Claude Code bringt eigene Skills mit, darunter /doctor, /code-review, /batch, /debug, /loop und /claude-api. Sie geben Claude ausführliche Anweisungen und lassen es die Arbeit mit seinen Werkzeugen erledigen. Die meisten eingebauten Befehle führen festen Programmcode aus, etwa /clear oder /model. In der Befehlsübersicht (externe Seite, code.claude.com) sind die mitgelieferten Skills als Skill markiert. Sie arbeiten wie selbst geschriebene: ein Prompt, den Claude bekommt.

Manche davon ruft Claude von selbst auf, wenn sie passen. Andere laufen nur auf Befehl, etwa /verify. So bestimmt man selbst, wann solche längeren Prüfungen Zeit und Token kosten. /code-review erklärt Kapitel 25, /loop Kapitel 28, /doctor Kapitel 02. Den Skill für Programme mit der Claude API beschreibt die zweite Ebene. Wer die mitgelieferten Skills nicht will, schaltet sie mit der Einstellung disableBundledSkills ab.

Was beim Aufruf geschieht

Beim Start einer Sitzung legt Claude Code von jedem Skill, den Claude selbst aufrufen darf, nur Name und Beschreibung in den Kontext. Der ganze Text kommt erst beim Aufruf, und vorher bereitet Claude Code ihn auf.

Drei Dinge passieren dabei. Erstens ersetzt Claude Code Platzhalter wie $ARGUMENTS durch das, was hinter dem Befehl stand. Zweitens führt es Befehle in der Schreibweise !`befehl` aus und setzt deren Ausgabe an ihre Stelle, bevor Claude den Text sieht. Im Beispiel oben bekommt Claude so den aktuellen Diff gleich mit. Drittens geht der fertige Text als eine einzige Nachricht ins Gespräch und bleibt dort in den folgenden Runden stehen.

Die Datei selbst liest Claude Code danach nicht noch einmal. Eine Anweisung, die für die ganze Aufgabe gelten soll, formuliert man deshalb als stehende Regel, etwa „Führe nach jeder Änderung die Tests aus“. Ein Satz wie „Führe die Tests aus“ liest sich als einzelner Schritt.

Ein Skill kann auch in einem eigenen Subagent laufen. Dann bekommt der Subagent den fertigen Text als Auftrag, sieht den bisherigen Verlauf nicht und meldet am Ende ein Ergebnis zurück. Wie das eingestellt wird, steht auf der zweiten Ebene. Was ein Subagent ist, erklärt Kapitel 20.

Wann sich ein Skill lohnt

Ein Skill passt für alles, was man sonst immer wieder in den Chat kopiert: eine Checkliste, ein Vorgehen in mehreren Schritten, Nachschlagewissen zu einem Teil des Projekts. Die ausführliche Abwägung gegen Hook und Projektanweisung steht in Vibe-Coding / Agentic Engineering, Kapitel 12. Kurz gefasst sprechen vier Fälle für einen anderen Weg:

• Eine Regel muss jedes Mal gelten. Ein Skill ist Text, dem Claude folgt. Für eine Regel ohne Ausnahme ist ein Hook der verlässlichere Ort.
• Eine Tatsache gilt immer. Namen, Befehle zum Bauen und der Aufbau des Projekts gehören in die CLAUDE.md, weil sie bei jeder Zeile mitwirken. Was dort hineingehört, steht in Vibe-Coding / Agentic Engineering, Kapitel 03.
• Ein Teilauftrag erzeugt viel Zwischenstand. Dafür ist ein Subagent gedacht, der nur das Ergebnis zurückgibt.
• Ein Werkzeug fehlt. Den Zugang zu einem Dienst bringt ein MCP-Server. Ein Skill kann danach beschreiben, wie man ihn gut benutzt.

Außerhalb von Claude Code gibt es dieselbe Abwägung mit anderen Mitteln, von Prompt und Suche bis zum Training. Die Wege stehen nebeneinander in Nutzung und Anpassung von LLMs, Kapitel 08.

Wer einen Skill mit anderen teilen will, committet ihn ins Repository oder verpackt ihn als Plugin. Die zweite Ebene zeigt die Felder der Kopfdaten im Einzelnen, Argumente, Shell-Ausgaben, Rechte und Einstellungen. Die dritte erzählt, wie aus Befehlen Skills wurden, und stellt Claude Code neben den offenen Standard, Codex und das Agent SDK.

Die erste Ebene hat gezeigt, wie ein Skill aussieht und wer ihn auslöst. Diese Ebene geht die Felder der Kopfdaten durch. Sie zeigt, was Claude Code beim Aufruf mit dem Text macht, wie ein Skill in einem eigenen Subagent läuft und welche Rechte er bekommt. Danach geht es um Einstellungen, ums Neuladen und um die Orte, an denen Skills erst später auftauchen. Zum Schluss steht der mitgelieferte Skill für Programme mit der Claude API.

Die Felder der Kopfdaten

Alle Felder sind freiwillig. Empfohlen ist nur die Beschreibung, damit Claude weiß, wann der Skill passt (Skill-Doku (externe Seite, code.claude.com)). Die Namen müssen genau stimmen, samt Bindestrich. Ein unbekanntes Feld übergeht Claude Code ohne Fehlermeldung. Ein Tippfehler in disable-model-invocation lässt den Skill also für Claude offen, und niemand merkt es.

• name: Name im Menü und Befehl; sonst gilt der Name des Ordners
• description: was der Skill tut und wann er passt
• when_to_use: weitere Auslöser, etwa typische Sätze; wird an die Beschreibung angehängt
• argument-hint: Hinweis beim Vervollständigen, etwa [issue-number]
• arguments: Namen für die Argumente, dann als $name im Text nutzbar
• disable-model-invocation: Claude ruft den Skill nicht von selbst auf
• user-invocable: mit false nur Claude, der Skill fehlt im Menü
• allowed-tools: Werkzeuge ohne Rückfrage, nur in der Antwort, die den Skill aufruft
• disallowed-tools: Werkzeuge, die Claude solange gar nicht bekommt
• model, effort: Modell und Effort, solange der Skill aktiv ist
• context, agent, background: Lauf in einem eigenen Subagent
• hooks: Hooks, die ab dem Aufruf bis zum Ende der Sitzung gelten
• paths: Dateimuster; Claude lädt den Skill dann nur bei passenden Dateien
• shell: bash oder powershell für eingebettete Befehle

Beschreibung und when_to_use kürzt Claude Code im Verzeichnis der Skills zusammen auf 1.536 Zeichen. Der wichtigste Anwendungsfall gehört deshalb an den Anfang. Was dieses Verzeichnis im Kontext kostet und wann es Beschreibungen ganz streicht, steht in Vibe-Coding / Agentic Engineering, Kapitel 12 auf der dritten Ebene.

Ja und Nein darf man seit Version 2.1.218 auch als yes, no, on, off, 1 und 0 schreiben. Vorher galten nur true und false. Was die Hooks im Kopf eines Skills können, zeigt Kapitel 18 auf der zweiten Ebene. Wann ein Skill mit paths lädt, folgt demselben Muster wie Regeln mit Pfadangabe. Diese Regeln erklärt das Kapitel Kapitel 14.

Argumente übergeben

Was hinter dem Befehl steht, landet im Platzhalter $ARGUMENTS. Einzelne Argumente holt man mit $ARGUMENTS[0] oder kürzer mit $0, $1 und so weiter; die Kurzform gibt es seit Version 2.1.19 vom 23.01.2026 (Versionsliste (externe Seite, code.claude.com)). Mehrere Wörter, die ein Argument bilden sollen, stehen in Anführungszeichen wie in der Shell.

---
name: uebertragen
description: Überträgt eine Komponente in eine andere Sprache
argument-hint: "[komponente] [von] [nach]"
---
Übertrage die Komponente $0 von $1 nach $2.
Verhalten und Tests bleiben unverändert.

/uebertragen SearchBar JavaScript TypeScript setzt die drei Wörter in die drei Platzhalter ein. Nimmt kein Platzhalter im Text die Eingabe auf, hängt Claude Code sie als Zeile ARGUMENTS: ans Ende, damit Claude sie trotzdem sieht.

Am Prompt im Terminal lassen sich mehrere Skills am Anfang einer Nachricht stapeln, etwa /tests-schreiben /fix-issue 123. Claude Code lädt beide und gibt jedem den Rest als Argument. Über das Agent SDK und claude -p lädt Claude Code nur den ersten Skill, der Rest der Zeile wird sein Argument. Bis zu sechs Skills gehen so hintereinander. Ein Skill, der in einem eigenen Subagent läuft, beendet die Reihe. Bei /code-review ist das so: Der Befehl und alles danach werden zum Argument der Skills davor.

Shell-Ausgaben und Dateien einbinden

Seit Version 1.0.30 vom 24.06.2025 können eigene Befehle die Ausgabe von Shell-Befehlen einbinden, Dateien mit @ anhängen und über Schlüsselwörter mehr Nachdenken anfordern (Versionsliste (externe Seite, code.claude.com)). In einem Skill gilt das bis heute. Eine Zeile !`git status` führt Claude Code vor dem Aufruf aus und setzt die Ausgabe an ihre Stelle. Für mehrere Zeilen gibt es einen Codeblock mit ! direkt hinter den öffnenden Backticks. Eine Datei, die der Text mit @ nennt, hängt Claude Code bei einem Skill auf dem eigenen Rechner an. Steht ultrathink irgendwo im Text, denkt Claude bei diesem Skill gründlicher nach.

Scheitert ein eingebetteter Befehl, scheitert der ganze Aufruf. Claude sieht den Text des Skills dann gar nicht. In der Voreinstellung mit bash zählt jeder Rückgabewert außer 0 als Fehlschlag. Eine Ausnahme gilt für Such- und Vergleichsbefehle: Bei ihnen nimmt Claude Code den Rückgabewert 1 als gewöhnliches Ergebnis und setzt die Ausgabe ein. Ein Prüfskript, das bei Befunden mit 1 endet, bekommt deshalb ein || true angehängt.

Eingebettete Befehle fragen nie nach. Claude Code prüft jeden vorher gegen die Rechteregeln. Trifft eine Sperrregel, bricht der Aufruf ab. Außerhalb des Auto-Modus gilt das auch für alles, was keine ausdrückliche Erlaubnis hat, sogar für eine Regel, die sonst nachfragen würde. Im Auto-Modus bricht ein solcher Befehl den Aufruf nicht ab. Der Skill lädt dann mit der Anweisung an Claude, den Befehl zuerst selbst auszuführen, und dieser Aufruf geht durch die üblichen Prüfungen des Modus. Zwei Ausnahmen gelten auch im Auto-Modus: Ein Skill mit eigenem Subagent, der das Feld agent setzt, bricht weiter ab, ebenso eine Sitzung, in der Claude das Shell-Werkzeug für eingebettete Befehle fehlt. Wie Rechteregeln und Auto-Modus arbeiten, steht im Kapitel Kapitel 16.

Wer keine Shell-Befehle in Skills will, setzt seit Version 2.1.91 die Einstellung disableSkillShellExecution. Sie gilt für Skills und Befehle von Nutzer, Projekt, Plugins und zusätzlichen Verzeichnissen. Mitgelieferte Skills und die der Organisation laufen weiter. Am meisten bringt die Einstellung in den verwalteten Einstellungen, die niemand überschreiben kann.

Für Pfade gibt es zwei Variablen. ${CLAUDE_SKILL_DIR} ist der Ordner des Skills selbst, seit Version 2.1.69. ${CLAUDE_PROJECT_DIR} ist der Ordner des Projekts. Steht dieselbe Variable im Text und in allowed-tools, führt Claude ein mitgeliefertes Skript ohne Rückfrage aus.

Ein Skill im eigenen Subagent

Seit Version 2.1.0 vom 07.01.2026 kann ein Skill in einem eigenen Subagent laufen (Versionsliste (externe Seite, code.claude.com)). Dafür steht context: fork in den Kopfdaten. Claude Code startet dann einen neuen Subagent der Art, die das Feld agent nennt, und gibt ihm den Text des Skills als Auftrag (Skill-Doku (externe Seite, code.claude.com)). Ohne Angabe ist das der allgemeine Subagent general-purpose. Möglich sind auch Explore, Plan und jeder eigene Subagent aus .claude/agents/.

---
name: recherche
description: Untersucht ein Thema im Code gründlich
context: fork
agent: Explore
---
Untersuche $ARGUMENTS gründlich:
1. Passende Dateien mit Glob und Grep finden
2. Den Code lesen
3. Ergebnisse mit Dateiangaben zusammenfassen

Der Subagent sieht den bisherigen Verlauf nicht. Der Text muss also für sich stehen, und das lohnt nur bei einem ausdrücklichen Auftrag. Ein Skill mit bloßen Leitlinien liefert im Subagent nichts Brauchbares. Explore und Plan lassen außerdem die CLAUDE.md und den Git-Status weg, damit ihr Kontext klein bleibt. Der Name fork täuscht: Ein Fork des Gesprächs nähme den Verlauf mit. Was ein echter Fork ist, erklärt Kapitel 20.

Seit Version 2.1.218 vom 22.07.2026 laufen solche Skills im Hintergrund. Man arbeitet weiter, und das Ergebnis kommt ins Gespräch, sobald der Subagent fertig ist. Mit background: false wartet Claude in der Antwort, die den Skill aufruft, auf das Ergebnis. Das lohnt aus zwei Gründen. Im Hintergrund bekommt der Subagent nur die schmalere Werkzeugliste, die für Hintergrund-Subagents gilt. Und seine Änderungen an Dateien liegen außerhalb der Checkpoints der Sitzung. /rewind stellt danach nur die Dateien wieder her, die Claude im Gespräch schon bearbeitet hatte. Was der Skill an anderen Dateien geändert hat, bleibt stehen und lässt sich mit Git zurücknehmen. Im nicht interaktiven Lauf mit -p, im Agent SDK und in einer geplanten Aufgabe wartet Claude Code ohnehin auf das Ergebnis.

Die umgekehrte Richtung gibt es auch: Ein Subagent kann Skills vorladen, über das Feld skills in seiner Definition. Das beschreibt Kapitel 20 auf der zweiten Ebene.

Modell und Effort je Skill

Das Feld model wechselt das Modell für den Rest der laufenden Antwort. In die Einstellungen schreibt Claude Code das nicht, und mit der nächsten Eingabe gilt wieder das Modell der Sitzung. Ein Modell, das die Organisation nicht erlaubt oder das der Auto-Modus nicht unterstützt, übergeht Claude Code. Läuft der Skill in einem Subagent, gilt das Modell für diesen.

Das Feld effort gibt es seit Version 2.1.80 vom 19.03.2026. Es überschreibt die Stufe der Sitzung, solange der Skill aktiv ist. Welche Stufen es gibt und wie eine Organisation eine Obergrenze zieht, steht in Kapitel 06. Der Text eines Skills kann die aktuelle Stufe seit Version 2.1.120 als ${CLAUDE_EFFORT} lesen und sich danach richten.

Beide Felder hatten Lücken. Vor Version 2.1.259 vom 02.09.2026 übersah Claude Code das Feld model in interaktiven Sitzungen. Vor Version 2.1.267 vom 09.09.2026 blieb effort bei Modellen wirkungslos, deren Standardstufe fest eingestellt ist, etwa Opus 4.8. Wer mit einer älteren Fassung arbeitet, verlässt sich auf keines der beiden Felder.

Rechte für einen Skill

allowed-tools erlaubt die genannten Werkzeuge für die Antwort, die den Skill aufruft. Claude fragt dann nicht nach. Mit der nächsten Nachricht erlischt die Erlaubnis, auch wenn der Text des Skills im Kontext bleibt. Das Feld beschränkt nichts: Alle anderen Werkzeuge bleiben aufrufbar, und für sie gelten die gewohnten Regeln. Zum Wegnehmen gibt es seit Version 2.1.152 disallowed-tools.

---
name: commit
description: Stellt die aktuellen Änderungen bereit und committet sie
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

Hier liegt eine Stelle, die man kennen muss. Das Vertrauen in einen Ordner, das Claude Code beim ersten Start dort abfragt, gilt für dieses Feld nicht. Ein Skill aus einem fremden Repository kann sich also selbst weite Rechte geben, auch in einem Lauf mit -p. Die Doku rät, die allowed-tools der eingecheckten Skills zu lesen, bevor man Claude Code dort startet. Eine Organisation kann das abstellen. Setzt sie allowManagedPermissionRulesOnly, übergeht Claude Code ab Version 2.1.282 die allowed-tools von Skills aus Projekt und Nutzerordner. /status zeigt dann, bei welchen Skills das geschah.

Den Aufruf selbst regeln Rechteregeln für das Werkzeug Skill. Skill(name) trifft genau einen Skill, Skill(name *) jeden Aufruf mit Argumenten. Eine Sperre auf Skill ohne Klammer nimmt Claude alle Skills. Skills ohne eigene Rechte und ohne Hooks laufen seit Version 2.1.19 ohne Rückfrage. Wo solche Regeln stehen und wie sie mit den Modi zusammenspielen, zeigt Kapitel 16.

Skills ausblenden und abschalten

Nicht jeder Skill liegt in einer Datei, die man ändern will, etwa einer aus dem Repository des Teams. Dafür gibt es die Einstellung skillOverrides. Sie steuert die Sichtbarkeit aus den Einstellungen heraus. Je Skill gibt es vier Zustände:

Das Menü /skills schreibt den Wert selbst. Man wählt einen Skill, schaltet mit der Leertaste durch die Zustände und speichert mit Esc in .claude/settings.local.json. Die Einstellung wirkt seit Version 2.1.129 vom 06.05.2026. Für Skills aus Plugins gilt sie nicht, die verwaltet man über /plugin.

Drei Schalter wirken auf ganze Gruppen. disableBundledSkills nimmt seit Version 2.1.169 die mitgelieferten Skills und Workflows weg und verbirgt die eingebauten Befehle vor dem Modell. syncClaudeAiSkills beendet den Abgleich mit dem Konto bei claude.ai, mehr dazu unten. Und eine Organisation kann Skills über strictPluginOnlyCustomization auf Plugins und verwaltete Quellen beschränken; dann laden Skills aus Nutzer- und Projektordner nicht mehr (Ein­stel­lungs­re­fe­renz (externe Seite, code.claude.com)). Wie verwaltete Einstellungen wirken, steht in Kapitel 15.

Skills ändern und neu laden

Seit Version 2.1.0 wirken neue und geänderte Skills sofort, ohne Neustart. Claude Code beobachtet dafür die Ordner unter ~/.claude/skills/, im Projekt und in zusätzlichen Verzeichnissen. Das gilt nur für den Text in SKILL.md. Hooks, Server und Subagents eines Skill-Ordners, der zugleich ein Plugin ist, brauchen /reload-plugins.

Einen Ordner, den es beim Start noch nicht gab, beobachtet Claude Code nicht. Für diesen Fall gibt es seit Version 2.1.152 vom 27.05.2026 den Befehl /reload-skills. Er durchsucht die Ordner neu und muss nach jeder weiteren Änderung dort erneut laufen. Ein Hook beim Start der Sitzung kann dasselbe auslösen, wenn er selbst Skills installiert.

Zum Aufräumen gibt es zwei Werkzeuge. /skill-doctor zeigt, was jeder Skill kostet und wie oft er benutzt wird. In der Versionsliste steht der Befehl unter 2.1.261 vom 04.09.2026. Die Doku nennt als Mindestfassung 2.1.252 und schränkt ein: Sitzungen, die keine Funktionsschalter von Anthropic abrufen, haben ihn nicht. Das betrifft etwa Amazon Bedrock. Wer genauer zählen will, schaltet die Telemetrie über OpenTelemetry ein. Das Ereignis skill_activated hält dann jeden Aufruf fest und sagt, ob ihn ein Befehl, Claude oder ein anderer Skill auslöste (Leitfaden für große Codebasen (externe Seite, code.claude.com)). Das zweite Werkzeug zum Aufräumen ist claude plugin validate .claude/skills. Es findet seit Version 2.1.233 jede SKILL.md, deren Kopfdaten sich nicht lesen lassen. Ein solcher Skill lädt sonst mit leeren Kopfdaten. Mit /name lässt er sich weiter aufrufen. Von selbst kann Claude ihn ohne Beschreibung keiner Aufgabe zuordnen.

Skills in Monorepos und Unterordnern

Claude Code lädt Skills aus .claude/skills/ im Startordner und in jedem Ordner darüber bis zur Wurzel des Repositorys. Wer in packages/frontend/ startet, hat also auch die Skills der Wurzel.

Skills in Ordnern unterhalb des Startordners laden beim Start nicht. Sie kommen, sobald Claude zum ersten Mal eine Datei in diesem Ordner liest oder bearbeitet, und bleiben dann für die Sitzung. Bis dahin fehlen sie im Menü und lassen sich nicht beim Namen aufrufen. /add-dir mit dem Pfad des Unterordners lädt sie früher, ab Version 2.1.257. Heißen zwei Skills gleich, einer an der Wurzel und einer in apps/web/, bleiben seit Version 2.1.178 beide erreichbar: /deploy startet den an der Wurzel, /apps/web:deploy den anderen. Claude bekommt die Anweisung, den zu nehmen, dessen Ordner die bearbeiteten Dateien enthält.

Ein Ordner, den man mit --add-dir dazunimmt, bringt seine Skills, Befehle und Subagents mit. Die Einstellung permissions.additionalDirectories gibt dagegen nur Zugriff auf Dateien und lädt nichts davon. Der Leitfaden für große Codebasen (externe Seite, code.claude.com) rät deshalb zu Skills je Paket oder Teilsystem. Arbeitet Claude in packages/api/, lädt es die Skills von dort, in packages/web/ die von dort. Wer an der Wurzel startet, sammelt dagegen die Skills aller Unterordner ein, die Claude in der Sitzung berührt, und das können Hunderte werden. Skills, die viele Pakete brauchen, gehören an die Wurzel des Repositorys.

Skills aus dem Konto bei claude.ai

Wer sich im Terminal mit einem Konto bei claude.ai anmeldet, bekommt die dort eingeschalteten Skills auch in Claude Code. Die Doku nennt dafür Version 2.1.273, die Versionsliste führt es unter 2.1.275 vom 17.09.2026. Dazu gehören eigene Skills, die der Organisation und die von Anthropic, etwa für PDF und Excel. Claude Code lädt sie beim Start im Hintergrund nach ~/.claude/skills/synced/. Das geschieht nur in einer Sitzung, die sich mit dem Konto anmeldet und die Funktionsschalter von Anthropic abruft. Mit API-Schlüssel, über Amazon Bedrock, im schlanken Modus und mit --safe-mode gibt es keinen Abgleich.

Der Weg geht nur in eine Richtung. Eine Änderung an einer Datei unter synced/ erreicht das Konto nicht, und ein späterer Abgleich kann sie überschreiben oder entfernen. Geändert wird auf claude.ai. Weil diese Skills von außen kommen, behandelt Claude Code sie seit Version 2.1.228 vorsichtiger: Auf dem eigenen Rechner laufen ihre Shell-Befehle nicht, und Dateien mit @ hängt es nicht an. Hat ein anderer Befehl denselben kurzen Namen, läuft der synchronisierte Skill nur unter /anthropic-skills:<name>. Abschalten lässt sich der Abgleich mit syncClaudeAiSkills auf false.

Der Skill für die Claude API

Wer Programme mit der Claude API schreibt, bekommt seit Version 2.1.69 vom 05.03.2026 einen eigenen Skill dafür (Versionsliste (externe Seite, code.claude.com)). /claude-api lädt Nach­schla­ge­ma­te­rial zur Claude API und zu Managed Agents in der Sprache des Projekts. Claude holt ihn auch von selbst, sobald der Code das SDK von Anthropic einbindet.

Das Material ist groß, und das hatte Folgen. Vor Version 2.1.234 vom 17.08.2026 kostete der Skill beim Laden über 200.000 Token Kontext. Seither sind es etwa 25.000, weil er die Nach­schla­ge­do­ku­mente erst bei Bedarf öffnet. Das ist die Bauregel aus der ersten Ebene im Großen: Ein schlankes SKILL.md, und das Material liegt in Begleitdateien.

Hinter dem Namen stehen Unterbefehle für einzelne Abläufe, laut Doku jeweils mit eigener Mindestfassung:

• migrate hebt vorhandenen Code auf ein neueres Modell.
• upgrade hebt das Python-Paket von Anthropic über eine Hauptversion, ab 2.1.236.
• prompt-audit sucht in Prompts, Skills und Werk­zeug­be­schrei­bungen nach Anweisungen für ältere Modelle, ab 2.1.221.
• cost-optimize zeigt, wohin die Ausgaben für die API gehen, und schlägt Einsparungen vor, ab 2.1.247.
• build-eval und hillclimb bauen eine Sammlung von Testfällen und verbessern eine Anwendung schrittweise daran, ab 2.1.259.

Ein Skill ist eine Datei mit Text, und doch hat sich um diese Datei in anderthalb Jahren viel Mechanik gelegt. Diese Ebene zeigt zuerst, wie aus den eigenen Befehlen Skills wurden. Danach geht es um den offenen Standard hinter dem Format und um Skills in Codex und im Agent SDK. Zum Schluss stehen die Stellen, an denen die Mechanik aufhört.

Wie aus Befehlen Skills wurden

Die Tabelle zeigt die Schritte mit Datum und Fassung aus der Versionsliste (externe Seite, code.claude.com). Für Fassung 0.2.31 führt die Versionsliste nur ein Sammeldatum. Hier steht deshalb das Datum der Veröffentlichung im npm-Verzeichnis, markiert mit „npm“.

Der Wendepunkt ist Version 2.0.20 vom 16.10.2025. Bis dahin war ein eigener Befehl ein gespeicherter Prompt in einer einzelnen Datei, und erst seit 1.0.123 durfte Claude ihn selbst aufrufen. Die Ankündigung der Skills (externe Seite, claude.com) beschrieb Ordner mit Anweisungen, Skripten und Material, die Claude bei Bedarf lädt. Und sie galten von Anfang an über Claude Code hinaus, im selben Format in den Apps von Claude und in der API.

Die Zusammenlegung in 2.1.3 zog daraus drei Monate später die Folge für Claude Code: ein Modell für beides, die alte Befehlsdatei als Sonderfall. Die Felder der Kopfdaten gelten seither für beide Formen, bis auf name und paths. Die Ankündigung nannte schon damals die Kehrseite: Ein Skill gibt Claude die Möglichkeit, Code auszuführen.

Wie die Grenze für Beschreibungen wanderte

Damit Claude einen Skill von selbst findet, steht seine Beschreibung in jeder Runde im Kontext. Wie viel Platz das Verzeichnis dafür bekommt, hat sich dreimal geändert:

• 2.1.32, 05.02.2026: Der Platz wächst mit dem Kontextfenster, damals mit 2 Prozent.
• 2.1.86, 27.03.2026: Jede Beschreibung wird auf 250 Zeichen gekürzt.
• 2.1.105, 13.04.2026: Die Grenze steigt auf 1.536 Zeichen, und beim Start erscheint eine Warnung, wenn Beschreibungen gekürzt werden.

Die Skill-Doku (externe Seite, code.claude.com) nennt am 12.10.2026 für das Verzeichnis 1 Prozent des Fensters. Wann der Anteil von 2 auf 1 Prozent sank, sagt die Versionsliste nicht. Beide Zahlen lassen sich einstellen: der Anteil über skillListingBudgetFraction, die Länge je Skill über skillListingMaxDescChars. Was passiert, wenn das Verzeichnis überläuft, und welche Skills zuerst ihre Beschreibung verlieren, steht in Vibe-Coding / Agentic Engineering, Kapitel 12 auf der dritten Ebene.

Ein offener Standard

Am 18.12.2025 hat Anthropic das Format als offenen Standard veröffentlicht, gedacht für den Austausch über Werkzeuge hinweg (Beitrag zu Agent Skills (externe Seite, anthropic.com)). Die Seite des Standards (externe Seite, agentskills.io) beschreibt einen Skill im Kern als Ordner mit einer Datei SKILL.md. Das Format sei als offener Standard freigegeben und von einer wachsenden Zahl von Agenten übernommen worden. Auch der Ablauf ist dort festgehalten: Beim Start liest ein Agent nur Name und Beschreibung jedes Skills, gerade genug, um zu wissen, wann er passen könnte.

Claude Code geht über den Standard hinaus, etwa mit der Steuerung, wer aufruft, mit dem eigenen Subagent und mit eingebetteten Shell-Befehlen. Das hat eine praktische Folge. Außerhalb von Claude Code gelten nur die Felder des Standards. Für ein Hochladen nach claude.ai, die Skills-API und das Packen mit dem Werkzeug von Anthropic sind das sechs: name, description, license, compatibility, metadata und allowed-tools. Jedes andere Feld lässt das Hochladen mit einem Fehler scheitern. Eingebettete Shell-Befehle wirken dort ebenfalls nicht.

Wer einen persönlichen Skill im Konto bei claude.ai einschaltet, etwa für Cowork, Cloud-Sitzungen oder Routines, lädt ihn dorthin hoch. Wer ihn dafür schreibt, bleibt bei den sechs Feldern. Mit einem disable-model-invocation oder einem argument-hint scheitert das Hochladen.

Skills bei Codex

OpenAI benutzt dasselbe Format für ChatGPT und Codex (OpenAI-Doku zu Skills (externe Seite, learn.chatgpt.com)). Auch dort ist ein Skill ein Ordner mit SKILL.md, dazu Skripte und Material nach Bedarf. Die Unterschiede liegen in der Einrichtung:

• Ordner im Repository. Claude Code: .claude/skills/. Codex: .agents/skills/.
• Pflichtfelder. Claude Code: keines, empfohlen ist description. Codex: name und description.
• Aufruf von Hand. Claude Code: /name. Codex: /skills oder $name.
• Selbstaufruf verbieten. Claude Code: disable-model-invocation in SKILL.md. Codex: allow_implicit_invocation in agents/openai.yaml.
• Platz für das Verzeichnis. Claude Code: 1 Prozent des Fensters. Codex: 2 Prozent des Fensters.
• Gleicher Name an zwei Orten. Claude Code: Einer gewinnt nach Rang (Organisation, persönlich, Projekt). Codex: Beide erscheinen.

Codex sucht im Repository wie Claude Code vom Startordner aufwärts bis zur Wurzel. Von Hand ruft man einen Skill über /skills oder mit einem $ vor dem Namen auf. Zwei gleichnamige Skills führt Codex nicht zusammen, beide stehen zur Wahl.

Codex löst manches großzügiger. Das Verzeichnis darf doppelt so viel Platz belegen wie bei Claude Code. Und es nennt zu jedem Skill den Pfad der Datei.

Ein weiterer Unterschied betrifft den Standard. Codex hält die Regel, ob ein Skill von selbst laufen darf, in einer eigenen Datei neben SKILL.md. SKILL.md bleibt damit beim Standard. In Claude Code steht dieselbe Regel in SKILL.md und verhindert, wie oben beschrieben, das Hochladen nach claude.ai. Claude Code bietet dafür mehr Felder in der Datei selbst: Argumente, eingebettete Shell-Befehle, ein eigener Subagent, Modell und Effort.

Skills im Agent SDK

Wer mit dem Agent SDK eigene Agenten baut, bekommt dieselben Skills. Auch dort liegt jeder Skill als SKILL.md in einem eigenen Ordner (SDK-Doku zu Skills (externe Seite, code.claude.com)). Einen Weg, Skills im Programm anzulegen, gibt es nicht. Subagents dagegen lassen sich im Programm definieren. Das SDK findet die Skills in denselben Ordnern wie das Terminal, sofern die Quellen für Einstellungen Nutzer und Projekt einschließen.

Welche Skills Claude aufrufen darf, legt die Option skills fest: eine Liste von Namen, alle oder keiner. Die Liste steuert, was das Modell sieht. Nicht genannte Skills sieht Claude nicht, und das Werkzeug Skill weist sie ab. Ihre Dateien bleiben aber über Lesen und Shell erreichbar. Auch ein Befehl mit /name im Prompt läuft unabhängig von der Liste. Wer einem Agenten einen Skill wirklich vorenthalten will, legt ihn gar nicht erst in einen Ordner, den der Agent erreicht.

Einen unbekannten Befehl reicht das SDK seit Version 2.1.274 als gewöhnliche Nachricht weiter: Claude bekommt den Prompt mit dem Hinweis, dass der Befehl nicht lief. Ein vertippter Name kostet also eine Antwort des Modells. Wie das SDK sonst arbeitet, steht in Kapitel 29.

Wo die Mechanik aufhört

Ein Skill ist eine Bitte. Claude folgt seinem Text, so gut es kann. Eine Regel, die jedes Mal gelten muss, gehört in einen Hook, der unabhängig davon läuft, ob Claude dem Skill gerade folgt. Den Unterschied erklärt Vibe-Coding / Agentic Engineering, Kapitel 12, die Hooks selbst Kapitel 18.

Ein fremder Skill ist fremder Code. Ein Skill kann Skripte mitbringen, Shell-Befehle einbetten und sich über allowed-tools Rechte geben. Für dieses Feld gilt das Vertrauen in den Ordner nicht, das Claude Code beim ersten Start abfragt. Anthropic rät, Skills nur aus ver­trau­ens­wür­digen Quellen zu installieren. Ein bösartiger Skill könne Claude dazu bringen, Daten abfließen zu lassen oder Ungewolltes zu tun. Für Skills aus Plugins gilt dasselbe, siehe Kapitel 19 auf der dritten Ebene.

Wer einen mitgelieferten Skill auslöst, kann sich mit der Fassung ändern. Mit Version 2.1.215 vom 19.07.2026 hörte Claude auf, /verify und /code-review von selbst zu starten. Für /code-review gilt das heute wieder umgekehrt: Laut Doku zum Review (externe Seite, code.claude.com) kann Claude ihn von selbst starten, wenn man in eigenen Worten um einen Review bittet. Vor Version 2.1.246 hing das an einem Funktionsschalter von Anthropic. Wer sich darauf verlassen will, legt es selbst fest, mit skillOverrides oder mit einer Rechteregel.

Ein Name kann eine Wirkung haben. Seit Version 2.1.286 gilt eine Regel für einen eigenen Skill namens verify. Die Doku zu Skills nennt heute dazu auch simplify. Liegt einer beim Start der Sitzung bereit, sagen die Anweisungen von Claude Code zum Commit, Claude solle ihn direkt vor jedem Commit aufrufen. Ausgenommen sind Änderungen nur an Doku oder Tests. Das gilt für Skills aus Organisation, Nutzerordner, Projekt und zusätzlichen Verzeichnissen und für eine Befehlsdatei dieses Namens. Claude muss den Skill außerdem aufrufen dürfen, und die Einstellung includeGitInstructions darf nicht abgeschaltet sein. Einen Skill, der zufällig so heißt, soll Claude also künftig vor jedem Commit aufrufen.

Versionsangaben weichen ab. An drei Stellen nennen Doku und Versionsliste verschiedene Fassungen:

• /skill-doctor: 2.1.252 in der Doku, 2.1.261 in der Versionsliste
• /claude-api upgrade: 2.1.236 in der Doku, 2.1.239 in der Versionsliste
• Abgleich mit dem Konto bei claude.ai: 2.1.273 in der Doku, 2.1.275 in der Versionsliste

Wer eine Mindestfassung braucht, nimmt die höhere Zahl.

Offen bleibt, wie zuverlässig der Selbstaufruf ist. Die Doku beschreibt Werkzeuge, um es zu messen. Eine Trefferquote nennt sie nicht. Eine kleine Zählung aus einem echten Aufbau steht in Vibe-Coding / Agentic Engineering, Kapitel 12: Dort kam ein Skill öfter, wenn der Auftrag die Sache beim Namen nannte.