Wenn du Claude Code im Alltag nutzt, kennst du das: Bestimmte Anweisungen tippst du immer wieder. „Halte dich an unseren Commit-Stil“, „schreibe Tests nach diesem Muster“, „formatiere die API-Response so“. Genau hier kommen Claude Code Skills ins Spiel. Ein Skill bündelt eine wiederverwendbare Fähigkeit, die Claude bei Bedarf automatisch lädt, ohne dass du sie jedes Mal neu erklären musst. In diesem Artikel zeige ich dir, was Claude Code Skills genau sind, wie das clevere Prinzip der Progressive Disclosure dahinter funktioniert, wie sie sich von Slash-Commands, Subagenten, Plugins und MCP unterscheiden und wie du in wenigen Minuten deinen ersten eigenen Skill baust.
Das Wichtigste in Kürze
- Ein Skill ist eine wiederverwendbare Anleitung in einer
SKILL.md, die Claude automatisch lädt, wenn sie zur Aufgabe passt. - Dank Progressive Disclosure kostet ein Skill im Ruhezustand nur rund 80 Tokens – dein Kontextfenster bleibt schlank.
- Skills sind das Know-how, MCP die Leitung, Slash-Commands manuelle Abkürzungen, Subagenten eigenständige Worker und Plugins die Verpackung.
- Du baust einen Skill mit einem Ordner und einer Markdown-Datei – verwalten und prüfen geht über /skills.
- Die
descriptionim Frontmatter entscheidet über alles: Sie ist das einzige Signal, an dem Claude erkennt, ob ein Skill zur Aufgabe passt. - Seit Dezember 2025 ist das Format ein offener Standard und läuft auch in Cursor, Codex CLI, GitHub Copilot und über 20 weiteren Tools.

Was sind Skills in Claude Code?
Ein Skill ist im Kern eine Anleitung in Textform, die in einer SKILL.md liegt. Diese Datei beschreibt, was die Fähigkeit kann, wann sie zum Einsatz kommt und welche Schritte Claude befolgen soll. Optional kannst du Skripte, Templates oder weitere Dateien dazulegen, auf die der Skill zugreift.
Manche nennen Skills „Plugins auf Anweisungsbasis“ – und das trifft es ziemlich gut. Es gibt keine Binärdateien, keine Installationsroutine, kein Kompilieren. Es ist strukturiertes Markdown. Wenn du eine Datei schreiben kannst, kannst du einen Skill bauen.
Das Clevere daran: Claude lädt einen Skill nicht stur bei jeder Anfrage, sondern erst, wenn er für die aktuelle Aufgabe relevant ist. In der SKILL.md beschreibst du im Frontmatter, wofür der Skill gut ist, und Claude entscheidet selbst, ob er ihn heranzieht. So bleibt dein Kontextfenster schlank, und trotzdem hast du eine wachsende Bibliothek an spezialisiertem Wissen parat. Egal ob du mit Opus 5, Sonnet 5 oder Haiku 4.5 arbeitest, das Prinzip bleibt identisch.
Du kannst dir einen Skill wie ein Rezept vorstellen: Es liegt im Regal, und sobald gekocht werden soll, greift Claude danach. Das macht Skills zum idealen Werkzeug für wiederkehrende, klar umrissene Aufgaben.
Anthropic hat das Feature im Oktober 2025 vorgestellt – ursprünglich als kleine Verbesserung für einzelne Aufgaben gedacht. Die Idee schlug aber so ein, dass Skills inzwischen über Claudes komplettes Ökosystem hinweg funktionieren: in Claude Code, in der Web-App auf claude.ai und über die API. Du baust einen Skill also einmal und nutzt ihn überall. Das Schöne: Du brauchst dafür nicht mehr als einen Ordner und eine Markdown-Datei.
Warum Skills mehr sind als ein Textschnipsel
Ein Skill löst gleich vier Probleme auf einmal – und deswegen lohnt sich der kleine Aufwand:
- Wiederverwendbarkeit: Du erklärst eine Sache genau einmal, nicht bei jedem neuen Chat.
- Kontextökonomie: Der Skill schläft, bis er gebraucht wird. Dazu gleich mehr.
- Teamstandardisierung: Liegt der Ordner
.claude/skills/im Git-Repo, arbeitet dein ganzes Team nach denselben Regeln. Ohne Wiki, ohne Onboarding-Call. - Kompositionsfähigkeit: Ein Skill kann Skripte ausführen, MCP-Tools ansprechen, einen Subagenten starten oder auf andere Skills verweisen. Er ist der Dirigent, nicht nur die Notiz.

