Agent Skills

Skills sind wiederverwendbare Fähigkeiten, die Claude je nach Kontext automatisch erkennt und einsetzt. Sie sind mächtiger als einfache Befehle: Sie unterstützen progressives Laden, um leichtgewichtig zu bleiben, dynamische Injektion von Shell-Kontext, Subagent-Isolation und Aufrufsteuerung. Dieses Modul zeigt dir, wie du effektive Skills entwirfst und erstellst.

Wie Skills geladen werden

Claude hält das Laden von Skills leichtgewichtig. Skill-Beschreibungen werden geladen, damit Claude weiß, welche Fähigkeiten verfügbar sind. Der vollständige SKILL.md Inhalt wird erst geladen, wenn der Skill aufgerufen wird, und unterstützende Dateien werden nur bei Bedarf gelesen.

Das bedeutet, du kannst viele Skills installieren, ohne das Context Window zu überfluten. Claude weiß anhand ihrer Beschreibungen, dass sie existieren, und lädt die eigentlichen Anweisungen erst für die Skills, die es tatsächlich einsetzen will.

Skills liegen in .claude/skills/<name>/SKILL.md für den Projekt-Scope (in git eingecheckt) oder ~/.claude/skills/<name>/SKILL.md für den persönlichen Scope. Plugin-Skills nutzen einen plugin-name:skill-name -Namespace, sodass sie nicht mit Projekt- oder persönlichen Skills kollidieren. Wenn Nicht-Plugin-Skills denselben Namen tragen, lautet die Prioritätsreihenfolge enterprise > personal > project.

Claude erkennt außerdem automatisch Skills aus verschachtelten .claude/skills/ -Verzeichnissen in Unterverzeichnissen des Projekt-Roots. Wenn du zum Beispiel innerhalb von packages/frontend/arbeitest, findet Claude auch Skills, die definiert sind in packages/frontend/.claude/skills/. So lassen sich Skills leicht neben bestimmten Paketen oder Services in Monorepo-Setups ablegen.

.claude/skills/code-review/
├── SKILL.md              # Instructions (required)
├── templates/
│   └── review-checklist.md
└── scripts/
    └── analyze-metrics.py

Effektive Skill-Beschreibungen schreiben

Das description-Feld ist der wichtigste Teil eines Skills. Es steuert, wann Claude den Skill automatisch aufruft, und muss genügend Signal enthalten, damit Claude ihn mit echten Nutzeranfragen abgleichen kann. Eine vage Beschreibung wie „hilft bei Code“ wird nie auslösen. Eine spezifische Beschreibung mit konkreten Trigger-Begriffen funktioniert:

---
name: security-review
description: Scan code for security vulnerabilities including injection flaws, authentication issues, and data exposure. Use when reviewing code changes, preparing a PR, or when the user mentions security, vulnerabilities, or audit.
---

Nenne den Aufgabentyp („scan“, „generate“, „analyze“), die Fachdomäne („security“, „API“, „database“) und explizite Trigger-Phrasen („when the user mentions“, „use when“). Die Skill-Liste kürzt bei jedem Eintrag den kombinierten description plus when_to_use -Text bei 1.536 Zeichen ab, stelle also den zentralen Anwendungsfall nach vorn und verschiebe überzählige Trigger-Phrasen in when_to_use:

---
name: security-review
description: Scan code for security vulnerabilities including injection flaws, authentication issues, and data exposure.
when_to_use: When reviewing code changes, preparing a PR, or when the user mentions security, vulnerabilities, or audit.
---

Claude bemisst den gesamten Platz für Skill-Beschreibungen standardmäßig auf etwa 1 % des Context Windows des Modells. Erhöhe ihn mit der Einstellung skillListingBudgetFraction (z. B. 0.02 = 2 %) oder der SLASH_COMMAND_TOOL_CHAR_BUDGET -Umgebungsvariable für eine feste Zeichenanzahl. Führe /doctor aus, um zu prüfen, ob das Budget überläuft und welche Skills aus der Liste fallen.

