Claude Skills erklärt: Die Markdown-Datei, die deinen KI-Workflow automatisiert

Tobe
Blog Veröffentlich am 28.02.26, Tobias Lorsbach

Ich muss kurz Erwartungen korrigieren, bevor du weiterliest.

Claude Skills klingen nach einem großen neuen Feature. Nach Plug-ins, nach komplexer KI-Magie, nach einer Sache, die du wahrscheinlich nicht selbst bauen kannst. Das Gegenteil ist der Fall. Ein Claude Skill ist im Kern eine .md-Datei mit einem YAML-Header. Das wars. Kein Scherz, kein vereinfachtes Marketing – das ist buchstäblich alles, was drin steckt.

Und genau deshalb ist es interessant.

Ich hab mir das letzte Woche genauer angeschaut, nachdem der Hype darum auf LinkedIn merklich lauter wurde. Was ich dabei rausgefunden habe – was wirklich funktioniert, wo die Grenzen liegen und für wen sich das lohnt – das gibt es jetzt hier. Ungefiltert, wie immer.

Claude, Claude Cowork, Claude Code – was ist was?

Bevor wir zu den Skills kommen, kurz zur Orientierung – weil die Begriffe gerade wild durcheinander geworfen werden.

Claude ist der KI-Assistent von Anthropic. Den nutzt du entweder über claude.ai im Browser oder in der mobilen App. Das ist der Chat, den die meisten kennen: du schreibst, Claude antwortet. Für Entwickler gibt es zusätzlich den Zugang über die API, mit der du Claude in eigene Anwendungen einbaust.

Claude Cowork ist ein Desktop-Tool, das sich an Nicht-Entwickler richtet. Es ist dafür gedacht, Datei- und Aufgabenverwaltung zu automatisieren – direkt auf dem eigenen Rechner, ohne Terminal. Cowork ist aktuell noch in der Beta.

Claude Code ist das Gegenteil von Cowork: ein Kommandozeilen-Tool für Entwickler. Du rufst es im Terminal auf, es hat Zugriff auf dein Filesystem, deine Git-History, deine Projektstruktur. Es kann eigenständig Code schreiben, testen, committen und komplexe Entwicklungsaufgaben von A bis Z durchführen. Claude Code ist der mächtigste der drei Zugänge – und der, der am meisten Kontrolle voraussetzt.

Der wichtige Unterschied für diesen Artikel: Skills verhalten sich je nach Umgebung anders. Was du im Browser (Claude Chat) installierst, ist nicht dasselbe wie was du in Claude Code nutzt. Mehr dazu im Abschnitt “Wo du Skills installierst”.

Was ein Skill technisch ist

Ein Skill ist ein Ordner. In diesem Ordner liegt mindestens eine SKILL.md. Diese Datei hat zwei Teile: einen YAML-Frontmatter-Block oben (zwischen den --- Trennern) und darunter normalen Markdown-Text mit Anweisungen.

mein-skill/
├── SKILL.md        ← Pflicht
├── scripts/        ← Optional: Python- oder Bash-Scripts
├── references/     ← Optional: Referenz-Dokumente
└── templates/      ← Optional: Ausgabe-Vorlagen

Die komplette Dateistruktur siehst du hier:

Aufbau eines Claude Skills – Dateistruktur-Übersicht

Der Frontmatter sieht so aus:

---
name: seo-audit
description: 'Führt einen SEO-Audit durch. Aufrufen wenn der User nach SEO, PageSpeed oder Core Web Vitals fragt.'
allowed-tools: Bash, Read
---

Das war’s. Der Rest ist Markdown – also normaler Text, in dem du Claude erklärst, was er tun soll. Schritt für Schritt, mit Beispielen, mit Regeln, mit Templates. Genau so, wie du es in einem langen Prompt machen würdest. Nur strukturiert, wiederverwendbar und auf Abruf verfügbar.

Der entscheidende Mechanismus dahinter: Claude lädt beim Start nur den YAML-Header aller verfügbaren Skills (circa 100 Token pro Skill). Wenn ein Auftrag zur Description eines Skills passt, lädt Claude den vollständigen Inhalt nach. Das spart Context-Window und macht das System skalierbar – 20 Skills bedeuten ~2.000 Token beim Start statt ~40.000.

Wie Claude entscheidet, wann ein Skill geladen wird

Die description im Frontmatter ist der Schlüssel. Claude liest diese Beschreibung und entscheidet darauf basierend, ob der aktuelle Auftrag zu diesem Skill passt. Du kannst Skills auch manuell aufrufen über /skill-name – dann wird er unabhängig vom Kontext geladen.

Wenn du willst, dass nur du einen Skill aufrufen kannst (zum Beispiel weil er Seiteneffekte hat wie einen Git-Commit oder eine Slack-Nachricht), setzt du disable-model-invocation: true. Dann entscheidet Claude nicht selbst, wann er ihn lädt.

Umgekehrt gibt es user-invocable: false für Skills, die Claude selbst im Hintergrund nutzen soll, ohne dass du sie direkt aufrufen willst – zum Beispiel ein Legacy-System-Kontext, der automatisch aktiv wird wenn du an einer bestimmten Codebase arbeitest.