Progressive Disclosure: warum Skills dein Kontextfenster nicht zumüllen
Klingt ein Skill für dich erst mal wie „noch mehr Text, den Claude lesen muss“? Das muss aber gar nicht sein! Genau hier steckt der eigentliche Geniestreich: ein Mechanismus namens Progressive Disclosure (zu Deutsch etwa „schrittweise Offenlegung“).
Die Grundidee ist einfach. Claude lädt nicht den kompletten Skill-Inhalt in den Kontext, sondern arbeitet sich in drei Stufen vor – und zwar nur so tief, wie es die Aufgabe wirklich verlangt. Laut dem offiziellen Agent-Skills-Standard läuft das so ab:
- Discovery (Entdecken): Beim Start liest Claude nur den Namen und die Beschreibung jedes Skills. Gerade genug, um zu wissen, dass es ihn überhaupt gibt. Das ist quasi dein Inhaltsverzeichnis.
- Activation (Aktivieren): Passt eine Aufgabe zur Beschreibung, lädt Claude die vollständige SKILL.md nach – und behält sie für den Rest der Session im Kontext.
- Execution (Ausführen): Erst wenn ein Detail gebraucht wird, greift Claude auf zusätzliche Dateien zu oder führt ein hinterlegtes Skript aus.
Warum ist das so wichtig? Weil dein Kontextfenster endlich ist – und je voller es ist, desto schlechter die Antworten. In der Discovery-Phase kostet ein Skill nur eine Handvoll Tokens. Messungen an Anthropics offiziellen Skills zeigen einen Median von rund 80 Tokens pro Skill – ein Bruchteil dessen, was die komplette Anleitung verbrauchen würde. Du kannst also Dutzende Skills bereithalten, ohne dass Claude träge oder teuer wird. Der volle Inhalt landet nur dann im Kontext, wenn er gebraucht wird.
Genau das ist der Unterschied zu einer riesigen CLAUDE.md, die immer komplett mitläuft. Skills sind wie ein gut sortiertes Regal: Claude sieht die Etiketten, greift aber nur nach dem Buch, das er gerade braucht.
Die 30-Prozent-Regel: CLAUDE.md oder Skill?
Die Frage kommt garantiert: Was gehört jetzt wohin? Dafür gibt es eine einfache Faustregel.
Ist ein Wissen in mehr als 30 Prozent deiner Anfragen relevant – etwa der Tech-Stack, die Ordnerstruktur, die grundsätzlichen Projektregeln – gehört es in die CLAUDE.md. Alles, was seltener gebraucht wird, aber dann richtig, gehört in einen Skill.
Denn ein Skill, den Claude in jedem zweiten Satz nachladen muss, ist Mehraufwand. Und eine CLAUDE.md, die alles Wissen der Welt enthält, ist Ballast in jeder einzelnen Anfrage. Die 30-Prozent-Regel hilft dir, beides sauber zu trennen.

