Anthropics 33-Seiten-Blueprint für Claude Skills

Anthropic hat einen 33-seitigen Leitfaden mit dem Titel "The Complete Guide to Building Skills for Claude" veröffentlicht. Auf den ersten Blick ist es eine technische Dokumentation. Auf den zweiten ist es eine Ansage: Die Art, wie Profis mit Claude arbeiten, verschiebt sich von "den nächsten cleveren Prompt finden" zu "wiederkehrende Workflows als Code-Artefakt versionieren".

Skills sind kein neues Modell. Sie sind ein Ordner. Genauer: ein Ordner mit einer einzigen Pflichtdatei – SKILL.md – und einem kurzen YAML-Header, der Claude sagt, wann dieser Skill aktiviert werden soll. Das war es im Kern. Und genau diese Schlichtheit ist der Punkt.

Was ein Skill ist – minimal beschrieben

Ein Skill ist ein Verzeichnis mit folgender Struktur:

your-skill-name/
├── SKILL.md          # Pflichtdatei: Markdown mit YAML-Frontmatter
├── scripts/          # Optional: ausführbare Skripte
├── references/       # Optional: Zusatz-Dokumentation
└── assets/           # Optional: Templates, Fonts, Icons

Die SKILL.md beginnt mit einem YAML-Block, der zwei Pflichtfelder hat: name und description. Die description ist das wichtigste Feld im gesamten Skill, weil sie entscheidet, ob Claude den Skill überhaupt lädt.

---
name: legal-contract-review
description: Prüft deutsche Wirtschaftsverträge auf typische
  Risikoklauseln. Nutze bei "Vertragsprüfung",
  "Risiko-Check", "AGB analysieren" oder beim Upload
  von .pdf/.docx-Verträgen.
---

Der Trick heißt Progressive Disclosure

Das eigentlich Clevere am Skill-System ist nicht das Format, sondern wie Claude die Inhalte lädt. Anthropic nennt das Progressive Disclosure – drei Ebenen, von denen nur die jeweils nötige geladen wird:

Praktische Konsequenz: Du kannst zehn oder zwanzig Skills aktiviert haben, ohne dass dein Kontext aufgebläht wird. Du zahlst Tokens nur für das, was Claude in der konkreten Aufgabe wirklich zieht.

Skills sind nicht MCP. Und das ist die wichtigste Unterscheidung im Guide

Anthropic nutzt ein Küchen-Bild, das die Trennung gut transportiert:

MCP ohne Skills heißt: Der User hat Zugriff auf 30 Werkzeuge und weiß bei jedem zweiten Prompt nicht, in welcher Reihenfolge er sie kombinieren soll. MCP mit Skills heißt: Der User beschreibt das Ergebnis, und der Skill orchestriert die richtigen MCP-Calls in der richtigen Sequenz – jedes Mal gleich.

Drei Kategorien, in die fast alles fällt

Der Guide gliedert produktive Skill-Anwendungen in drei Klassen, die sich in der Praxis tatsächlich gut bewähren:

1. Document & Asset Creation. Skills, die konsistente Outputs nach festen Standards produzieren – Präsentationen im Corporate Design, Code in einem Style-Guide, technische Reports nach Template. Beispiel im Guide: das frontend-design-Skill, das Claudes Design-Output spürbar hebt.
2. Workflow-Automation. Mehrstufige Prozesse mit klaren Validierungs-Gates. Sprint-Planung, Onboarding eines Kunden, Code-Review nach Schema. Wenn die Reihenfolge zählt und Schritte voneinander abhängen, gehört der Workflow in einen Skill.
3. MCP-Enhancement. Skills, die als Wissensschicht über einer bestehenden MCP-Integration liegen. Sentry hat das öffentlich vorgemacht: Ein sentry-code-review-Skill, der die Tools des Sentry-MCP-Servers in der richtigen Sequenz aufruft, um Bugs aus Production-Daten automatisch in Pull Requests zu fixen.

Die description ist der wichtigste Satz im gesamten Skill

Anthropic widmet dem description-Feld mehrere Seiten – aus gutem Grund. Diese eine Zeile entscheidet, ob Claude den Skill bei einer User-Anfrage überhaupt in Erwägung zieht. Die Regel ist einfach: Was tut der Skill + wann soll er ausgelöst werden.

description: Hilft mit Projekten.

description: End-to-End-Onboarding
für PayFlow-Kunden inklusive Account-
Erstellung und Subscription-Setup.
Nutze bei "neuen Kunden anlegen",
"PayFlow-Account erstellen",
"Subscription einrichten".

Was im Skill-Body wirklich zählt

Der Guide hat dafür eine erfrischend pragmatische Linie: Sei konkret, sei prüfbar, lass Code prüfen, was sich automatisieren lässt.