Mein eigener Test: Der SEO-Audit-Skill

Ich hab einen SEO-Audit-Skill gebaut und auf einer echten Kundenwebsite laufen lassen. Der Skill hatte drei Aufgaben: die Website selbständig aufrufen, PageSpeed Insights öffnen, Daten sammeln und ein strukturiertes Ergebnis liefern.

Was passiert ist: Claude hat die Seite aufgerufen, PageSpeed geöffnet, die relevanten Metriken rausgezogen und ein sauberes, strukturiertes Audit-Ergebnis geliefert. Ohne dass ich die Maus angefasst habe.

Das klingt beeindruckend – und das war es auch. Aber ich muss ehrlich sein: Es hat beim ersten Versuch nicht funktioniert. Der Skill hat zweimal falsche Tool-Calls gemacht, bevor er auf dem richtigen Weg war. Für einen einmaligen Test brauchbar, für ein produktives Kundenprojekt ohne Kontrolle? Noch nicht.

Das ist die wichtigste Botschaft dieses Artikels: Skills sind mächtig, aber sie sind kein Autopilot. Du bist immer noch der Pilot.

Was Skills tatsächlich können

Skills eignen sich für vier Szenarien, in denen sie wirklich Sinn ergeben:

Wiederkehrende interne Workflows. Du machst jeden Montag denselben Report? Jedes neue Projekt startet mit denselben Schritten? Das ist der Sweet Spot. Einmal als Skill definiert, immer wieder abrufbar – konsistent, ohne dass du den Prompt jedes Mal neu formulieren musst.

Firmen- oder projektspezifisches Wissen. Brand Guidelines, Coding Conventions, API-Dokumentation – alles, was Claude bei einem bestimmten Auftrag kennen soll, ohne dass du es jedes Mal in den Chat kopierst. Ein references/-Ordner im Skill lädt diese Informationen nur wenn nötig.

Kombinierte Tool-Workflows. Skills können Bash-Scripts ausführen, Dateien lesen, externe Tools aufrufen. Das macht sie zur Brücke zwischen “Claude gibt Anweisungen” und “Claude erledigt Aufgaben direkt”. In Kombination mit MCP-Servern wird das nochmal interessanter – Skills für die Logik, MCP für den Datenzugriff.

Plattformunabhängige Workflows. Skills folgen einem offenen Standard, der inzwischen von über 25 Tools unterstützt wird – Claude Code, Cursor, Gemini CLI und andere. Du definierst einen Skill einmal und kannst ihn theoretisch in mehreren KI-Umgebungen nutzen.

Was Skills nicht sind

Keine Plug-ins mit komplexem Code im Hintergrund. Kein Ersatz für n8n oder echte Automatisierung bei komplexen Workflows mit vielen Abhängigkeiten. Keine 100% zuverlässige Lösung für kritische Produktionsprozesse – das sage ich direkt.

Und: Skills ersetzen nicht das Denken. Eine gut geschriebene description ist entscheidend dafür, ob Claude den Skill zur richtigen Zeit lädt. Eine schlechte Description bedeutet, der Skill wird ignoriert oder im falschen Kontext aktiviert. Das ist Prompt Engineering – nur an einer anderen Stelle.

Wo du Skills installierst

Die Grafik oben zeigt es kompakt: UI-basiert und Terminal-basiert sind zwei komplett verschiedene Welten mit unterschiedlicher Verfügbarkeit.

UI-basierte Installation (Claude Chat, Cowork): Settings → Capabilities → Skill als .zip hochladen. Funktioniert nicht in Claude Code.

Terminal-basierte Installation (Claude Code): Persönliche Skills in ~/.claude/skills/, projektspezifische in .claude/skills/ im Projektordner. Funktioniert nicht in Claude Chat oder Cowork.

Claude Code erkennt Änderungen live, ohne Neustart.

Mein ehrliches Fazit

Skills sind das, was Custom Instructions hätten sein sollen, aber strukturierter, modularer und mit echter Tool-Integration. Der Einstieg ist absurd niedrig – wenn du Markdown kannst, kannst du Skills bauen.

Der Use Case, der mich am meisten überzeugt: Skills für wiederkehrende interne Workflows. Nicht für alles. Nicht als Ersatz für echte Automatisierung. Aber für genau diese Aufgaben – einmal richtig definiert, immer wieder abrufbar – sind sie ein echter Zeitgewinn.

Produktionsreif für Kundenprojekte ohne Kontrolle? Noch nicht für komplexe Flows. Brauchbar für eigene Workflows und als Ergänzung zum KI-Toolset? Definitiv ja.

Der nächste Schritt für mich: einen WordPress-Deployment-Skill bauen, der meine üblichen Pre-Launch-Checks automatisiert. Wenn der steht, gibt es hier einen Follow-up.


Weiterführend: Wenn du verstehen willst, wie Skills und MCP zusammenspielen, schau dir meinen MCP-Artikel an. Und wenn dich KI-Agents im echten Einsatz interessieren – meine Real-World-Erfahrungen mit KI-Agents 2026 sind der direkte Vorläufer zu diesem Artikel.


Kommentare

Kommentar schreiben

0 / 5000 Zeichen

* Pflichtfelder

Noch keine Kommentare. Sei der Erste!