Claude Code Skills vs. Slash-Commands, Subagenten, Plugins und MCP
Bei den ganzen Begriffen kann man schnell den Überblick verlieren. Klingt ganz schön kompliziert? Ist es nicht. Die Konzepte ergänzen sich, lösen aber unterschiedliche Probleme. Hier die wichtigsten im Vergleich:
- Skills sind Wissen und Anleitungen. Sie sagen Claude wie etwas gemacht wird. Ein Skill startet keinen eigenen Prozess, sondern wird in den laufenden Kontext geladen.
- Slash-Commands sind manuelle Shortcuts. Du tippst
/befehlund löst eine feste Vorlage aus. Sie werden nie automatisch erkannt und eignen sich für ganz einfache, immer gleiche Handgriffe. - Subagenten sind eigenständige Helfer mit eigenem Kontextfenster. Sie übernehmen abgegrenzte Teilaufgaben (etwa eine Recherche oder ein Code-Review) und liefern dir nur die Zusammenfassung zurück. Subagenten delegieren Arbeit, Skills beschreiben Arbeit. Übrigens: Ein Subagent kann keine weiteren Subagenten starten.
- Plugins sind das Verpackungsformat. Ein Plugin kann mehrere Skills, Subagenten, Slash-Commands und Hooks bündeln und über einen Marketplace teilbar machen. Wenn du dein Setup mit anderen teilen willst, ist ein Plugin der Weg.
- MCP (Model Context Protocol) ist die Anbindung an die Außenwelt. Darüber greift Claude auf echte Tools, Datenbanken und APIs zu – etwa GitHub, eine Postgres-Datenbank oder den Browser.
Ein schönes Bild dafür: MCP ist die Leitung, Skills sind das Handbuch. MCP liefert die Daten und den Zugang, der Skill liefert das Know-how, wie man damit umgeht. Anthropic selbst zieht denselben Vergleich zwischen Skills und MCP. Ein Skill kann ein MCP-Tool nutzen – umgekehrt geht das nicht.
Ein Unterschied, den viele unterschätzen: Ein MCP-Server lädt seinen kompletten Tool-Katalog sofort in den Kontext, sobald er verbunden ist. Ein Skill nicht. Deshalb ist es fast nie eine gute Idee, für eine reine Anweisungssache einen MCP-Server aufzusetzen. Das wäre, wie mit Kanonen auf Spatzen zu schießen.
Kurz gesagt: Ein Skill ist die kleinste Einheit, Slash-Commands sind manuelle Abkürzungen, Subagenten sind eigenständige Worker, Plugins sind die Distributionsschicht drumherum, und MCP ist die Brücke zu externen Systemen. Die meisten Profi-Setups kombinieren am Ende mehrere davon. Aber keine Sorge: Für den Anfang reicht ein einziger Skill völlig.
Der Entscheidungsbaum: Was nehme ich wann?
Damit du nicht lange grübeln musst, hier meine Kurzfassung. Geh die Fragen einfach von oben nach unten durch:
- Brauchst du eine externe API oder Datenbank? Dann führt kein Weg an MCP vorbei.
- Willst du selbst auslösen, wann etwas passiert? Bei einem Einzeiler reicht ein Slash-Command. Bei allem Größeren nimmst du einen Skill und schaltest den automatischen Aufruf ab.
- Soll es automatisch laufen und produziert viel Output? Ab damit in einen Subagenten mit isoliertem Kontext.
- Soll es automatisch laufen und bleibt schlank? Klassischer Fall für einen Skill.
- Willst du es teamweit verteilen? Pack alles in ein Plugin.

Skills nutzen und verwalten mit /skills
Den zentralen Überblick bekommst du über den Slash-Command /skills. Tippst du /skills in Claude Code, siehst du, welche Skills aktuell verfügbar sind und kannst sie verwalten. Das ist dein Startpunkt, um zu prüfen, was Claude gerade zur Verfügung steht.
Du musst einen Skill in der Regel nicht manuell aufrufen. Claude erkennt anhand der Beschreibung, wann ein Skill passt, und zieht ihn automatisch heran. Wenn du also einen Skill für „Conventional Commits“ angelegt hast und Claude einen Commit erstellen soll, lädt er die passende Anleitung von selbst. Über /skills kannst du diesen Bestand jederzeit einsehen.
Kleine Randnotiz für alle, die schon länger dabei sind: Skills und Slash-Commands laufen intern inzwischen über dasselbe Werkzeug. Ein Slash-Command ist technisch gesehen nur noch ein Skill, den du von Hand aufrufst. Für dich als Nutzer ändert das wenig – es macht die Sache aber deutlich logischer.
Wo Skills liegen können
Claude schaut an mehreren Orten nach – und das ergibt eine klare Rangordnung, von persönlich bis teamweit. Liegt derselbe Skill an zwei Orten, gewinnt der speziellere:
- Persönlich: unter
~/.claude/skills/<name>/. Diese Skills stehen dir in jedem Projekt zur Verfügung. - Projekt-spezifisch: unter
.claude/skills/<name>/direkt im Repo. Commitest du den Ordner, hat jeder im Team automatisch dieselben Skills. - Über Plugins: als geteiltes Paket aus einem Marketplace, sauber unter eigenem Namensraum.
- Organisationsweit: in den Team- und Enterprise-Plänen können Admins Skills zentral verwalten und an alle ausrollen.
Arbeitest du in einem Monorepo, ist das inzwischen auch kein Problem mehr: Verschachtelte .claude/skills/-Ordner in den einzelnen Paketen werden automatisch erkannt. Jedes Teilprojekt bringt also seine eigenen Regeln mit.
Fertige Skills installieren
Du musst nicht bei null anfangen. Anthropic pflegt ein offizielles Skills-Repository auf GitHub, das du als Marketplace einbinden kannst. Zwei Befehle reichen:
# 1. Offizielles Repo als Marketplace hinzufügen
/plugin marketplace add anthropics/skills
# 2. Dokumenten-Skills installieren (PDF, Excel, Word, PPTX)
/plugin install document-skills@anthropic-agent-skills
Danach kann Claude zum Beispiel Excel-Reports mit Formeln bauen, Word-Dokumente erzeugen oder PDFs auslesen – ganz ohne dass du ihm das jedes Mal erklärst. Praktischer Bonus: Änderungen an einer SKILL.md wirken sofort, ein Neustart ist nicht nötig. Du kannst die Datei also offen lassen, feilen, testen, feilen – alles in einer Session.
Sicherheits-Tipp: Ein Skill ist ausführbarer Text und kann Skripte enthalten. Installier deshalb nur Skills aus Quellen, denen du vertraust, und wirf vorher einen Blick in die SKILL.md. Bei offiziellen Anthropic-Skills bist du auf der sicheren Seite, bei zufälligen GitHub-Funden lohnt sich ein prüfender Blick.