Unterstützende Dateien erweitern den Skill, ohne den Level-2-Kontext aufzublähen. Verweise auf sie aus SKILL.md mit relativen Pfaden:

For the full review checklist, see [templates/review-checklist.md](templates/review-checklist.md).

Claude liest unterstützende Dateien bei Bedarf mit bash. Halte SKILL.md unter 500 Zeilen; lege detailliertes Referenzmaterial in separaten Dateien ab.

Dynamischer Kontext und Aufrufsteuerung

Das !command -Syntax führt Shell-Befehle aus, bevor der Skill-Inhalt Claude erreicht. Die Ausgabe wird inline eingefügt — Claude sieht nur das Ergebnis, nicht den Befehl. So gibst du Skills Live-Kontext:

---
name: pr-summary
description: Summarize pull request changes. Use when asked to review or summarize a PR.
context: fork
agent: Explore
---

## PR context
- Diff: !`gh pr diff`
- Comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

Summarize the intent and key changes in this pull request.

Das shell -Feld gibt an, welche Shell für !command -Blöcke verwendet wird. Setze es auf powershell statt des Standardwerts bash , wenn das PowerShell-Tool aktiviert ist über CLAUDE_CODE_USE_POWERSHELL_TOOL=1. Unter Linux und macOS erfordert die Aktivierung außerdem pwsh in deinem PATH:

---
name: windows-helper
description: Manage Windows services and configurations
shell: powershell
---

Zwei Frontmatter-Felder steuern, wer einen Skill aufrufen kann. disable-model-invocation: true bedeutet, dass nur der Benutzer ihn aufrufen kann über /skill-name — Claude löst ihn nie automatisch aus. Verwende das für jeden Skill mit Seiteneffekten (Deploys, Pushes, Sends). user-invocable: false verbirgt den Skill vor dem / -Menü, lässt Claude ihn aber weiterhin automatisch aufrufen — gut für Hintergrundwissen-Skills, die als Befehle nicht ausführbar sind.

paths: akzeptiert eine YAML-Liste von Globs, die eingrenzen, wann ein Skill gilt. Wenn gesetzt, lädt der Skill nur, wenn das Arbeitsverzeichnis mit einem der Globs übereinstimmt. So verschmutzen projektspezifische Skills keine unabhängigen Sessions:

---
name: api-generator
description: Generate REST API endpoints from schema definitions.
paths: ["src/**/*.ts", "tests/**"]
---

effort steuert die Reasoning-Tiefe für den Skill. Die Werte sind low, medium, high, xhigh, und max (nur für die Session). Nutze low für schnelle Nachschlagevorgänge oder Boilerplate-Generierung, medium für die meisten Aufgaben und high für tiefe Analysen, die sorgfältiges Reasoning erfordern:

---
name: security-review
description: Scan code for security vulnerabilities.
effort: high
---

context: fork führt den Skill in einem isolierten Subagent mit eigenem Context Window aus. Das agent -Feld gibt den Agent-Typ an: Explore für rein lesende Recherche, Plan für Planung, general-purpose für alles, was alle Tools benötigt. Die Hauptkonversation bleibt sauber, während der Subagent die schwere Arbeit erledigt.

Das model -Feld gibt an, welches Modell verwendet wird, wenn der Skill aktiv ist. Das ist nützlich, wenn eine Aufgabe von den Stärken eines bestimmten Modells profitiert (z. B. opus für komplexes Reasoning, sonnet für schnelle Ausführung):

---
name: deep-analysis
description: Thoroughly analyze the codebase for a specific pattern or issue
context: fork
agent: Explore
model: opus
disable-model-invocation: true
---

Analyze $ARGUMENTS across the entire codebase:
1. Use Glob and Grep to find all occurrences
2. Read each file and understand context
3. Summarize patterns, inconsistencies, and recommendations

Argumente und Tool-Zugriff