Statt zu schreiben "Validiere die Eingaben sorgfältig" – ein Satz, den jedes Modell anders interpretiert – lieber: "Rufe python scripts/validate.py --input {filename} auf. Bei Fehlern prüfe: fehlende Pflichtfelder, Datumsformat YYYY-MM-DD". Skripte sind deterministisch. Sprache nicht. Wo es um Korrektheit geht, gewinnt das Skript.

Anthropic empfiehlt darüber hinaus eine simple Struktur für den Body: Workflow-Schritte als nummerierte Liste, Beispiele für typische Anwendungsfälle, Troubleshooting-Sektion für die zwei oder drei Fehler, die in der Praxis immer wieder auftreten. Mehr braucht es selten.

Testen, ohne Test-Framework

Der Guide schlägt drei Test-Ebenen vor – alle ohne aufwendige Infrastruktur machbar:

1. Trigger-Tests. Zwanzig realistische Anfragen formulieren, prüfen, wann der Skill lädt und wann nicht. Auch Edge-Cases ("Wetter in San Francisco") – um sicherzustellen, dass der Skill nicht überall feuert.
2. Funktionale Tests. Workflow ausführen, Output prüfen. Werden die Tickets erstellt? Stimmen die Properties? Schlagen API-Calls fehl?
3. Vorher/Nachher-Vergleich. Gleiche Aufgabe mit und ohne Skill. Wie viele Nachfragen? Wie viele Tokens? Wie viele Retries? Genau hier wird der Wert sichtbar.

Anthropic stellt für diesen Prozess einen skill-creator-Skill bereit – ein Meta-Skill, der einen interaktiv durch Definition, YAML, Beispiele und Validierung führt. Wer einen MCP-Server hat und seine zwei oder drei Top-Workflows kennt, baut den ersten funktionierenden Skill in 15 bis 30 Minuten.

Was Skills in der Praxis verändern

Ohne Skills wiederholt sich ein bekanntes Muster: Jeder Mitarbeiter erklärt Claude bei jedem Sprint-Planning erneut, wie das Team plant. Fünfzehn Nachrichten hin und her. Inkonsistente Outputs zwischen Kollegen. Support-Tickets der Art "Wie nutze ich euren Connector richtig?".

Mit Skills verschiebt sich der Punkt, an dem Wissen gespeichert wird. Statt im Kopf einzelner Power-User liegt es im Repository – versioniert, reviewbar, teamweit aktivierbar. Anthropic hat im Dezember 2025 die organisationsweite Skill-Verteilung freigegeben. Admins können Skills für eine ganze Workspace ausrollen. Updates landen zentral. Onboarding eines neuen Teammitglieds bedeutet nicht mehr "lies dich in unsere Prompts ein", sondern "schalte diese Skill-Sammlung frei".

Wo Skills aufhören – und wo CLAUDE.md weiterläuft

Skills sind nicht das richtige Werkzeug für alles. Allgemeine Verhaltensregeln – "Frage bei Unklarheit nach", "Überschreibe keinen Code, den du nicht verstanden hast", "Halte den Stil des Repos" – gehören weiterhin in eine CLAUDE.md, weil sie für jede Aufgabe gelten sollen, nicht nur für spezifische Workflows.

Die saubere Aufteilung in Projekten, die ich gerade betreue: CLAUDE.md für Disziplin und Stil. Skills für konkrete, wiederkehrende Workflows. MCP für Tool-Zugriff. Drei Schichten, die sich nicht überlappen, aber zusammen das ergeben, was Anthropic im Guide "encoded workflows" nennt.

Was das größere Bild ist

Der Guide ist mehr als nur Doku. Er ist ein Marker für eine Verschiebung, die sich seit ein paar Monaten abzeichnet. Die Phase "clever prompten" geht zu Ende. Die Phase "Workflows encoden" beginnt. Wer Claude täglich nutzt, aber noch keinen einzigen Skill gebaut hat, arbeitet im Vergleich noch manuell – jede Konversation startet bei Null, jedes Ergebnis hängt am Tagesform-Prompt.

Skills lösen dieses Problem mit einer fast banal wirkenden Idee: Ein Ordner mit einer Markdown-Datei. Aber genau diese Banalität ist der Grund, warum sich das Konzept durchsetzen wird. Es braucht keinen neuen Stack, kein Framework, keine spezielle SDK. Ein Texteditor und eine Stunde Zeit reichen für den ersten produktiven Skill. Und ab dem zweiten Skill merkt man, was sich verändert.

Verwendete Quellen:

Sie überlegen, wo in Ihrem Team Skills den größten Hebel hätten – beim Onboarding, bei Code-Reviews, bei einem mehrstufigen Compliance-Workflow? Lassen Sie uns sprechen. Ich helfe beim Aufbau von Skill-Bibliotheken, die in realen Projekten funktionieren und nicht nur in der Demo.