Einen eigenen Skill bauen
Jetzt wird’s praktisch. Ein Skill lebt in einem eigenen Ordner mit einer SKILL.md als Herzstück. So sieht eine minimale Struktur aus:
.claude/
skills/
conventional-commits/
SKILL.md
examples.md (optional)
Sobald dein Skill wächst, kannst du ihn sauber aufteilen. Eine ausgereiftere Struktur sieht typischerweise so aus:
mein-skill/
├── SKILL.md # Pflicht: Frontmatter + Anleitung
├── scripts/ # optional: ausführbare Skripte
├── references/ # optional: Details, die nur bei Bedarf geladen werden
├── templates/ # optional: Vorlagen
└── assets/ # optional: Bilder, Beispieldateien
Wichtig ist nur: Die SKILL.md muss direkt im Skill-Ordner liegen, nicht in einem Unterordner.
Die SKILL.md beginnt mit einem kurzen Info-Block ganz oben (in der Fachsprache „Frontmatter“ genannt). Darin stehen ein Name und eine Beschreibung – darunter folgt die eigentliche Anleitung in einfachem Text. Genau über die Beschreibung entscheidet Claude, wann der Skill geladen wird, also formuliere sie konkret.
---
name: conventional-commits
description: Schreibt Commit-Messages im Conventional-Commits-Stil.
Nutze diesen Skill, wenn ein Git-Commit erstellt werden soll.
---
# Conventional Commits
Wenn du einen Commit erstellst, halte dich an dieses Format:
<type>(<scope>): <kurze Beschreibung>
## Erlaubte Types
- feat: neue Funktion
- fix: Bugfix
- docs: nur Dokumentation
- refactor: Code-Umbau ohne Verhaltensänderung
- test: Tests hinzufügen oder anpassen
## Regeln
- Beschreibung im Imperativ, klein, ohne Punkt am Ende.
- Maximal 72 Zeichen in der ersten Zeile.
- Body nur bei nicht-trivialen Änderungen.
Mehr braucht es für den Start nicht. Lege den Ordner an, speichere die SKILL.md, prüfe mit /skills, ob der Skill auftaucht, und ab dann nutzt Claude ihn automatisch.
Die wichtigsten Frontmatter-Felder
Zwei Felder sind Pflicht, der Rest ist Kür. Hier die, die du wirklich kennen solltest:
- name (Pflicht): der eindeutige Name. Maximal 64 Zeichen, nur Kleinbuchstaben, Zahlen und Bindestriche – und keine reservierten Wörter wie „claude“ oder „anthropic“. Wichtig: Er muss exakt dem Ordnernamen entsprechen, sonst lädt der Skill schlicht nicht.
- description (Pflicht): der wichtigste Trigger überhaupt. Sie darf bis zu 1.024 Zeichen lang sein und sollte klar sagen, was der Skill tut und wann Claude ihn nutzen soll.
- disable-model-invocation: verhindert den automatischen Aufruf. Sinnvoll bei riskanten Aktionen wie einem Deploy, die du lieber manuell auslöst.
- allowed-tools / disallowed-tools: legen fest, welche Werkzeuge der Skill nutzen darf. Gut für die Sicherheit.
- context: fork: lässt den Skill in einem isolierten Subagenten laufen. Perfekt für alles, was viel Output produziert und deinen Hauptkontext nicht vollmüllen soll.
- effort und model: steuern, wie gründlich Claude arbeitet und mit welchem Modell. Ein Review darf ruhig teuer sein, ein Formatierer nicht.
- paths: bindet den Skill über ein Glob-Muster an bestimmte Dateien. Der Test-Skill greift dann nur, wenn wirklich Tests im Spiel sind.
Dazu kommen noch Feinheiten wie user-invocable (versteckt den Skill im Menü), argument-hint oder hooks. Aber ganz ehrlich: Für 90 Prozent aller Fälle reichen name und description. Fang damit an und ergänze später.
Dynamischer Kontext statt starrer Anweisungen
Ein netter Trick für Fortgeschrittene: Mit der !-Syntax kannst du in der SKILL.md sogar Befehle ausführen und deren Ausgabe direkt einbauen. !`git diff HEAD` injiziert zum Beispiel die aktuellen Änderungen, bevor Claude sie zusammenfasst. So bekommt dein Skill dynamischen Kontext, statt nur statischer Anweisungen.
Dazu gibt es ein paar Variablen, die dir das Leben leichter machen: $ARGUMENTS nimmt auf, was du beim Aufruf mitgibst. ${CLAUDE_SKILL_DIR} zeigt auf den Ordner des Skills selbst – praktisch, wenn du ein Skript oder Template daraus starten willst. Und ${CLAUDE_PROJECT_DIR} zeigt auf die Projektwurzel. Damit funktionieren deine Pfade zuverlässig, egal aus welchem Unterordner heraus du arbeitest.
Wie groß darf das Ganze werden?
Halte die Teile klein, dann bleibt der Skill zuverlässig. Als Richtwerte haben sich bewährt: die SKILL.md bei maximal 500 Zeilen, einzelne Referenzdateien bei rund 200 Zeilen, Skripte bei etwa 300 und Templates bei 100. Alles darüber ist ein Zeichen, dass du eigentlich zwei Skills brauchst.