Skills nehmen Argumente auf zwei Arten entgegen. $ARGUMENTS erfasst alles nach dem Befehlsnamen als einzelnen String. $0, $1, $2 erfassen einzelne, durch Leerzeichen getrennte Argumente. Du kannst auch benannte Argumente deklarieren mit dem arguments -Frontmatter-Feld — Namen bilden auf Positionen ab, sodass $issue zum ersten Argument expandiert und $branch zum zweiten. Alle Ersetzungen erfolgen, bevor der Prompt Claude erreicht. argument-hint verbessert die Autovervollständigung im Slash-Menü, indem es anzeigt, welche Argumente ein Skill erwartet:

---
name: review-pr
description: Review a GitHub PR by number
argument-hint: "<pr-number> <priority>"
allowed-tools: Bash(gh *), Read, Grep, Glob
---

Review PR #$0 with priority $1. Focus on security and performance.

Reference our standards in [standards/code-review.md](standards/code-review.md).

Verwendung: /review-pr 456 high — $0 wird zu 456, $1 wird zu high.

allowed-tools gewährt die Berechtigung für die aufgeführten Tools, solange der Skill aktiv ist — es schränkt nicht ein, welche Tools verfügbar sind. Deine Berechtigungseinstellungen regeln weiterhin nicht aufgeführte Tools.

Über Positionsargumente hinaus unterstützen Skills integrierte Ersetzungsvariablen: ${CLAUDE_SESSION_ID} für die aktuelle Session-ID (nützlich fürs Logging), ${CLAUDE_EFFORT} für das aktive Effort-Level und ${CLAUDE_SKILL_DIR} für das Verzeichnis, das die SKILL.md -Datei des Skills enthält (nutze es, um auf gebündelte Skripte unabhängig vom Arbeitsverzeichnis zu verweisen).

Ältere Befehlsdateien in .claude/commands/*.md funktionieren weiterhin, aber Skills sind das empfohlene Format. Wenn beide mit demselben Namen existieren, hat der Skill Vorrang.

Overrides für die Skill-Sichtbarkeit

Das skillOverrides Einstellung in settings.json steuert die Skill-Sichtbarkeit, ohne das eigene Frontmatter des Skills zu bearbeiten. Das ist nützlich für geteilte Projekt-Skills oder von Plugins bereitgestellte Skills, die du nicht verändern kannst. Das /skills -Menü lässt dich die Zustände interaktiv durchschalten — hebe einen Skill hervor, drücke Space zum Durchschalten, dann Enter zum Speichern in .claude/settings.local.json:

{
  "skillOverrides": {
    "legacy-context": "name-only",
    "deploy": "off"
  }
}

Werte: "on" (Standard — vollständige Auflistung), "name-only" (Name sichtbar, aber Beschreibung verborgen), "user-invocable-only" (vor Claude verborgen, aber im / -Menü), "off" (überall verborgen).

Integrierte Skills

Claude Code enthält eine Reihe gebündelter Skills, die in jeder Session verfügbar sind, darunter /code-review, /batch, /debug, /loop, und /claude-api. Drei weitere gebündelte Skills — /run, /verify, und /run-skill-generator — erfordern v2.1.145+ und arbeiten zusammen, um deine App zu starten und Änderungen gegen die laufende App statt nur gegen Tests zu bestätigen:

/run und /verify leiten den Start aus deinem Projekttyp (CLI, Server, TUI, browsergesteuert) ab und aus package.json, Makefileoder deiner README. Für Projekte, die mehr als einen Standardstart brauchen — eine Datenbank, eine env-Datei, einen mehrstufigen Build — führe /run-skill-generator einmal aus. Es bringt deine App aus einer sauberen Umgebung zum Laufen, hält fest, was funktioniert hat, und checkt es als projektspezifischen Skill ein unter .claude/skills/run-<name>/. Danach /run und /verify folgen dem aufgezeichneten Rezept, statt zu raten.

/fewer-permission-prompts durchsucht deine Konversations-Transkripte nach häufigen, rein lesenden Bash- und MCP-Tool-Aufrufen und schlägt dann eine priorisierte Allowlist vor für deine .claude/settings.json. Führe es nach ein paar Sessions aus, um eine auf deinen tatsächlichen Workflow zugeschnittene Berechtigungskonfiguration zu erzeugen:

/fewer-permission-prompts