Claude Code Skills: Eigene Fähigkeiten erstellen
Skills erweitern Claude Code um wiederverwendbare Workflows. Lernen Sie, wie Sie Skills erstellen, konfigurieren und für Ihr Team bereitstellen.
Skills sind das Geheimrezept für produktives Arbeiten mit Claude Code. Statt bei jeder Aufgabe von vorne zu erklären, was Sie wollen, definieren Sie einmal den Workflow - und Claude führt ihn konsistent aus.
Was sind Skills?
Ein Skill ist ein wiederverwendbares Workflow-Modul. Er besteht aus:
- SKILL.md: Hauptdatei mit Anweisungen
- Templates (optional): Vorlagen für Output
- Examples (optional): Beispiele für erwartete Ergebnisse
- Scripts (optional): Ausführbare Hilfsskripte
Das Problem, das Skills lösen:
Ohne Skills:
User: Mach ein Code Review. Achte auf Security, Performance,
unseren Code Style aus .eslintrc, teste die Edge Cases...
[50 Zeilen Anweisungen]
Mit Skills:
User: /code-review src/auth/login.ts
Der Skill "erinnert" sich an alle Details.
Skills folgen dem offenen Agent-Skills-Standard, funktionieren also auch ausserhalb von Claude Code. Claude Code erweitert den Standard um eigene Features: Invocation-Kontrolle, Ausführung im Subagent und dynamische Kontext-Injektion.
Custom Commands sind Skills geworden
Wer Claude Code länger nutzt, kennt die Custom Commands unter .claude/commands/. Diese sind inzwischen in Skills aufgegangen:
.claude/commands/deploy.mdund.claude/skills/deploy/SKILL.mderzeugen beide/deploy- Beide verhalten sich identisch und unterstützen dasselbe Frontmatter
- Bestehende Command-Dateien funktionieren unverändert weiter
Bei Namensgleichheit gewinnt der Skill. Für alles Neue sind Skills die bessere Wahl, weil sie ein eigenes Verzeichnis für Templates und Scripts mitbringen und von Claude automatisch geladen werden können.
Bundled Skills
Claude Code bringt eine Reihe eigener Skills mit, unter anderem /doctor, /code-review, /debug, /batch und /loop. Seit v2.1.215 sind /verify und /code-review nur noch manuell per Slash-Command aufrufbar (kein Auto-Loading mehr). Drei weitere arbeiten zusammen, um Änderungen an der laufenden Anwendung zu prüfen statt nur an Tests:
| Skill | Zweck |
|---|---|
/run | Anwendung starten und bedienen, um eine Änderung live zu sehen |
/verify | Anwendung bauen und ausführen, um eine Code-Änderung zu bestätigen (manuell) |
/run-skill-generator | /run und /verify beibringen, wie Ihr Projekt gebaut und gestartet wird |
/run-skill-generator bringt Ihr Projekt einmal aus einer sauberen Umgebung zum Laufen und schreibt das Rezept als projekteigenen Skill nach .claude/skills/run-<name>/. Danach folgen alle Agenten im Repository denselben Schritten, statt sie jedes Mal neu zu erraten.
Einen eigenen Skill mit gleichem Namen legen Sie einfach unter .claude/skills/ ab – er ersetzt den mitgelieferten.
Skill-Anatomie
Verzeichnisstruktur
.claude/skills/code-review/
├── SKILL.md # Hauptanweisungen (erforderlich)
├── template.md # Output-Template (optional)
├── examples/
│ └── sample.md # Beispiel-Output (optional)
└── scripts/
└── validate.sh # Hilfsskript (optional)
SKILL.md Aufbau
---
name: code-review
description: Führt Code Reviews nach unseren Standards durch
argument-hint: [file-path]
user-invocable: true
allowed-tools: Read, Grep, Glob
model: sonnet
---
Du führst Code Reviews für unser Team durch.
## Prüfkriterien
1. **Sicherheit**: OWASP Top 10, Input Validation
2. **Performance**: N+1 Queries, unnötige Loops
3. **Code Style**: ESLint-Regeln aus .eslintrc
4. **Tests**: Edge Cases, Error Handling
## Output-Format
Erstelle einen Report mit:
- Severity (Critical/High/Medium/Low)
- Datei und Zeile
- Problem-Beschreibung
- Lösungsvorschlag
Frontmatter-Felder
Alle Felder sind optional. Empfohlen ist lediglich description, damit Claude weiss, wann der Skill passt.
| Feld | Erforderlich | Beschreibung |
|---|---|---|
name | Nein | Display-Name in Skill-Listen (default: Verzeichnisname). Der Befehl selbst kommt weiterhin vom Verzeichnisnamen – ausser bei Plugin-Skills |
description | Empfohlen | Was der Skill tut und wann Claude ihn nutzen soll |
when_to_use | Nein | Zusätzliche Trigger-Formulierungen, wird an description angehängt |
argument-hint | Nein | Hinweis bei Autocomplete (z.B. [file-path]) |
arguments | Nein | Benannte Positionsargumente für $name-Platzhalter |
user-invocable | Nein | false versteckt den Skill aus dem / Menu |
disable-model-invocation | Nein | true verhindert Auto-Loading durch Claude |
allowed-tools | Nein | Tools ohne Permission-Prompt – nur für den auslösenden Turn |
disallowed-tools | Nein | Tools, die Claude bei aktivem Skill gar nicht zur Verfügung stehen |
model | Nein | Modell für diesen Skill, oder inherit für das Session-Modell |
effort | Nein | Effort-Level: low, medium, high, xhigh, max |
context | Nein | fork für Subagent-Kontext |
agent | Nein | Subagent-Typ wenn context: fork |
background | Nein | Nur mit context: fork. false wartet auf das Ergebnis statt im Hintergrund zu laufen |
paths | Nein | Glob-Muster, die das automatische Laden auf passende Dateien beschränken |
hooks | Nein | Skill-spezifische Hooks |
shell | Nein | bash (default) oder powershell für Shell-Befehle im Skill |
Boolesche Felder akzeptieren neben true/false auch yes, no, on, off, 1 und 0.
Skill-Locations
Wo ein Skill liegt, bestimmt, wer ihn nutzen kann:
| Location | Pfad | Gilt für |
|---|---|---|
| Enterprise | Managed Settings | Alle Nutzer der Organisation |
| Persönlich | ~/.claude/skills/<name>/SKILL.md | Alle Ihre Projekte |
| Projekt | .claude/skills/<name>/SKILL.md | Nur dieses Projekt |
| Plugin | <plugin>/skills/<name>/SKILL.md | Wo das Plugin aktiv ist |
Bei gleichem Namen überschreibt Enterprise die persönliche Ebene, und die persönliche das Projekt. Jede dieser Ebenen ersetzt zudem einen gleichnamigen Bundled Skill. Plugin-Skills laufen unter einem eigenen Namensraum (plugin-name:skill-name) und kollidieren deshalb nie mit den anderen Ebenen.
Monorepos: Skills werden auch aus verschachtelten .claude/skills/-Verzeichnissen geladen, sobald Claude eine Datei in dem Unterverzeichnis liest oder bearbeitet. Bei Namensgleichheit bekommt die verschachtelte Variante einen qualifizierten Namen wie /apps/web:deploy, und Claude wählt die Variante, die zu den bearbeiteten Dateien passt.
Live-Änderungen: Neue oder geänderte SKILL.md-Dateien greifen ohne Neustart. Nur wenn Sie ein Skills-Verzeichnis komplett neu anlegen, das beim Session-Start noch nicht existierte, ist ein Neustart nötig.
Praktisches Beispiel: Code Review Skill
Schritt 1: Verzeichnis erstellen
mkdir -p .claude/skills/code-review
Schritt 2: SKILL.md schreiben
---
name: code-review
description: Führt ein Code Review nach internen Standards durch. Nutze diesen Skill bei Code-Änderungen.
argument-hint: [file-or-directory]
allowed-tools: Read, Grep, Glob
---
Du bist ein erfahrener Code Reviewer. Deine Aufgabe ist es,
Code-Qualität und Sicherheit zu gewährleisten.
## Prüfkriterien
### 1. Sicherheit (Kritisch)
- SQL Injection, XSS, CSRF
- Hardcoded Credentials
- Unsichere Deserialisierung
- Fehlende Input-Validierung
### 2. Performance (Hoch)
- N+1 Database Queries
- Unnötige Schleifen oder Rekursion
- Fehlende Indizes bei DB-Queries
- Memory Leaks
### 3. Code Quality (Medium)
- Einhaltung von .eslintrc / .prettierrc
- DRY-Prinzip
- Single Responsibility
- Aussagekräftige Namen
### 4. Testing (Medium)
- Edge Cases abgedeckt?
- Error Handling getestet?
- Mocking sinnvoll?
## Output-Format
Erstelle einen strukturierten Report:
| Severity | Datei:Zeile | Problem | Empfehlung |
|----------|-------------|---------|------------|
| ... | ... | ... | ... |
### Zusammenfassung
- X kritische Issues
- X wichtige Issues
- X Verbesserungsvorschläge
Insgesamt: [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]
Schritt 3: Testen
claude
> /code-review src/auth/
Fortgeschrittene Techniken
Dynamic Context Injection
Mit der Syntax !`command` führen Sie Shell-Commands aus, bevor der Skill-Inhalt an Claude geht:
---
name: pr-summary
description: Fasst einen Pull Request zusammen
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---
## PR-Kontext
### Diff
!`gh pr diff`
### Kommentare
!`gh pr view --comments`
### Geänderte Dateien
!`gh pr diff --name-only`
## Deine Aufgabe
Erstelle eine Zusammenfassung dieses PRs...
Claude sieht dann den Output dieser Commands, nicht die Commands selbst.
Zwei Details zur Syntax: Das Ausrufezeichen wird nur erkannt, wenn es am Zeilenanfang oder direkt nach einem Leerzeichen steht. Steht ein anderes Zeichen davor, etwa bei einer Zuweisung wie KEY=, bleibt der Ausdruck literaler Text und der Befehl läuft nicht. Und für mehrzeilige Befehle nutzen Sie einen Code-Block, der mit ```! geöffnet wird:
## Umgebung
```!
node --version
npm --version
git status --short
```
In Managed Settings lässt sich diese Ausführung übrigens mit "disableSkillShellExecution": true organisationsweit abschalten.
String Substitutions
| Variable | Beschreibung |
|---|---|
$ARGUMENTS | Alle übergebenen Argumente |
$ARGUMENTS[N] bzw. $N | Einzelnes Argument per Index, z.B. $0 für das erste |
$name | Benanntes Argument aus dem arguments-Frontmatter |
${CLAUDE_SESSION_ID} | Aktuelle Session-ID |
${CLAUDE_EFFORT} | Aktives Effort-Level |
${CLAUDE_SKILL_DIR} | Verzeichnis der SKILL.md – für mitgelieferte Scripts |
${CLAUDE_PROJECT_DIR} | Projekt-Wurzelverzeichnis |
---
name: explain
argument-hint: [function-name]
---
Erkläre die Funktion `$ARGUMENTS` im Detail...
${CLAUDE_SKILL_DIR} ist in der Praxis besonders nützlich, weil es auch in allowed-tools ersetzt wird. So läuft ein mitgeliefertes Script ohne Permission-Prompt, egal ob der Skill persönlich, im Projekt oder in einem Plugin installiert ist:
---
name: render-chart
description: Rendert ein Diagramm aus einer CSV-Datei
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)
---
Führe `${CLAUDE_SKILL_DIR}/scripts/render.sh <csv-datei>` aus.
Skill mit Agent kombinieren
Für komplexe Recherche-Aufgaben können Sie einen Subagent nutzen:
---
name: architecture-review
description: Analysiert Architektur-Entscheidungen
context: fork
agent: Explore
allowed-tools: Read, Grep, Glob
---
Analysiere die Architektur des Projekts und erstelle einen Report...
Der Skill läuft dann in einem isolierten Kontext und belastet nicht die Haupt-Konversation.
Der geforkte Subagent läuft standardmässig im Hintergrund: Sie arbeiten weiter, das Ergebnis kommt an, sobald es fertig ist. Wenn Sie im selben Turn auf das Resultat warten wollen, setzen Sie background: false (Claude Code ≥ v2.1.218). Zwei Dinge sind dabei zu beachten: Ein Hintergrund-Fork hat einen eingeschränkteren Tool-Satz, und seine Datei-Änderungen liegen ausserhalb der Session-Checkpoints – /rewind macht sie nicht rückgängig, dafür brauchen Sie Git.
context: fork ergibt nur bei Skills mit konkretem Auftrag Sinn. Ein Skill, der reine Richtlinien enthält ("nutze diese API-Konventionen"), gibt dem Subagenten nichts zu tun.
Skills mit Hooks
Skills können eigene Hooks definieren, die nur laufen, solange der Skill aktiv ist:
---
name: safe-edit
description: Editiert Dateien mit Backup
hooks:
PreToolUse:
- matcher: "Edit"
hooks:
- type: command
command: "${CLAUDE_PROJECT_DIR}/.claude/hooks/backup.sh"
---
Editiere die angegebene Datei...
Das Hook-Script erhält die Details des Tool-Aufrufs als JSON über stdin – es gibt keine Variablen wie $FILE im Command-String. Der Pfad der zu bearbeitenden Datei steht in tool_input.file_path:
#!/bin/bash
# .claude/hooks/backup.sh
FILE=$(jq -r '.tool_input.file_path')
[ -f "$FILE" ] && cp "$FILE" "$FILE.bak"
Skill-Ideen für Teams
1. Commit Message Generator
---
name: commit
description: Generiert Commit Messages nach Conventional Commits
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---
Analysiere die staged Changes und erstelle eine Commit Message:
Format: <type>(<scope>): <description>
Types: feat, fix, docs, style, refactor, test, chore
Halte die erste Zeile unter 72 Zeichen.
2. Test Generator
---
name: generate-tests
description: Generiert Unit Tests für eine Datei
argument-hint: [file-path]
allowed-tools: Read, Write
---
Analysiere $ARGUMENTS und erstelle umfassende Unit Tests.
Nutze das Test-Framework aus package.json.
Decke ab:
- Happy Path
- Edge Cases
- Error Handling
- Boundary Conditions
3. Documentation Writer
---
name: document
description: Erstellt oder aktualisiert Dokumentation
argument-hint: [file-or-module]
---
Erstelle/aktualisiere Dokumentation für $ARGUMENTS.
Berücksichtige:
- JSDoc/TSDoc für Funktionen
- README.md für Module
- Beispiel-Code wo sinnvoll
4. PR Creator
---
name: create-pr
description: Erstellt einen Pull Request mit Beschreibung
context: fork
disable-model-invocation: true
---
## Änderungen
!`git diff main...HEAD --stat`
## Commits
!`git log main...HEAD --oneline`
---
Erstelle einen PR mit:
- Aussagekräftigem Titel
- Beschreibung der Änderungen
- Test-Anweisungen
- Screenshots (falls UI-Änderungen)
Skills vs CLAUDE.md vs Hooks
| Feature | Zweck | Aktivierung |
|---|---|---|
| CLAUDE.md | Allgemeine Projekt-Anweisungen | Immer geladen |
| Skills | Spezialisierte Workflows | Bei Bedarf (auto oder manuell) |
| Hooks | Automatische Aktionen | Bei bestimmten Events |
Faustregel:
- CLAUDE.md für "wie wir hier arbeiten"
- Skills für "wiederkehrende Aufgaben"
- Hooks für "muss immer passieren"
Was passiert mit dem Skill-Inhalt?
Ein Punkt, der in der Praxis oft überrascht: Wird ein Skill aufgerufen, landet sein gerenderter Inhalt als Nachricht in der Konversation und bleibt dort für den Rest der Session. Claude Code liest die Datei nicht bei jedem Turn neu ein.
Daraus folgen drei praktische Konsequenzen:
- Jede Zeile kostet dauerhaft Tokens. Halten Sie den Body knapp – schreiben Sie, was zu tun ist, nicht warum. Ausführliches Referenzmaterial gehört in separate Dateien im Skill-Verzeichnis, die Claude nur bei Bedarf liest.
- Formulieren Sie Anweisungen als Dauerregeln, nicht als einmalige Schritte, wenn sie über die ganze Aufgabe gelten sollen.
- Der
allowed-tools-Zugriff ist die Ausnahme: Er gilt nur für den auslösenden Turn und verfällt mit Ihrer nächsten Nachricht, auch wenn der Skill-Inhalt im Kontext bleibt.
Wenn ein Skill nach der ersten Antwort scheinbar keine Wirkung mehr hat, ist der Inhalt meist noch da – Claude wählt nur andere Wege. Dann hilft eine präzisere description, ein Hook für hartes Durchsetzen, oder ein erneuter Aufruf nach einer Kontext-Komprimierung.
Best Practices
1. Fokussiert halten
Ein Skill = eine Aufgabe. Lieber mehrere kleine Skills als ein Mega-Skill. Als Faustregel: SKILL.md unter 500 Zeilen halten.
2. Gute Descriptions
Die description bestimmt, wann Claude den Skill automatisch nutzt. Seien Sie präzise:
# Schlecht
description: Hilft bei Code
# Gut
description: Führt Code Reviews nach OWASP-Standards durch.
Nutze bei PR-Reviews und vor Deployments.
Setzen Sie den wichtigsten Anwendungsfall nach vorne. Claude Code lädt eine Liste aller Skill-Namen und -Beschreibungen in den Kontext, und diese Liste hat ein Zeichenbudget. Bei vielen Skills werden Beschreibungen gekürzt – zuerst bei den selten genutzten. /doctor zeigt Ihnen, wie viel Kontext die Liste kostet und welche Skills die grössten Posten sind.
Wer Trigger-Formulierungen sauber trennen will, nutzt zusätzlich when_to_use:
description: Führt Code Reviews nach OWASP-Standards durch.
when_to_use: Bei PR-Reviews, vor Deployments, wenn nach Sicherheitslücken gefragt wird.
3. Beispiele mitliefern
Ein examples/ Ordner mit Beispiel-Outputs hilft Claude, das gewünschte Format zu verstehen.
4. Team-Skills dokumentieren
Führen Sie eine Liste der verfügbaren Skills in Ihrer README:
## Verfügbare Claude Code Skills
- `/code-review` - Code Review nach internen Standards
- `/commit` - Commit Message Generator
- `/document` - Dokumentation erstellen
5. Sichtbarkeit ohne Datei-Änderung steuern
Bei Skills aus einem geteilten Repository wollen Sie die SKILL.md oft nicht anfassen. Dafür gibt es die Einstellung skillOverrides, die das /skills-Menu für Sie schreibt:
{
"skillOverrides": {
"legacy-context": "name-only",
"deploy": "off"
}
}
Vier Zustände sind möglich: on (Standard), name-only (nur der Name wird Claude gezeigt), user-invocable-only (nur im / Menu sichtbar) und off (komplett versteckt).
6. Wirkung messen statt vermuten
Dass ein Skill auslöst, heisst noch nicht, dass er das Richtige tut. Der belastbare Test ist ein Vergleich: dieselbe Aufgabe je einmal in einer frischen Session mit und ohne Skill. Frisch deshalb, weil Kontext aus dem Entwickeln des Skills Lücken in den Anweisungen überdeckt.
Das offizielle skill-creator-Plugin automatisiert diesen Vergleich – inklusive Trefferquote der description und A/B-Test zwischen zwei Skill-Versionen:
/plugin install skill-creator@claude-plugins-official
Fazit
Skills transformieren repetitive Aufgaben in Ein-Wort-Befehle. Starten Sie mit einem Skill für Ihre häufigste Aufgabe - sei es Code Review, Commit Messages oder Dokumentation.
Mit der Zeit bauen Sie eine Bibliothek von Skills auf, die genau zu Ihrem Workflow passt.
Weiterführende Artikel:
- Claude Code: Der komplette Überblick - Alle Features im Überblick
- Claude Code Agents verstehen - Sub-Agenten für komplexe Aufgaben
- Claude Code Hooks konfigurieren - Event-Automatisierung
- CLAUDE.md Best Practices - Projekt-Konfiguration
Sie möchten Skills für Ihr Entwicklungsteam erstellen? Hedinger-Digital unterstützt bei der Konzeption und Implementierung von Team-spezifischen Workflows - Softwareentwicklung bei Hedinger-Digital. Geht es um den KI-Einsatz über die Entwicklung hinaus, ist die KI-Beratung für KMU der passende Einstieg.