Nützliche Skill-Beispiele
Skills lohnen sich übrigens nicht nur fürs Programmieren, sondern für jede wiederkehrende Aufgabe. Ein paar praxiserprobte Ideen:
- Dein Schreibstil: wie ein Blogartikel oder Newsletter bei dir aufgebaut ist (Tonalität, Struktur, Länge), damit Entwürfe sofort passen.
- Standard-Dokumente: dein Format für Angebote, Rechnungen oder E-Mail-Antworten an Kunden.
- Commit-Regeln (für Entwickler): wie oben gezeigt, plus ein Muster für aussagekräftige Beschreibungen von Code-Änderungen.
- Test-Vorgaben (für Entwickler): wie deine Tests aufgebaut sein sollen und welche Fälle immer geprüft werden.
- Onboarding-Schritte: ein Skill, der die Schritte zum Aufsetzen eines Projekts kennt und neue Mitstreiter durchführt.
- Deploy-Checkliste: alles, was vor einem Release passieren muss – am besten mit
disable-model-invocation, damit sie nur läuft, wenn du es sagst.
Faustregel: Alles, was du mehr als zweimal erklärst, ist ein Kandidat für einen Skill.
Damit das nicht abstrakt bleibt, hier ein Beispiel, das für alle spannend ist, die mit WordPress arbeiten. Ich selbst hab damit die besten Erfahrungen gemacht: ein kleiner Blog-Formatter, der jeden Rohtext automatisch in eine saubere, SEO-freundliche Struktur bringt.
---
name: blog-formatter
description: Formatiert Blog-Artikel für WordPress. Optimiert Struktur,
SEO, Lesbarkeit und Heading-Hierarchie. Nutzen bei "Formatiere diesen
Blogpost" oder "Mache das WordPress-tauglich".
---
# WordPress Blog Formatter
## Aufgabe
Nimm den bereitgestellten Text und liefere eine optimierte Version zurück.
## Regeln
1. Struktur: H2/H3 logisch gegliedert, niemals ein zweites H1 im Body.
2. SEO: Keyword in den ersten 100 Wörtern, Meta-Description-Vorschlag am Ende.
3. Lesbarkeit: kurze Absätze, Aufzählungen wo sinnvoll, Fettung für Schlüsselbegriffe.
4. Sprache: aktiv, direkte Ansprache, sauberes Deutsch.
5. Am Ende: Alt-Text-Vorschläge für Bilder und Ideen für interne Verlinkung.
Einmal angelegt, formatiert Claude ab sofort jeden Entwurf nach genau diesem Muster. Du tippst die Regeln nie wieder ab.
Skills, die andere schon für dich gebaut haben
Die Community ist hier verdammt fleißig. In den Verzeichnissen findest du inzwischen Tausende fertiger Skills, und Anthropic selbst hat eine Reihe seiner eigenen als Open Source auf GitHub veröffentlicht. Ein paar Klassiker, die immer wieder auftauchen:
- test-driven-development: zwingt Claude, erst den Test zu schreiben und dann den Code.
- code-reviewer: läuft meist mit
context: forkin einem eigenen Fenster und liefert nur das Ergebnis zurück. - systematic-debugging: statt wildem Raten ein sauberer Ablauf: reproduzieren, eingrenzen, Hypothese, Fix.
- security-scan: prüft Code gegen typische OWASP-Schwachstellen.
- commit-writer: baut die Commit-Message direkt aus dem gestagten Diff.
Ein besonders beliebter Vertreter ist das offizielle frontend-design-Plugin. Sein einziger Job: verhindern, dass deine Oberflächen aussehen wie von der KI zusammengeklickt – also kein Standard-Inter, kein lila Farbverlauf, keine austauschbaren Karten. Installiert wird es mit einem Befehl:
/plugin install frontend-design@anthropics/claude-code
Und weil Skills sich mit MCP kombinieren lassen, kannst du so ein Design-Skill direkt mit einem WordPress- oder Shop-Server koppeln. Der Skill sagt, wie es aussehen soll, der MCP-Server bringt es dorthin, wo es hingehört.
Skills teilen: vom Git-Ordner bis zum eigenen Plugin
Der einfachste Weg, einen Skill zu teilen, ist auch der unspektakulärste: Du legst ihn unter .claude/skills/ ab und commitest ihn. Wer das Repo klont, hat den Skill sofort dabei. Kein Setup, keine Anleitung, keine Rückfragen. Gerade im Team ist das Gold wert, weil dein Standard damit im selben Ordner lebt wie der Code, für den er gilt.
Willst du weiter gehen, baust du ein Plugin. Das ist im Grunde ein Verzeichnis, das Skills, Subagenten, Hooks und MCP-Konfigurationen bündelt – zusammengehalten von einer plugin.json. Der Vorteil: Du bekommst Versionierung und einen eigenen Namensraum, sodass Aufrufe wie /mein-plugin:review eindeutig bleiben.
Verteilen kannst du das Ganze über einen Marketplace – entweder den offiziellen Community-Marketplace oder dein eigenes Git-Repo. Zum Testen musst du gar nichts veröffentlichen:
# Marketplace hinzufügen
/plugin marketplace add anthropics/claude-plugins-community
# Lokal testen, ohne irgendwas zu veröffentlichen
claude --plugin-dir ./mein-plugin
Mit /reload-plugins ziehst du Änderungen rein, ohne Claude Code neu zu starten. So kannst du dein Plugin in Ruhe entwickeln und erst dann teilen, wenn es wirklich sitzt.

