Skills & Workflows erstellen
Level 2 | 30 Minuten
Erweitere Claude Code mit eigenen Skills und automatisierten Workflows
Lernziele
- Den Unterschied zwischen Skills und Slash-Commands verstehen
- Eigene Skills erstellen und konfigurieren
- Workflow-Orchestration implementieren
- Community Skills nutzen
Skills vs. Slash Commands
Seit Version 2.1.3 von Claude Code hat sich das Konzept der Erweiterungen weiterentwickelt. Skills und Slash Commands erfüllen ähnliche Zwecke, unterscheiden sich aber grundlegend in der Art wie sie funktionieren. Diesen Unterschied zu verstehen ist wichtig, damit du das richtige Werkzeug für die richtige Aufgabe wählst. Slash Commands sind manuelle Auslöser. Du tippst /commandname und Claude führt die hinterlegte Anweisung aus. Das ist wie ein Knopfdruck: Du entscheidest wann der Command ausgeführt wird, und er tut genau das was in der Markdown-Datei steht. Slash Commands eignen sich perfekt für wiederkehrende Aufgaben die du bewusst starten willst — Code Review, Test-Generierung, Deployment-Vorbereitung. Skills hingegen sind intelligenter. Sie sind Wissensmodule die Claude AUTOMATISCH lädt wenn sie für den aktuellen Task relevant sind. Stell dir Skills wie Fachbücher in einer Bibliothek vor: Claude geht zur Bibliothek, sucht das relevante Buch, und nutzt das Wissen daraus. Du musst nicht sagen 'benutze den Testing-Skill' — wenn du Claude bittest Tests zu schreiben und ein Testing-Skill existiert, wird er automatisch geladen. Der technische Unterschied: Slash Commands sind Markdown-Dateien in .claude/commands/ die du per /projekt:name aufrufst. Skills sind Markdown-Dateien mit SKILL.md als Name in .claude/skills/ oder .cursor/skills/ Verzeichnissen, die eine Beschreibung haben wann sie relevant sind. Skills haben noch einen weiteren Vorteil: Progressive Disclosure. Der Skill selbst kann weitere Dateien referenzieren die nur bei Bedarf geladen werden. Das spart Context Window — der Skill-Titel und die Beschreibung sind immer sichtbar (wenige Tokens), aber der vollständige Inhalt wird erst geladen wenn er gebraucht wird. Mein Empfehlung: Nutze Slash Commands für Aktionen die du bewusst auslösen willst (/deploy, /review, /test). Nutze Skills für Wissen und Workflows die Claude automatisch anwenden soll (Testing-Standards, Code-Style-Regeln, Architektur-Patterns).
SKILLS VS SLASH COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━
SLASH COMMANDS (/command)
├── Manuell vom User aufgerufen
├── Direkte Terminal-Shortcuts
├── Für spezifische, wiederholbare Tasks
└── Beispiele: /commit, /review, /test
SKILLS
├── Von Claude automatisch erkannt
├── Dynamisch angewendet wenn relevant
├── Können auch manuell aufgerufen werden
├── Strukturierte Capability-Definitionen
└── Beispiele: code-review-skill, deploy-skill
💡 Skills sind die Evolution von Slash Commands!Skill erstellen
Einen eigenen Skill zu erstellen ist überraschend einfach. Jeder Skill ist eine Markdown-Datei namens SKILL.md, die in einem bestimmten Verzeichnis liegt und ein optionales YAML-Frontmatter hat. Der Inhalt kann alles sein: Wissen, Regeln, Workflows, Code-Templates oder Anleitungen. Denk an einen Skill wie an eine detaillierte Anleitung die du einem neuen Teammitglied geben würdest. 'So schreiben wir Tests in diesem Projekt', 'So funktioniert unser Deployment', 'Diese Regeln gelten für unsere API'. Jedes Mal wenn Claude auf eine Aufgabe trifft die zu einem deiner Skills passt, lädt es die Anleitung automatisch und folgt ihr. Die Struktur einer SKILL.md Datei besteht aus zwei Teilen: Dem Frontmatter (optional, zwischen --- Markierungen) und dem eigentlichen Inhalt. Im Frontmatter definierst du Metadaten wie eine Beschreibung, erlaubte Tools und ob der Skill manuell oder automatisch ausgelöst wird. Die Beschreibung im Frontmatter ist der wichtigste Teil — sie entscheidet ob und wann Claude den Skill lädt. Nutze das WHEN/WHEN NOT Pattern: 'WHEN: Writing or reviewing test files. WHEN NOT: Quick one-off scripts or prototypes.' Das gibt Claude klare Kriterien wann der Skill relevant ist. Der Inhalt selbst sollte klar strukturiert sein: Was soll Claude tun? Welche Regeln gelten? Welche Schritte sollen befolgt werden? Welche Fehler sollen vermieden werden? Je konkreter und spezifischer der Inhalt, desto besser die Ergebnisse. Ein praktischer Tipp: Starte mit einem einfachen Skill und verfeinere ihn iterativ. Erstelle eine erste Version, nutze sie ein paar Tage, identifiziere was fehlt oder was Claude falsch macht, und verbessere den Skill. Nach 2-3 Iterationen ist ein Skill typischerweise deutlich besser als die erste Version.
# .claude/skills/code-review/SKILL.md
---
name: code-review
description: Führt ein detailliertes Code Review durch
invocation: user # 'user' = manuell, 'auto' = automatisch
triggers:
- "review"
- "code review"
- "prüfe den code"
---
# Code Review Skill
Du bist ein erfahrener Code Reviewer. Wenn dieser Skill aktiviert wird:
## Ablauf
1. Datei identifizieren
- Frage welche Datei(en) reviewed werden sollen
- Oder nutze die zuletzt geänderten Dateien
2. Review durchführen
Prüfe auf:
- [ ] Bugs und Logic Errors
- [ ] Performance-Probleme
- [ ] Security Vulnerabilities
- [ ] Code Style und Conventions
- [ ] TypeScript Typen
- [ ] Test Coverage
3. Feedback formatieren
Skill-Verzeichnisstruktur
Skills können an verschiedenen Orten gespeichert werden, und jeder Ort hat eine andere Reichweite — ähnlich wie bei CLAUDE.md Dateien gibt es eine Hierarchie von global bis projekt-lokal. Wo du einen Skill ablegst, bestimmt wer ihn nutzen kann und wann er geladen wird. Das globale Verzeichnis ist ~/.claude/skills/. Skills hier sind in ALLEN deinen Projekten verfügbar. Perfekt für persönliche Vorlieben die projektübergreifend gelten: Dein bevorzugter Code-Style, deine Testing-Philosophie, oder dein Workflow für Git-Commits. Diese Skills gehören nur dir und werden nicht mit dem Team geteilt. Das Projekt-Verzeichnis ist .claude/skills/ im Projektstamm. Skills hier gehören zum Projekt und werden typischerweise ins Git-Repository committed. Das ist der richtige Ort für projektspezifische Regeln: Welches Framework wird wie genutzt, welche Architektur-Patterns gelten, wie sehen Tests aus. Jedes Teammitglied bekommt diese Skills automatisch. Seit den letzten Updates unterstützt Claude Code auch .cursor/skills/ — das ist besonders relevant wenn du Cursor IDE nutzt. Skills in diesem Verzeichnis werden sowohl von Claude Code als auch von Cursor erkannt. Jeder Skill liegt in einem eigenen Unterordner mit einer SKILL.md Datei. Der Ordnername dient als Identifier. Du kannst zusätzliche Dateien im selben Ordner ablegen — Referenzdokumente, Code-Templates, Konfigurationsbeispiele — die der Skill bei Bedarf laden kann. Die Verzeichnisstruktur folgt dem Wrapper-Pattern: Die SKILL.md selbst ist klein und beschreibt was der Skill tut (wenige Tokens). Die eigentliche Logik und das Detailwissen liegen in separaten Dateien die nur geladen werden wenn der Skill tatsächlich genutzt wird. Das spart enormen Context-Platz. Mein Empfehlung für die Organisation: Ein Ordner pro Fachgebiet. Zum Beispiel: testing/, deployment/, code-review/, api-design/. So bleibt die Struktur übersichtlich, auch wenn du viele Skills hast.
SKILL DIRECTORY STRUCTURE
━━━━━━━━━━━━━━━━━━━━━━━━━
.claude/
└── skills/
├── code-review/
│ ├── SKILL.md # Hauptdatei (erforderlich)
│ ├── templates/ # Optionale Templates
│ │ └── review.md
│ └── prompts/ # Optionale Prompts
│ └── security.md
│
├── deploy/
│ ├── SKILL.md
│ └── scripts/
│ └── deploy.sh
│
└── testing/
├── SKILL.md
└── fixtures/
└── test-data.jsonYAML Frontmatter Optionen
Das YAML-Frontmatter am Anfang einer SKILL.md Datei ist optional, aber mächtig. Es steuert das Verhalten des Skills: Wann wird er geladen? Welche Tools darf er nutzen? In welchem Kontext soll er laufen? Ohne Frontmatter funktioniert ein Skill trotzdem, aber mit Frontmatter hast du viel mehr Kontrolle. Die wichtigste Option ist die Beschreibung (description). Sie erklärt Claude in einem Satz, was der Skill tut und wann er relevant ist. Diese Beschreibung wird IMMER geladen — auch wenn der Skill selbst noch nicht aktiv ist. Claude liest alle Skill-Beschreibungen und entscheidet basierend darauf, welche Skills für die aktuelle Aufgabe relevant sind. Die zweitwichtigste Option sind die erlaubten Tools (allowed_tools). Damit bestimmst du welche Claude Code Tools der Skill nutzen darf. Ein Code-Review Skill braucht vielleicht nur Read und Grep, während ein Deployment-Skill auch Bash und Write benötigt. Indem du die Tools einschränkst, erhöhst du die Sicherheit. Mit der trigger Option bestimmst du ob der Skill automatisch (auto) oder nur manuell per Slash-Command (manual) geladen wird. Automatische Skills werden geladen wenn Claude die Beschreibung als relevant einstuft. Manuelle Skills werden nur per /skillname aufgerufen. Die agent Option ermöglicht es, den Skill als Subagent in isoliertem Kontext auszuführen. Das ist nützlich für ressourcenintensive Skills die viele Dateien lesen: Der Skill läuft in seinem eigenen Context Window und gibt nur die Ergebnisse zurück, ohne deinen Hauptkontext zu belasten. Weitere nützliche Optionen: model (welches Claude-Modell der Skill nutzen soll — z.B. Haiku für günstige Exploration), max_tokens (maximale Ausgabelänge), und files (Dateien die automatisch mitgeladen werden sollen). Mein Praxis-Tipp: Starte ohne Frontmatter und füge Optionen erst hinzu wenn du sie brauchst. Die Beschreibung ist die einzige Option die du von Anfang an setzen solltest — sie ist der Schlüssel zu guter automatischer Skill-Erkennung.
---
# Basis-Konfiguration
name: my-skill # Eindeutiger Name
description: Was der Skill tut # Kurzbeschreibung
# Aufruf-Modus
invocation: user # 'user' oder 'auto'
# Trigger-Wörter (für auto-invocation)
triggers:
- "keyword1"
- "keyword2"
# Tool-Einschränkungen
allowed_tools:
- Read
- Edit
- Bash
# Modell-Präferenz
preferred_model: sonnet # haiku, sonnet, opus
# Kontext-Dateien automatisch laden
context_files:
- "src/config/*.ts"
- "package.json"
# Dependencies (andere Skills)
requires:
- git-workflow
---Workflow Orchestration
Workflows sind Skills auf Steroiden. Während ein einfacher Skill Claude Wissen oder Regeln bereitstellt, orchestriert ein Workflow-Skill einen kompletten mehrstufigen Prozess — von der Analyse über die Implementierung bis zur Verifikation. Stell dir einen Workflow vor wie ein Kochrezept: nicht nur die Zutaten (Wissen), sondern auch die Schritt-für-Schritt Anleitung. Ein typischer Workflow-Skill könnte so aussehen: Der /deploy Workflow (1) prüft ob alle Tests grün sind, (2) erstellt einen Release-Branch, (3) aktualisiert die Versionsnummer, (4) generiert Release Notes aus den Commits, (5) erstellt einen Tag und (6) triggert die Deployment Pipeline. Sechs Schritte die du sonst manuell und fehleranfällig durchführen würdest. Der Schlüssel zu guten Workflow-Skills ist die richtige Balance zwischen Automation und Kontrolle. Nicht jeder Schritt sollte automatisch ablaufen — bei kritischen Entscheidungen sollte der Workflow pausieren und dich fragen. 'Die Tests sind fehlgeschlagen. Soll ich trotzdem fortfahren?' Das verhindert, dass Fehler sich durch den gesamten Workflow propagieren. Workflow-Skills nutzen oft das Subagent-Pattern: Der Hauptworkflow orchestriert, und einzelne Schritte werden an Subagents delegiert die in isoliertem Kontext arbeiten. So bleibt der Hauptkontext sauber und jeder Schritt hat seinen eigenen frischen Kontext. Zum Beispiel: Der Test-Step läuft als Subagent, der Code-Review als weiterer, und die Release-Note-Generierung als dritter. Beim Erstellen von Workflow-Skills empfehle ich die Top-Down Methode: Definiere zuerst die Schritte als Liste, dann fülle jeden Schritt mit Details. Beginne mit dem Happy Path (alles läuft glatt), und füge dann Fehlerbehandlung und Edge Cases hinzu. Teste den Workflow mehrmals mit unterschiedlichen Szenarien. Ein häufiger Fehler: Workflows die zu viel automatisieren. Wenn ein Schritt fehlschlägt und der Workflow trotzdem weiterläuft, kann das größeren Schaden anrichten als manuelle Arbeit. Baue Checkpoints ein.
# .claude/skills/feature-workflow/SKILL.md
---
name: feature-workflow
description: Kompletter Feature-Development Workflow
invocation: user
triggers: ["neues feature", "feature erstellen"]
---
# Feature Development Workflow
Dieser Workflow orchestriert die komplette Feature-Entwicklung.
## Phase 1: Analyse
1. Requirements sammeln
2. Betroffene Dateien identifizieren
3. Implementation-Plan erstellen
## Phase 2: Implementation
Nutze Subagents für parallele Arbeit:
Community Skills nutzen
Du musst nicht jedes Rad neu erfinden. Die Claude Code Community hat bereits hunderte Skills erstellt und geteilt — von einfachen Code-Style-Regeln bis zu komplexen Multi-Step-Workflows. Der Marketplace und GitHub sind die beiden Hauptquellen für Community Skills. Der offizielle Marketplace ist die einfachste Quelle. Hier findest du kuratierte, getestete Skills die du mit einem einzigen Befehl installieren kannst. Die Skills sind nach Kategorien sortiert: Testing, Deployment, Code Review, Documentation, und viele mehr. Jeder Skill hat eine Beschreibung, Bewertungen und Nutzungsstatistiken. Auf GitHub findest du zusätzlich das awesome-claude-code Repository — eine kuratierte Liste mit über 22.000 Stars (Stand Februar 2026). Hier sind nicht nur Skills, sondern auch Hooks, Commands, Agent-Konfigurationen und komplette Plugin-Packages gelistet und beschrieben. Bei der Auswahl von Community Skills solltest du auf drei Dinge achten: Erstens, lies die Beschreibung genau und stelle sicher, dass der Skill zu deinem Projekt passt. Ein React-Testing-Skill nützt dir nichts wenn du Vue verwendest. Zweitens, prüfe die Aktualität — Skills die seit Monaten nicht aktualisiert wurden, funktionieren möglicherweise nicht mit der neuesten Claude Code Version. Drittens, lies den Skill-Inhalt bevor du ihn nutzt — ein Skill ist letztendlich ein Prompt, und du solltest wissen was er Claude anweist. Besonders empfehlenswert ist der Superpowers Plugin, der seit November 2025 die Art wie viele Entwickler mit Claude Code arbeiten fundamental verändert hat. Er enthält hochoptimierte Skills für die häufigsten Entwicklungsaufgaben. Nachdem du einen Community Skill installiert hast, empfehle ich dir ihn an dein Projekt anzupassen. Ändere die Pfade, passe die Konventionen an, füge projektspezifische Regeln hinzu. Ein angepasster Community Skill ist fast immer besser als die Standardversion.
# Skills von GitHub installieren
cd .claude/skills
git clone https://github.com/user/awesome-skill
# Oder einzelne Skill-Datei kopieren
curl -o .claude/skills/review/SKILL.md \
https://raw.githubusercontent.com/user/skills/main/review/SKILL.md
# Beliebte Community-Ressourcen:
# - github.com/hesreallyhim/awesome-claude-code
# - github.com/qdhenry/Claude-Command-Suite
# - github.com/wshobson/commands💡 Best Practices für Skills 1. Ein Zweck pro Skill - Halte Skills fokussiert 2. Klare Trigger - Eindeutige Aktivierungswörter 3. Gute Dokumentation - Der Markdown-Teil ist die Anleitung 4. Fehlerbehandlung - Beschreibe was bei Problemen passiert 5. Beispiele inkludieren - Zeige erwarteten Input/Output
Praktisches Beispiel: Test-Skill
Lass uns Theorie in Praxis umwandeln und gemeinsam einen konkreten Skill bauen. Wir erstellen einen Test-Generator-Skill der automatisch Unit Tests für geänderte Dateien schreibt — und dabei deine projektspezifischen Test-Konventionen befolgt. Dieses Beispiel zeigt dir den gesamten Prozess von der Idee bis zum fertigen Skill. Der Ausgangspunkt: In deinem Projekt nutzt du Jest mit React Testing Library, Tests liegen im __tests__ Ordner neben den Quelldateien, Dateinamen folgen dem Muster ComponentName.test.tsx, und ihr nutzt das AAA-Pattern (Arrange-Act-Assert). Diese Konventionen soll Claude automatisch anwenden wenn es Tests schreibt. Der Skill besteht aus einer SKILL.md Datei mit Frontmatter und strukturiertem Inhalt. Im Frontmatter setzen wir: description für die automatische Erkennung ('WHEN: User asks to write, add, or update tests. WHEN NOT: Quick exploratory code or prototypes.'), und allowed_tools auf Read, Write, Grep und Bash. Der Skill-Inhalt ist in Abschnitte gegliedert: Zuerst die Grundregeln (Framework, Dateistruktur, Naming), dann die Test-Struktur (AAA Pattern, describe/it Blöcke), dann Edge Cases die immer geprüft werden sollen (leere Eingaben, Null-Werte, Fehler), und schließlich was NICHT getestet werden soll (triviale Getter, rein visuelle Dinge). Besonders wertvoll ist der Abschnitt mit Beispiel-Tests: Du zeigst Claude anhand von 2-3 konkreten Tests wie ein 'guter Test' in eurem Projekt aussieht. Claude lernt daraus das Pattern und wendet es konsistent auf neue Tests an. Nachdem du den Skill erstellt hast, teste ihn: Ändere eine Komponente und bitte Claude Tests zu schreiben. Prüfe ob die Konventionen eingehalten werden. Wenn nicht, verfeinere den Skill. Typischerweise brauchst du 2-3 Iterationen bis der Skill zuverlässig funktioniert. Der fertige Skill spart dir täglich 15-30 Minuten Test-Schreibarbeit und — viel wichtiger — er stellt sicher dass alle Tests im Projekt konsistent sind, egal wer sie schreibt.
# .claude/skills/smart-test/SKILL.md
---
name: smart-test
description: Intelligentes Testing basierend auf Code-Änderungen
invocation: auto
triggers: ["test", "teste", "tests ausführen"]
allowed_tools: [Read, Bash, Edit]
---
# Smart Test Skill
Analysiere Änderungen und führe relevante Tests aus.
## Ablauf
1. Änderungen erkennen