Claude Skills: Anthropics 32-seitiger Leitfaden entschlüsselt
Ich habe acht Monate lang dieselben Anweisungen an Claude geschrieben. Jeden Montag früh, derselbe Sprint-Planungs-Prompt. Bei jedem Kundengespräch, dieselbe Vorlage für Besprechungsnotizen. Bei jeder Bereitstellung, dieselbe Checkliste ins Chatfenster eingefügt wie eine Art digitaler Groundhog Day.
Dann veröffentlichte Anthropic einen 32-seitigen Leitfaden über etwas namens Claude Skills — und innerhalb eines einzigen Nachmittags löschte ich jeden gespeicherten Prompt, den ich hatte.
Nicht archiviert. Gelöscht. Denn sobald man versteht, was Skills tatsächlich sind, fühlt sich die Rückkehr zum Kopieren und Einfügen von Prompts an wie die Rückkehr zum Briefeschreiben nach der Entdeckung von E-Mail. Das Konzept ist täuschend einfach: Du lehrst Claude einmal etwas, innerhalb eines Ordners mit einer Markdown-Datei und optionalen Scripts, und es weiß einfach, wie man das von diesem Punkt an tut. Kein erneutes Erklären. Kein "hier ist mein Styleguide nochmal." Kein "denk daran, wir verwenden Tailwind, nicht Bootstrap."
Eine SKILL.md-Datei. Etwas YAML oben. Fertig.
Aber — und darauf möchte ich eingehen — der Leitfaden selbst ist sowohl brillant als auch frustrierend. Brillant, weil das Rahmenwerk, das er umreißt, wirklich mächtig ist. Frustrierend, weil die wichtigsten Implementierungsdetails unter Schichten polierter Dokumentationssprache begraben sind, und einige der am schwersten erkämpften Lektionen über das Zum-Laufen-Bringen von Skills nebenbei erwähnt oder gar nicht erwähnt werden.
Ich verbrachte drei Tage damit, den Leitfaden zu lesen, Skills zu bauen, Skills zu brechen und sie neu aufzubauen. Was folgt ist alles, was ich mir gewünscht hätte, jemand hätte mir gesagt, bevor ich anfing — die Teile, die Anthropic richtig gemacht hat, die Teile, die sie abgehakt haben, und die fünf Muster, die wirklich zählen, sobald man die Marketingsprache entfernt.
Das Konzept, Das Alles Klicken Lässt
Hier ist das mentale Modell, das Claude Skills endlich für mich verständlich machte, und es ist nicht das, mit dem Anthropic anfängt.
Du kennst wahrscheinlich MCP bereits — das Model Context Protocol, das Claude mit externen Tools wie Notion, Linear, Figma, GitHub, Slack und im Grunde allem mit einer API verbindet. MCP geht um Zugang. Es gibt Claude die Schlüssel zu deinen Tools. Die Tür öffnen, hereinkommen, sich umsehen.
Skills sind anders. Skills gehen um Urteilsvermögen.
Denk so darüber nach. Du stellst einen neuen Entwickler ein und gibst ihm Administrator-Zugang zu deinem gesamten Stack — dein Projektmanagement-Tool, deine CI/CD-Pipeline, dein Design-System, deine Kommunikationskanäle. Sie können technisch alles berühren. Aber sie kennen die Konventionen deines Teams nicht. Sie wissen nicht, dass deine Sprint-Velocity-Berechnung Bugfixes unter zwei Story Points ausschließt. Sie wissen nicht, dass Design-Übergaben immer über einen spezifischen Figma-zu-Linear-Workflow mit obligatorischen Zugänglichkeitsanmerkungen gehen. Sie wissen nicht, dass Bereitstellungsankündigungen einem bestimmten Format in einem bestimmten Slack-Kanal folgen.
Zugang ohne Urteilsvermögen schafft Chaos. MCP gibt Claude Zugang. Skills geben Claude Urteilsvermögen.
Diese Unterscheidung ist der gesamte Leitfaden in einem einzigen Satz. Alles andere — das YAML-Frontmatter, die Ordnerstruktur, die fünf Muster, die Debugging-Ratschläge — ist Implementierungsdetail, das an dieser Kernidee hängt.
Sobald das für mich klickte, hörte ich auf, Skills als "fancy Prompts" zu denken, und begann sie als institutionelles Wissen in Code zu denken. Und diese Neuformulierung veränderte, wie ich jede einzelne baute.
Was Wirklich im Ordner Steckt — Und Was Jedes Teil Tut
Ein Claude Skill lebt in einem Ordner. Mindestens enthält dieser Ordner eine Datei: SKILL.md. Das war's. Eine Markdown-Datei, und du hast einen funktionierenden Skill.
Oben in dieser Markdown-Datei befindet sich YAML-Frontmatter — der Metadatenblock zwischen dreifachen Bindestrichen, der Claude mitteilt, was dieser Skill ist, was er tut, und entscheidend, wann er aktiviert werden soll. Der Rest der Datei enthält die eigentlichen Anweisungen: wie die Aufgabe auszuführen ist, welche Standards einzuhalten sind, welche Tools zu verwenden sind und welche Fallstricke zu vermeiden sind.
Optional kannst du Scripts, Referenzdokumente und Vorlagen zum Ordner hinzufügen. Ein Styleguide-PDF. Ein Bash-Script, das Linting ausführt. Ein JSON-Schema für deine API-Antworten. Claude wird diese beim Ausführen des Skills konsultieren.
Hier ist ein minimales Beispiel — ein Skill, der wöchentliche Statusberichte für meine Projekte generiert:
---
name: weekly-status-report
description: >
Generates a formatted weekly status report by pulling data
from Linear and GitHub. Trigger when user asks for a status
report, weekly update, or progress summary.
---
## Weekly Status Report Generator
### What This Skill Does
Produces a concise weekly status report covering completed work,
in-progress items, blockers, and next-week priorities.
### Data Sources
1. Pull completed issues from Linear for the current sprint
2. Pull merged PRs from GitHub for the past 7 days
3. Pull open blockers tagged with "blocked" label in Linear
### Report Format
- **Summary** (2-3 sentences, biggest wins and risks)
- **Completed** (bullet list with ticket references)
- **In Progress** (bullet list with percentage estimates)
- **Blockers** (bullet list with owner and age in days)
- **Next Week** (top 3 priorities)
### Style Rules
- No jargon — this goes to stakeholders, not engineers
- Lead each section with the most impactful item
- Blockers must include who owns the resolution
- Keep total length under 500 words
Das ist ein vollständiger Skill. Wenn ich Claude frage "gib mir das Statusupdate dieser Woche," erkennt er den Trigger aus dem Beschreibungsfeld, lädt den Skill, verbindet sich mit Linear und GitHub über MCP und erstellt einen Bericht nach meinem genauen Format und meinen Stilregeln.
Kein Prompt-Engineering. Kein Erinnern, wo ich die Vorlage gespeichert habe. Das Wissen lebt im Skill, und Claude weiß, wann er danach greifen soll.
Aber hier ist der Teil, den der Leitfaden in einer Randnotiz begräbt, der auf Seite eins stehen sollte: Das Beschreibungsfeld in deinem YAML-Frontmatter ist die wichtigste Zeile, die du jemals schreiben wirst. Bekomme das falsch und nichts anderes zählt.
Die Zwei Zeilen, Die Deinen Skill Machen oder Brechen
Ich verlor vier Stunden damit. Vier Stunden damit, einen perfekt detaillierten Skill zu bauen, den Claude nie auslöste. Die Anweisungen waren klar. Das Format war präzise. Die Referenzdokumente waren umfassend. Und jedes Mal, wenn ich Claude bat, das Ding zu tun, für das der Skill konzipiert war, verwendete er einfach sein allgemeines Wissen. Ignorierte den Skill vollständig.
Das Problem war mein Beschreibungsfeld.
Meine ursprüngliche Beschreibung lautete: "Hilft bei Code-Review-Prozessen." Sechs Worte. Vage. Passiv. Claude hatte keine Ahnung, wann er ihn aktivieren sollte, weil "hilft bei Code-Review-Prozessen" buchstäblich alles bedeuten könnte.
Ich schrieb es um: "Führt strukturierten Code-Review an Pull Requests durch. Auslösen wenn Benutzer einen PR-Link teilt, um Code-Review bittet, einen PR-Review anfordert oder ein Diff einfügt. Prüft auf Sicherheitsschwachstellen, Leistungsprobleme, Namenskonventionen gemäß Teamstandards und Lücken in der Testabdeckung."
Begann sofort zu funktionieren. Jedes einzelne Mal.
Das Muster, das ich durch Versuch und Irrtum entdeckte — und der Leitfaden deutet darauf hin, aber sagt es nicht klar genug — ist, dass deine Beschreibung drei Dinge braucht:
1. Was es tut (aktives Verb, spezifische Ausgabe): "Generiert wöchentliche Berichte" nicht "Hilft bei der Berichterstattung."
2. Wann auslösen (explizite Trigger-Phrasen): "Auslösen wenn Benutzer nach X, Y oder Z fragt." Liste die tatsächlichen Wörter und Phrasen auf, die ein Mensch verwenden würde. Sei nicht clever. Sei wörtlich.
3. Was es abdeckt (Umfangsgrenzen): "Prüft auf A, B, C und D." Das sagt Claude, was innerhalb der Domäne des Skills liegt und, implizit, was nicht.
Das Namensfeld zählt auch — verwende kebab-case, keine Leerzeichen, und mach es beschreibend. weekly-status-report schlägt report-v2 schlägt wsr. Claude verwendet den Namen als zusätzliches Signal für das Matching, also verbessern beschreibende Namen die Trigger-Genauigkeit.
Drei Anwendungsfälle — Und Der Eine, Den Anthropic Unterschätzt
Anwendungsfall 1: Dokumentenerstellung
Das ist die unkomplizierteste Anwendung. Du hast eine bestimmte Art von Dokument — eine Präsentation, eine technische Spezifikation, ein Kundenangebot, ein Design-Brief — das jedes Mal konsistente Standards einhalten muss. Schriftarten, Struktur, Ton, erforderliche Abschnitte, verbotene Phrasen. Anstatt bei jedem Gespräch einen Styleguide einzufügen, codierst du ihn einmal in einen Skill.
Anwendungsfall 2: Workflow-Automatisierung
Hier beginnen Skills, ernsthafte Zeit zurückzugewinnen. Mehrstufige Prozesse, die jedes Mal auf dieselbe Weise stattfinden müssen — Sprint-Planung, Bereitstellungs-Checklisten, Onboarding-Sequenzen, Incident-Response-Verfahren.
Mein Sprint-Planungs-Skill ist der, auf den ich am stolzesten bin. Er verbindet sich mit Linear, um den aktuellen Projektstatus abzurufen, analysiert unsere Geschwindigkeit über die letzten drei Sprints, identifiziert Carry-over-Elemente, die immer wieder rutschen, schlägt Prioritäten basierend auf Deadline-Nähe und Abhängigkeitsketten vor und erstellt die eigentlichen Sprint-Tickets mit geschätzten Punkten. Ein Prozess, der früher 90 Minuten meines Montagmorgens verbrauchte, findet jetzt in etwa vier Minuten statt, wobei ich die Ausgabe überprüfe und genehmige, anstatt sie von Grund auf neu zu generieren.
Anwendungsfall 3: MCP-Erweiterung
Das ist der Anwendungsfall, über den Anthropic am begeistert ist, und ehrlich gesagt, der, bei dem ich denke, dass sie das Potenzial unterschätzen. MCP-Erweiterung bedeutet, Domain-Expertise über dem Tool-Zugang zu schichten. Dein Skill verwendet Figma nicht nur — er kennt dein Design-System, deine Komponentennamenskonventionen, deine Zugänglichkeitsanforderungen und den spezifischen Workflow für die Übergabe von Designs an Engineering.
Ich baute einen Design-zu-Entwicklung-Übergabe-Skill, der die neuesten Designs von Figma abruft, Komponentenspezifikationen extrahiert, sie unserer bestehenden React-Komponentenbibliothek zuordnet, Lücken identifiziert, wo neue Komponenten benötigt werden, Linear-Tickets für die Engineering-Arbeit mit Akzeptanzkriterien aus den Designspezifikationen erstellt und eine Zusammenfassung in unserem Slack-Entwicklungskanal postet.
Sechs verschiedene Tools. Ein Skill. Eine Trigger-Phrase: "Verarbeite die neuen Designs."
Fünf Muster, Die 90% Der Realen Skills Abdecken
Muster 1: Sequenzieller Workflow
Schritte finden in einer festen Reihenfolge statt. Schritt 2 hängt von der Ausgabe von Schritt 1 ab. Schritt 3 hängt von Schritt 2 ab. Keine Verzweigungen, keine Konditionale — nur eine zuverlässige Pipeline.
Am besten für: Bereitstellungsverfahren, Compliance-Checklisten, Onboarding-Sequenzen, Datenmigrations-Scripts.
Muster 2: Multi-MCP-Koordination
Der Workflow umfasst mehrere externe Dienste. Figma zu Linear zu Slack. GitHub zu Jira zu Confluence. Der Skill orchestriert Datenfluss zwischen Tools, die nicht nativ miteinander kommunizieren.
Am besten für: toolübergreifende Workflows, Design-Übergaben, Release-Management, teamübergreifende Benachrichtigungen.
Muster 3: Iterative Verfeinerung
Generiere Ausgabe, validiere sie anhand von Kriterien, verbessere sie, validiere erneut. Der Skill enthält seine eigene Qualitätsschleife, anstatt ein Einzeldurchgangs-Ergebnis zu produzieren.
Am besten für: Berichtserstellung, Inhaltserstellung, Code-Review, wo du umfassende Abdeckung möchtest, jede Ausgabe, die von Selbstkritik profitiert.
Muster 4: Kontextbewusste Auswahl
Gleiches Ziel, verschiedene Ausführungspfade basierend auf Kontext. Lade eine PNG hoch und es verwendet einen Workflow. Lade eine SVG hoch und es verwendet einen anderen. Kleine Datei wird inline verarbeitet; große Datei wird in Stücke aufgeteilt.
Am besten für: Dateiverarbeitung, Inhaltsgenerierung über verschiedene Formate, Bereitstellungs-Scripts, die je nach Umgebung variieren.
Muster 5: Domain-Intelligenz
Der Skill verkörpert tiefes Fachwissen in einem bestimmten Bereich — finanzielle Compliance-Regeln, Sicherheitsprotokolle, medizinische Codierungsstandards, rechtliche Überprüfungskriterien. Der Wert liegt nicht im Workflow; er liegt im Wissen selbst.
Am besten für: Compliance-Prüfung, Sicherheitsaudits, spezialisierte Überprüfungsprozesse, jede Aufgabe, bei der "die Regeln kennen" der schwierige Teil ist.
Vier Fehler, Die Ich Gemacht Habe, Damit Du Das Nicht Musst
Fehler 1: Vage Beschreibungen, die nie auslösen.
Bereits behandelt, aber es verdient Wiederholung, denn es ist der häufigste Fehlermode. Wenn dein Skill nie aktiviert wird, ist die Beschreibung fast immer das Problem. Schreibe Trigger-Phrasen, die den genauen Wörtern entsprechen, die ein Mensch verwenden würde.
Fehler 2: Anweisungen in Textwänden begraben.
Meine ersten paar Skills waren Romane. Seiten Kontext, Hintergrundinformationen, Randfälle, Philosophie über warum wir Dinge auf eine bestimmte Weise tun. Was besser funktioniert: Stelle die kritischen Anweisungen an die Front. Lege die nicht verhandelbaren Regeln in die ersten 20 Zeilen. Verwende Überschriften aggressiv.
Fehler 3: Fehlende Fehlerbehandlung für MCP-Aufrufe.
Dein Skill muss Tool-Fehler antizipieren. Füge explizite Anweisungen hinzu: "Wenn der Linear-API-Aufruf fehlschlägt, warte 10 Sekunden und versuche es einmal erneut. Wenn er wieder fehlschlägt, fahre mit zwischengespeicherten Daten aus dem letzten erfolgreichen Durchlauf fort und weise darauf hin, dass Daten veraltet sein könnten."
Fehler 4: Versuchen, zu viel in einem Skill zu tun.
Ich baute einen Skill namens "project-manager", der Sprint-Planung, Statusberichte, Retrospektiv-Generierung, Backlog-Grooming und Stakeholder-Updates zu verarbeiten versuchte. Es war 400 Zeilen Anweisungen für fünf verschiedene Workflows.
Es war schrecklich. Das zugrundeliegende Prinzip: Ein Skill, eine Aufgabe. Wenn du "auch" oder "zusätzlich" in deine SKILL.md schreibst, brauchst du vielleicht einen zweiten Skill.
Die Erkenntnis, Die Verändert, Wie Du Über KI Bei Der Arbeit Denkst
Die meisten Leute verwenden KI als Allzweck-Assistenten. Jedes Gespräch beginnt bei null. Du erklärst deinen Kontext, deine Präferenzen, deine Standards, deine Tools, deine Workflows — und dann bekommst du eine Antwort, die durch all diese Erklärungen geprägt ist. Morgen machst du es wieder. Und wieder. Und wieder.
Claude Skills kehren dieses Modell um. Anstatt den Kontext in jedem Gespräch zur KI zu bringen, bettest du den Kontext dauerhaft innerhalb der KI-Umgebung ein. Die KI beginnt jedes relevante Gespräch damit, bereits deine Standards zu kennen, bereits mit deinen Tools verbunden zu sein, bereits deine Workflows zu verstehen.
Das ist kein Produktivitäts-Hack. Es ist eine architektonische Verschiebung in der Zusammenarbeit von Menschen und KI.
Wenn ich auf die elf Skills schaue, die ich in den letzten drei Tagen gebaut habe, schaue ich auf eine komprimierte Version davon, wie mein Team arbeitet. Unsere Code-Review-Standards. Unser Bereitstellungsprozess. Unser Kundenkommunikationsstil. Unsere Sprint-Planungsmethodik. Unser Design-Übergabe-Workflow. Alles kodiert, ausführbar und sich verbessernd, jedes Mal, wenn jemand im Team eine Zeile zu einer SKILL.md-Datei hinzufügt.
Die Organisationen, die das früh herausfinden — die beginnen, Skills-Bibliotheken aufzubauen, die ihre Best Practices und ihr institutionelles Wissen erfassen — werden einen zusammengesetzten Vorteil haben, der jeden Monat wächst. Nicht weil die KI klüger ist. Weil die KI sie besser kennt.
Ich begann diesen Beitrag damit, über das Löschen meiner gespeicherten Prompts zu sprechen. Das war das Symptom. Die eigentliche Veränderung ist tiefer. Ich hörte auf, Claude als Tool zu betrachten, das ich instruiere, und begann, es als Teammitglied zu betrachten, das ich onboarde. Der Skills-Ordner ist das Onboarding-Handbuch. Und genau wie das Onboarding eines Menschen zahlt sich die anfängliche Investition des Schreibens klarer Anweisungen jeden Tag zurück, an dem diese Person — oder dieser Skill — auftaucht und die Arbeit erledigt, ohne zweimal gesagt zu werden.
Anthropic baute das Rahmenwerk. Die 32 Seiten legen die Mechanik dar. Aber der Wert liegt nicht im Rahmenwerk — er liegt darin, was du darin steckst.
Also ist hier meine Frage: Was ist der eine Workflow, den du jede Woche wiederholst, den du Claude einmal beibringen könntest und nie wieder erklären müsstest? Fang dort an. Ein Ordner. Eine SKILL.md. Eine Beschreibung, die tatsächlich auslöst.
Alles andere baut auf diesem ersten Skill auf, der funktioniert.
🤝 Lass Uns Zusammenarbeiten
Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe dir gerne.
- 🔗 Fiverr (Custom Builds & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Unternehmenslösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