Best Practices für Claude Code Skills
Wenn du dir nur eine Sache aus diesem Artikel mitnimmst, dann diese:
Die description macht rund 90 Prozent der Wirkung aus. Sie ist das einzige Signal, an dem Claude erkennt, ob ein Skill zur Aufgabe passt.
Ein „Wann nutzen“-Abschnitt im Body zählt dafür nicht – den liest Claude ja erst, wenn der Skill schon geladen ist. Klingt banal, ist aber der häufigste Grund, warum Skills einfach nie anspringen.
Eine Formel, die zuverlässig funktioniert:
[Verb] + [Ziel] + [Standard]. Use when [Bedingung].
Also nicht „Hilft bei Commits“, sondern „Erstellt Commit-Messages nach Conventional Commits. Nutzen, wenn ein Git-Commit erstellt oder eine Message umformuliert wird.“ Schreib in der dritten Person, nenne die Auslöser beim Namen und bleib bei ein bis drei Sätzen. Und ein Tipp aus der Praxis: Trigger-Wörter funktionieren auf Englisch oft besser, auch wenn der Rest deutsch ist.
Der Rest ist schnell erzählt:
- Eine Fähigkeit pro Skill. Ein Skill, der zehn Dinge gleichzeitig kann, wird selten zuverlässig geladen. Halte den Fokus eng.
- Halte die SKILL.md kurz. Anthropic empfiehlt als Richtwert rund 500 Zeilen bzw. 5.000 Tokens. Lange Erklärungen lagerst du in
references/aus, echte Logik inscripts/. - Nutze konkrete Beispiele. Ein gutes Vorher-Nachher sagt mehr als drei Absätze Theorie.
- Schreib handlungsorientiert. Nicht „sei gründlich“, sondern „Prüfe zuerst X, dann Y“. Claude folgt konkreten Schritten zuverlässiger als vagen Wünschen.
- Sperr kritische Aktionen. Deploys, Datenbank-Migrationen, Commits auf Produktiv-Branches: Da gehört
disable-model-invocation: truerein. Sicherheit vor Bequemlichkeit. - Leg Skills in deinen Projektordner. Speicherst du sie unter
.claude/skills/direkt im Projekt, hat jeder, der mit diesem Projekt arbeitet, automatisch dieselben Skills. - Teste mit /skills. Prüfe nach jeder Änderung, ob der Skill korrekt erkannt wird – am besten mit verschiedenen Prompts, wie du auch echten Code testen würdest.
Bau den Skill nicht am Reißbrett. Arbeite eine Aufgabe erst ganz normal im Chat durch, bis das Ergebnis sitzt. Und dann sagst du einfach: „Fasse das als Skill zusammen.“ Claude schreibt dir die SKILL.md aus dem, was gerade nachweislich funktioniert hat. Besser geht’s kaum.
Die häufigsten Fehler – und wie du sie vermeidest
Fast alle Probleme mit Skills laufen auf dieselben paar Klassiker hinaus. Wenn dein Skill also nicht tut, was er soll, findest du die Ursache mit hoher Wahrscheinlichkeit hier:
- Die description ist zu vage. „Hilft beim Code“ ist kein Trigger. Der Skill wird schlicht nie geladen.
- Die description ist zu eng. Reagiert sie nur auf exakt eine Formulierung, springt sie im Alltag nie an. Nenne mehrere typische Auslöser.
- Alles steckt in der SKILL.md. 800 Zeilen in einer Datei sprengen das Prinzip der Progressive Disclosure. Auslagern!
- Der Trigger steht im Body. Ein „Wann nutzen“-Kapitel mitten im Skill bringt nichts, weil Claude es erst nach der Aktivierung sieht.
- name passt nicht zum Ordnernamen. Kleiner Tippfehler, große Wirkung: Der Skill taucht gar nicht erst auf.
- Jeder Slash-Command wird zum Skill. Ein Einzeiler bleibt besser ein Einzeiler, sonst überlädst du dein Menü.
Merkst du was? Die meisten Fehler drehen sich um die description. Investier fünf Minuten mehr in diesen einen Satz, und der Rest läuft.
Was sich zuletzt getan hat
Skills haben sich in kurzer Zeit vom Nischen-Feature zum Herzstück von Claude Code entwickelt. Ein paar Meilensteine, die du kennen solltest:
Im Januar 2026 hat Anthropic mit Version 2.1.3 Slash-Commands und Skills intern zu einem einzigen Werkzeug verschmolzen. Seitdem gibt es keine zwei Systeme mehr, die sich beißen – ein Slash-Command ist einfach ein Skill, den du selbst aufrufst. Im selben Zug kam das Hot-Reloading: Du speicherst deine SKILL.md, und die Änderung greift sofort. Kein Neustart, kein Session-Verlust.
Im Frühjahr folgten der offizielle Community-Marketplace und eine ganze Reihe quelloffener Skills von Anthropic selbst. Seitdem wächst das Ökosystem rasant: In den Community-Verzeichnissen findest du inzwischen Tausende Skills und Hunderte Plugins.
Das spannendste Update für Fortgeschrittene sind die Routines, die seit Mai 2026 offiziell verfügbar sind. Damit laufen Skills zeitgesteuert oder event-basiert in der Cloud – etwa jeden Morgen um sechs oder immer dann, wenn ein GitHub-Webhook feuert. Ein Beispiel: Dein Security-Skill prüft nachts automatisch die Abhängigkeiten und legt dir das Ergebnis auf den Tisch, bevor du überhaupt den Rechner hochfährst.
Ein Stolperstein, der viele erwischt: Routines sehen nur Skills, die im Repo eingecheckt sind, also unter .claude/skills/. Was in deinem persönlichen Ordner ~/.claude/skills/ liegt, existiert für die Cloud nicht. Wenn deine Routine also „den Skill nicht findet“, liegt es fast immer daran.
Für Unternehmen kam zuletzt noch die zentrale Verwaltung dazu: Admins können Skill-Registries organisationsweit ausrollen und über Managed Settings festlegen, was erlaubt ist. Damit werden Skills endgültig zur Infrastruktur – nicht mehr nur zum Bastelprojekt einzelner Entwickler.

Der offene Standard: Skills laufen längst nicht mehr nur in Claude
Hier kommt das vielleicht spannendste Update. Seit Dezember 2025 ist das Format ein offener Standard, dokumentiert unter agentskills.io. Was bedeutet das für dich konkret? Eine einmal gebaute SKILL.md ist nicht mehr an Claude gekettet.
Dieselbe Datei funktioniert ohne Änderung in einer wachsenden Zahl von Tools – darunter OpenAI Codex CLI, Gemini CLI, GitHub Copilot, Cursor, VS Code und über 20 weitere Plattformen. Das ist derselbe Weg, den Anthropic schon beim Model Context Protocol gegangen ist: aus einem internen Feature einen Branchenstandard machen. Für dich heißt das: Deine Skill-Bibliothek ist eine Investition, die du mitnehmen kannst, selbst wenn du irgendwann das Tool wechselst.
Und was ist mit den Claude-spezifischen Feldern wie context: fork oder effort? Ganz easy: Tools, die damit nichts anfangen können, ignorieren sie einfach. Dein Skill läuft trotzdem – nur eben ohne die Extras. Schreib also den Kern deiner Skills in schlichtem Markdown, dann bist du überall zu Hause.
Noch mehr aus KI holen: Sechs fertige Bausteine zum Kopieren gibt es in meinem kostenlosen Werkzeugkasten. Und wer es gründlich angehen will, ist im KI Business Dojo richtig — dort liegen alle Kurse zusammen mit der Community.

Fazit
Claude Code Skills sind eines der unterschätztesten Produktivitäts-Features. Sie verwandeln wiederkehrende Erklärungen in wiederverwendbares Wissen, das Claude genau dann zieht, wenn er es braucht – dank Progressive Disclosure, ohne dein Kontextfenster zuzumüllen. Während Slash-Commands manuelle Shortcuts bleiben, Subagenten Arbeit delegieren, MCP die Verbindung zur Außenwelt herstellt und Plugins das Teilen ermöglichen, sind Skills die schlanke, fokussierte Basis dafür. Und weil das Format mittlerweile ein offener Standard ist, nimmst du deine Skill-Bibliothek sogar über Tool-Grenzen hinweg mit.
Fang klein an: Nimm eine Aufgabe, die du immer wieder erklärst, gieß sie in eine SKILL.md, feile an der description, bis sie zuverlässig anspringt, prüfe alles mit /skills und beobachte, wie Claude ab sofort von selbst weiß, was zu tun ist. Dein zukünftiges Ich wird es dir danken.

Häufig gestellte Fragen
Muss ich einen Skill manuell aktivieren?
Nein. Claude lädt einen Skill automatisch, sobald er anhand der description als relevant erkannt wird. Über /skills kannst du aber jederzeit nachsehen, welche Skills verfügbar sind. Und wenn du die Kontrolle behalten willst, setzt du disable-model-invocation: true – dann läuft der Skill nur, wenn du ihn selbst aufrufst.
Was ist der Unterschied zwischen einem Skill und CLAUDE.md?
Deine CLAUDE.md gilt projektweit und ist immer im Kontext. Ein Skill wird dagegen nur bei Bedarf geladen – dank Progressive Disclosure. Allgemeine Projektregeln gehören in die CLAUDE.md, spezialisierte, situative Fähigkeiten in Skills. Als Daumenregel: Was in mehr als 30 Prozent deiner Anfragen zählt, gehört in die CLAUDE.md.
Warum wird mein Skill nicht geladen?
In den allermeisten Fällen liegt es an der description. Sie ist das einzige Signal, das Claude vor der Aktivierung sieht – ein „Wann nutzen“-Kapitel im Body hilft nicht. Nenne konkrete Auslöser statt vager Beschreibungen. Der zweithäufigste Grund: Der name im Frontmatter stimmt nicht exakt mit dem Ordnernamen überein.
Funktionieren Skills auch außerhalb von Claude Code?
Ja. Skills laufen in Claude Code, in der Web-App auf claude.ai und über die API. Und seit das Format ein offener Standard ist, ziehen auch andere Tools wie Cursor, Codex CLI oder GitHub Copilot mit. Claude-spezifische Felder werden von diesen Tools einfach ignoriert.
Kann ich Skills mit anderen teilen?
Ja. Am einfachsten legst du die Skill-Dateien in deinen Projektordner – wer das Projekt öffnet, hat die Skills automatisch dabei. Willst du sie unabhängig von einem einzelnen Projekt weitergeben, bündelst du sie in einem Plugin und teilst es über einen Marketplace.
Verbrauchen viele Skills nicht jede Menge Tokens?
Eben nicht – das ist der ganze Witz an Progressive Disclosure. Beim Start kostet jeder Skill nur den Namen und die Beschreibung, also eine Handvoll Tokens. Der volle Inhalt landet erst dann im Kontext, wenn Claude den Skill tatsächlich braucht.
Kann ein Skill automatisch nach Zeitplan laufen?
Ja, über die Routines. Damit lässt du Skills zeitgesteuert oder per Event in der Cloud laufen – etwa nach einem GitHub-Webhook. Wichtig: Routines sehen nur Skills, die im Repo unter .claude/skills/ eingecheckt sind, nicht die in deinem persönlichen Ordner.






