Agent Skills in Claude Code: Das fortgeschrittene Handbuch

Agent Skills in Claude Code: Das fortgeschrittene Handbuch

Die Skill hat meine Hauptsession zerstört. Kein sanfter Fehler — keine "hmm, das sah nicht ganz richtig aus"-Situation. Ich spreche von einem 47.000-Token Context Window, das in acht Sekunden verschlungen wurde, weil eine Research-Skill, die ich geschrieben hatte, die gesamte Issue-Historie eines GitHub-Repositorys in die Konversation ziehen wollte. Claude hörte mitten im Satz auf zu antworten. Die Session war hinüber.

Das war vor drei Wochen. Ich versuchte, eine Skill zu bauen, die Wettbewerbsinformationen sammeln sollte, bevor ich einen technischen Artikel schrieb. Einfache Idee: GitHub abfragen, aktuelle Issues abrufen, Trends zusammenfassen. Die Skill funktionierte — technisch gesehen. Aber sie funktionierte so, wie ein Feuerwehrschlauch funktioniert, wenn man eine Kaffeetasse füllen will. Alle Daten kamen an, und sie zerstörten alles drum herum.

Ich verbrachte die nächste Woche damit, diese Skill mit drei Funktionen neu aufzubauen, die ich ignoriert hatte: Context Forking, Dynamic Context Injection und Background Agents. Dieselbe Skill läuft jetzt in einer eigenen isolierten Session, verarbeitet Daten über Shell-Scripts, bevor Claude sie jemals zu sehen bekommt, und arbeitet asynchron, während ich in meinem Hauptfenster weitercodiere. Der Token-Verbrauch sank von 47.000 auf etwa 3.200. Gleiche Ausgabequalität. Ein völlig anderes Universum der Effizienz.

Diese Erfahrung lehrte mich etwas, das ich in keiner Dokumentation oder keinem Tutorial gelesen hatte: Die grundlegende Skill-Architektur — ein Ordner mit einer SKILL.md-Datei — ist die Startlinie, nicht die Ziellinie. Die fortgeschrittenen Funktionen, die auf diesem Fundament aufbauen, sind der Punkt, an dem Skills von "cleverem Prompt-Trick" zu "echtem autonomem Workflow" werden. Und die meisten Entwickler, die gerade Skills bauen, haben sie noch nicht angefasst.

Dies ist alles, was ich über die fortgeschrittene Seite der Claude Code Skills gelernt habe — die Teile, die mich vom Spielzeugbauen zum Systemebauen gebracht haben.

Wo Skills Heute Stehen (Und Warum die Grundlagen Nicht Ausreichen)

Wenn du meinen früheren Überblick darüber gelesen hast, wie Agent Skills auf fundamentaler Ebene funktionieren, kennst du das Kernkonzept: Eine Skill ist ein Ordner mit einer SKILL.md-Datei mit YAML Frontmatter und Markdown-Anweisungen. Claude lädt die Metadaten, sieht welche Skills verfügbar sind, und holt den vollständigen Inhalt erst dann, wenn eine Skill für die aktuelle Aufgabe relevant ist. Progressive Enthüllung. Kontexteffizienz. Modulare Expertise.

Diese Architektur ist wirklich gut. Ich verwende täglich noch einfache Skills — meinen Commit-Message-Formatter, meine Code-Review-Checkliste, mein Deployment-Pre-Flight-Script. Sie sind einfach, sie funktionieren, und sie sparen mir 10-15 Minuten pro Einsatz.

Aber ich stieß immer wieder an Grenzen.

Das Research-Skill-Desaster war das dramatische Beispiel, aber die stilleren Fehlschläge waren lehrreicher. Eine Skill, die den aktuellen Projektstatus benötigte — welche Dateien sich geändert haben, auf welchem Branch ich bin, welche Dependencies installiert sind — aber nur Zugriff auf statische Anweisungen hatte, die zum Zeitpunkt der Skill-Erstellung geschrieben wurden. Eine Skill, die einen komplexen Mehrstufen-Workflow ausführte und meine Hauptkonversation mit 30 Nachrichten an Zwischenergebnissen verschmutzte, die mich nicht interessierten. Eine Skill, die mit Opus 4 brillant funktionierte, aber nach dem Wechsel zu Sonnet 4.6 anfing, Schritte zu halluzinieren.

Jeder dieser Fehlschläge wies auf dieselbe Lücke hin: Einfache Skills sind statisch. Sie kodieren Wissen, aber sie können sich nicht an Live-Kontext anpassen, ihre Arbeit nicht isolieren und nicht beweisen, dass sie noch korrekt funktionieren, wenn sich Modelle weiterentwickeln.

Anthropic hat offensichtlich dieselbe Lücke gesehen. Das Skill-System per März 2026 enthält Funktionen, die jedes dieser Probleme adressieren. Die Herausforderung ist, dass diese Funktionen über verschiedene Seiten dokumentiert, in verschiedenen Kontexten erklärt und — ehrlich gesagt — in ihrer Leistungsfähigkeit nicht immer offensichtlich sind, bis man an die spezifische Wand gestoßen ist, die sie lösen.

Ich werde sie alle in der Reihenfolge durchgehen, in der ich mir gewünscht hätte, sie gelernt zu haben.

Skill-Typen: Wähle die Richtige Architektur, Bevor Du Eine Zeile Schreibst

Bevor du eine fortgeschrittene Skill baust, musst du eine Frage beantworten: Welche Art von Problem löst diese Skill? Anthropic kategorisiert Skills in zwei Typen, und die falsche Wahl bedeutet, dass du etwas baust, das entweder überkompliziert oder unterdimensioniert ist.

Capability Uplift Skills

Diese geben Claude Fähigkeiten, die es standardmäßig nicht hat. Meine Airtop-Browserautomatisierungs-Skill ist ein reines Capability Uplift — Claude kann nativ keinen Cloud-Browser steuern, aber mit installierter Skill kann es Websites navigieren, Formulare ausfüllen, Daten extrahieren und authentifizierte Sitzungen handhaben. Die Airtop-Integration kompiliert Anweisungen in einfachem Englisch zu deterministischem Code, der auf einer echten Chromium-Instanz in der Cloud läuft.

Andere Capability-Uplift-Beispiele, die ich täglich nutze: Eine Skill, die Lighthouse-Audits durchführt und die Ergebnisse zurück in die Konversation einspeist. Eine Skill, die meine Airtable-Projektdatenbank abfragt. Eine Skill, die Remotion-Videokompositionen generiert und rendert.

Das Muster ist konsistent — Capability Uplift Skills enthalten ausführbare Scripts (Bash, Python, Node), die Claude als Tools aufruft. Die Markdown-Anweisungen sagen Claude, wann und wie das Tool zu verwenden ist. Das Script erledigt die eigentliche Arbeit.

Encoded Preference Skills

Diese fügen keine neuen Fähigkeiten hinzu. Sie kodieren spezifische Workflows, Konventionen und Entscheidungsmuster. Meine Code-Review-Skill gibt Claude keine neuen Tools — Claude kann bereits Code lesen und Verbesserungen vorschlagen. Die Skill kodiert die Review-Standards meines Teams: Zuerst auf N+1-Queries prüfen, verifizieren dass alle öffentlichen Methoden Docblocks haben, jedes rohe SQL markieren das nicht parametrisiert ist, sicherstellen dass Fehlerantworten unserem API-Vertrag folgen.

Die Unterscheidung ist wichtig, weil sie die Komplexität bestimmt. Capability Uplift Skills brauchen Scripts, Tool-Definitionen, manchmal MCP-Server-Konfigurationen. Encoded Preference Skills sind reines Markdown — oft nur 50-200 Zeilen präziser Anweisungen. Wenn du eine Encoded Preference Skill baust und merkst, dass du Shell-Scripts schreibst, hast du wahrscheinlich den Typ falsch identifiziert.

Ich machte diesen Fehler zweimal, bevor er sich einprägte. Ich baute eine aufwendige Skill mit einem Python-Script, um die Testmuster meiner Codebase zu "analysieren", während alles, was ich tatsächlich brauchte, eine Markdown-Datei war, die Claude sagte: "Verwende beim Schreiben von Tests für dieses Projekt Pest statt PHPUnit, mocke externe Services mit Http::fake() und teste immer zuerst den Fehlerfall." Die Markdown-only-Version war schneller zu bauen, schneller zu laden und produzierte bessere Ergebnisse, weil Claude nicht zwischen Anweisungsbefolgung und Tool-Aufrufen wechseln musste.

Dennoch — die leistungsstärksten Skills, die ich gebaut habe, kombinieren beide Typen. Die Research-Skill, die ich schließlich repariert habe? Capability Uplift für die Datensammlung (Shell-Scripts, die die GitHub API abfragen), Encoded Preferences für die Analyse (wie verschiedene Signale zu gewichten sind, welches Ausgabeformat verwendet werden soll). Hybride Skills sind der Punkt, an dem es interessant wird, und an dem die fortgeschrittenen Funktionen ihre Komplexität zu rechtfertigen beginnen.

Context Forking: Gib Skills Ihren Eigenen Raum zum Denken

Dies ist die Funktion, die meine Research-Skill gerettet hat. Und es ist diejenige, die meiner Meinung nach die meisten Entwickler zuerst lernen sollten.

Hier ist das Problem, das Context Forking löst. Wenn eine Skill in deiner Claude-Hauptsession läuft, lebt jedes Token, das sie generiert — jeder Zwischenschritt, jedes Datenstück, das sie verarbeitet, jede Argumentationskette, der sie folgt — in deinem Haupt-Context Window. Eine Skill, die 15 Arbeitsschritte durchführt, bevor sie ein Endergebnis produziert, hat 15 Schritte Kontext in deine Konversation gedumpt, nach denen du nicht gefragt hast. Dein nächster Prompt muss jetzt mit all diesem Rauschen um Claudes Aufmerksamkeit konkurrieren.

Ich habe das letzten Monat an einem realen Projekt gemessen. Meine Hauptsession lag bei ungefähr 12.000 Token, als ich eine Skill auslöste, die meine package.json analysierte, auf veraltete Dependencies prüfte, bekannte Schwachstellen abglich und einen priorisierten Update-Plan erstellte. Als die Skill fertig war, enthielt mein Context Window 38.000 Token. Die Ausgabe der Skill — der Teil, den ich tatsächlich wollte — umfasste etwa 800 Token. Die anderen 25.200 Token waren Arbeitsspeicher, den ich nie wieder ansehen würde. Und sie würden dort sitzen, Kapazität verbrauchen und Claudes Fokus leicht verschlechtern, für den Rest der Session.

Context Forking eliminiert das vollständig. Du fügst eine Zeile zur YAML Frontmatter deiner Skill hinzu:

---
name: dependency-audit
description: Analyzes project dependencies for security issues and updates
context: fork
---

Diese context: fork-Direktive weist Claude Code an, einen dedizierten Subagenten für diese Skill zu starten. Der Subagent bekommt sein eigenes Context Window, seine eigene Gesprächshistorie und den vollständigen Skill-Inhalt beim Start injiziert. Er erledigt seine gesamte Arbeit isoliert und gibt nur das Endergebnis an deine Hauptsession zurück.

Dieselbe Dependency-Audit-Skill, dasselbe Projekt. Kosten der Hauptsession: etwa 1.200 Token (die Anfrage und die zurückgegebene Zusammenfassung). Der Subagent verbrauchte seine eigenen 26.000 Token in seinem eigenen Fenster, das nach Abschluss der Skill bereinigt wurde.

Das mentale Modell, das mir geholfen hat: Denke an Context Forking wie das Ausführen einer Funktion in einem separaten Thread statt inline. Die Inline-Version funktioniert, blockiert aber deinen Hauptthread und lässt ihre Stack-Frames herumliegen. Die geforkte Version läuft unabhängig und gibt ein sauberes Ergebnis zurück.

Wann Forken (Und Wann Nicht)

Ich forke alles, was mehr als 3-4 Schritte Zwischenverarbeitung umfasst. Kurze Skills — eine Commit-Message formatieren, eine Migrationsdatei generieren, eine einzelne Konfiguration prüfen — laufen problemlos im Hauptkontext. Der Overhead des Startens eines Subagenten lohnt sich nicht für eine Skill, die 500 Token Arbeitsspeicher generiert.

Aber alles, was Recherche, Analyse, Mehrfach-Dateiverarbeitung oder komplexes Reasoning umfasst? Forke es. Die Kontexteinsparungen summieren sich über einen Arbeitstag. Früher musste ich meine Claude-Sessions alle 2-3 Stunden neu starten, weil der Kontext zu überladen wurde. Mit geforkten Skills, die die schwere Arbeit erledigen, komme ich regelmäßig durch volle 8-Stunden-Sessions ohne Verschlechterung.

Etwas, das die Dokumentation nicht genug betont: Geforkte Skills können angeben, welches Agenten-Modell verwendet werden soll. Ich führe meine Hauptsession auf Opus 4.6 für sein tiefes Reasoning, aber meine einfacheren geforkten Skills — Datensammlung, Formatierung, Dateiorganisation — laufen auf Sonnet 4.6 zu einem Bruchteil der Kosten. Das stellst du in der Frontmatter ein:

---
name: format-changelog
description: Generates a formatted changelog from git history
context: fork
model: sonnet
---

Eine einzelne Research-Skill, die mich früher $0,40 pro Durchlauf auf Opus kostete, kostet jetzt $0,06, weil der Datensammlungs-Fork auf Sonnet läuft und nur der abschließende Analyseschritt Opus in meiner Hauptsession verwendet. Über einen Monat täglicher Nutzung ist das echtes Geld.

Dynamic Context Injection: Skills, Die Wissen, Was Gerade Passiert

Statische Anweisungen versagen in dem Moment, in dem dein Projektstatus relevant wird. Das lernte ich beim Bau einer Deployment-Skill, die den aktuellen Git-Branch wissen musste, den letzten Commit-Hash, welche Umgebungsvariablen gesetzt waren und ob Migrationen ausstanden. Ich konnte Anweisungen hartcodieren, wie diese Dinge zu prüfen sind, aber die Skill würde Token dafür verschwenden, dass Claude Befehle ausführt und Ausgaben verarbeitet, die ich im Voraus hätte sammeln können.

Dynamic Context Injection dreht das Modell um. Anstatt dass Claude den Projektstatus zur Laufzeit entdeckt, sammelt ein Vorverarbeitungs-Script die Daten bevor die Skill geladen wird und injiziert sie direkt in den Skill-Inhalt. Claude empfängt die Skill mit bereits eingebetteten Live-Daten. Kein Entdeckungsschritt. Keine verschwendeten Token.

Die Syntax verwendet !command-Platzhalter in deiner SKILL.md:

---
name: deploy-preflight
description: Runs deployment readiness checks for current branch
context: fork
---

## Current Project State

- **Branch:** !git rev-parse --abbrev-ref HEAD
- **Last commit:** !git log -1 --oneline
- **Uncommitted changes:** !git status --porcelain | wc -l
- **Pending migrations:** !php artisan migrate:status --pending 2>/dev/null || echo "N/A"
- **Node version:** !node --version
- **Environment:** !echo $APP_ENV

## Deployment Checklist

Based on the current state above, verify the following...

Wenn diese Skill aktiviert wird, führt Claude Code jeden !command-Shell-Befehl aus, erfasst die Ausgabe und ersetzt den Platzhalter durch das tatsächliche Ergebnis. Claude sieht:

- **Branch:** feature/payment-gateway
- **Last commit:** a3f2c91 Add Stripe webhook handler
- **Uncommitted changes:** 3
- **Pending migrations:** 2 pending

Nicht die Befehle. Die Ergebnisse. Claude beginnt, über die Deployment-Bereitschaft anhand des tatsächlichen Projektstatus nachzudenken, anstatt Token für dessen Entdeckung aufzuwenden.

Die Token-Einsparungen sind erheblich — meine Deploy-Preflight-Skill sank von etwa 4.800 Token (mit Claude, das Entdeckungsbefehle ausführt) auf 1.900 Token (mit vorinjiziertem Status). Aber der größere Gewinn ist die Genauigkeit. Wenn Claude den Status selbst entdeckt, parst es manchmal Befehlsausgaben falsch, überspringt eine Prüfung, wenn es "sicher genug" ist, oder lässt sich von einer unerwarteten Antwort ablenken. Mit vorinjizierten Daten ist jedes Statuselement garantiert vorhanden und korrekt formatiert.

Injection mit Forking Kombinieren

Der echte Power-Move ist, beides zusammen zu verwenden. Meine Competitive-Research-Skill — diejenige, mit der diese ganze Reise begann — sieht jetzt so aus:

---
name: competitive-research
description: Analyzes GitHub activity and trends for a given technology
context: fork
model: sonnet
---

## Research Context

Target technology: {{topic}}
Date range: !date -v-30d +%Y-%m-%d to !date +%Y-%m-%d

## Recent Activity
!gh api search/repositories --jq '.[0:5] | .[] | "\(.full_name) - \(.stargazers_count) stars - \(.description)"' -q "{{topic}} pushed:>$(date -v-30d +%Y-%m-%d)"

## Trending Issues
!gh api search/issues --jq '.[0:10] | .[] | "[\(.repository_url | split("/") | last)] \(.title)"' -q "{{topic}} is:issue created:>$(date -v-7d +%Y-%m-%d)"

Die Shell-Befehle verarbeiten die GitHub-API-Abfragen vor. Das context: fork führt alles in einem isolierten Subagenten auf Sonnet aus. Meine Opus-Hauptsession erhält eine saubere Zusammenfassung. Gesamte Token-Kosten der Hauptsession: etwa 900 Token. Tatsächlich geleistete Gesamtarbeit: Äquivalent zu dem, was früher mein 47.000-Token Context Window gesprengt hat.

Das ist keine inkrementelle Verbesserung. Das ist eine fundamental andere Fähigkeit.

Background Agents: Skills, Die Arbeiten, Während Du Arbeitest

Manche Skills brauchen Zeit. Ein umfassendes Sicherheitsaudit einer Codebase. Eine vollständige Testsuite-Ausführung mit Analyse. Das Scrapen und Zusammenfassen von 20 Dokumentationsseiten. Diese Workflows können 3-5 Minuten dauern — eine Ewigkeit, wenn du darauf wartest, dass dein Terminal wieder benutzbar wird.

Background Agents lösen das, indem sie Skills asynchron laufen lassen. Du löst die Skill aus, sie startet einen Background Agent, und deine Hauptsession bleibt reaktionsfähig. Wenn der Background Agent fertig ist, präsentiert er die Ergebnisse.

Ich nutze das täglich für meine Testanalyse-Skill. Nach dem Pushen eines Feature-Branches löse ich die Skill aus:

/skill test-analysis

Die Skill forkt in einen Background Agent, führt die vollständige Testsuite aus, erfasst eventuelle Fehler, analysiert Coverage-Reports und erstellt eine Zusammenfassung. In der Zwischenzeit arbeite ich bereits am nächsten Feature in meiner Hauptsession. Drei Minuten später meldet sich der Background Agent zurück mit:

Test Analysis Complete:
- 247 tests passed, 2 failed
- Failed: OrderCalculation::test_discount_stacking (assertion mismatch on line 89)
- Failed: PaymentGateway::test_timeout_retry (mock not returning expected response)
- Coverage: 78.3% (down 0.4% from main branch)
- Suggestion: The discount stacking failure looks like a rounding issue...

Der Workflow ähnelt der Verwendung von Ctrl+B, um einen laufenden Subagenten in den Hintergrund zu verschieben — der Agent arbeitet unabhängig weiter, selbst nachdem deine Hauptaufgabe fortfährt. Der /tasks-Befehl gibt dir ein Dashboard über alles, was im Hintergrund läuft, mit IDs, die du verwenden kannst, um den Status zu prüfen, Details anzusehen oder abzubrechen.

Was dir niemand über Background Agents erzählt: Sie sind am wertvollsten nicht wegen der Zeitersparnis, sondern wegen der Kontextisolierung. Bevor ich Background Agents nutzte, ließ ich meine Testsuite in Claudes Hauptsession laufen und bekam 200+ Zeilen Testausgabe zurück, die ich mental filtern musste. Der Background Agent verarbeitet das gesamte Rauschen in seinem eigenen Kontext und gibt mir nur das Signal zurück.

Wenn du lieber jemanden hättest, der ein solches Multi-Agent-Skill-System von Grund auf baut, übernehme ich Claude Code-Automatisierungsprojekte. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD.

Skills Installieren: Das Ökosystem Ist Größer Als Du Denkst

Ich sollte kurz zurückgehen und über die Installation von Skills in deinem System sprechen, denn die Installationsgeschichte hat sich schnell weiterentwickelt.

Der Plugin-Befehl

Die primäre Methode ist das eingebaute Plugin-System von Claude Code:

/plugin install <skill-name>@<marketplace>

Für das offizielle Skills-Repository von Anthropic:

/plugin install document-skills@anthropic-agent-skills

Du kannst auch Drittanbieter-Marktplätze registrieren:

/plugin marketplace add alirezarezvani/claude-skills

Nach dem Hinzufügen eines Marktplatzes wird jede Skill in diesem Repository mit einem einzigen Befehl installierbar.

Das skills.sh-Ökosystem

Das skills.sh-Ökosystem ist explodiert, seit ich zum ersten Mal darüber geschrieben habe. Stand März 2026 gibt es über 7.000 evaluierte Skills über mehrere Marktplätze hinweg, kompatibel nicht nur mit Claude Code, sondern auch mit Codex CLI, Gemini CLI, Cursor und Antigravity IDE. Das universelle SKILL.md-Format bedeutet, dass eine Skill, die du für Claude baust, in all diesen Tools funktioniert.

Die beste Entdeckungsmethode, die ich gefunden habe: Durchstöbere SkillHub oder das VoltAgent awesome-agent-skills-Repository, das Skills von offiziellen Entwicklerteams und der Community kuratiert. Filtere nach Kategorie, prüfe Bewertungen und installiere mit einem Befehl.

Manuelle Installation

Für Skills, die du selbst baust — und dort liegt die eigentliche Stärke — hast du zwei Wege:

Projektbezogen: Lege den Skill-Ordner in .claude/skills/ in deinem Repository ab. Jedes Teammitglied, das das Repo klont, bekommt die Skill automatisch. Versioniert, geteilt, konsistent.

Persönlich: Lege sie in ~/.claude/skills/ für Skills, die du projektübergreifend verfügbar haben willst. Meine Formatierungs-Skills, meine allgemeinen Code-Review-Standards, mein Schreibstil-Guide — diese befinden sich in meinem persönlichen Verzeichnis, weil sie nicht projektspezifisch sind.

Die Ordnerstruktur ist unkompliziert:

.claude/skills/
  deploy-preflight/
    SKILL.md          # Frontmatter + instructions
    scripts/
      check-deps.sh   # Optional executable scripts
    templates/
      deploy-log.md   # Optional reference files

Claude sieht den Skill-Namen und die Beschreibung aus der Frontmatter. Der vollständige Inhalt wird erst geladen, wenn die Skill ausgelöst wird. Scripts im Ordner werden zu Tools, die die Skill aufrufen kann.

Skills Manuell Bauen: Die Muster, Die Tatsächlich Funktionieren

Ich habe in den letzten vier Monaten etwa 40 Skills gebaut. Die meisten frühen waren mittelmäßig. Die, die ich jetzt baue, sind drastisch besser, und der Unterschied liegt an drei Mustern, die ich durch Scheitern lernen musste.

Muster 1: Anweisungsspezifität Statt Anweisungsvolumen

Meine ersten Skills waren 500+ Zeilen detaillierter Anweisungen. "Wenn der Benutzer nach X fragt, tue Y. Wenn er Z erwähnt, prüfe zuerst W. In Fällen, in denen..." Erschöpfend. Und furchtbar.

Das Problem: Lange Skills verbrennen Kontexttoken selbst nach dem Forking, und Claude wird schlechter im Befolgen von Anweisungen, je größer die Anweisungsmenge wird. Es gibt einen Sweet Spot — und in meinen Tests liegt er zwischen 80 und 200 Zeilen Markdown für den Anweisungsteil.

Die Lösung war, Anweisungen so zu schreiben, wie ich einen Senior Engineer briefen würde, nicht einen Junior. Anstatt jeden Schritt auszubuchstabieren, beschreibe ich das Ziel, die Einschränkungen und den Qualitätsmaßstab. Claudes Reasoning füllt die Lücken.

Schlecht:

1. First, open the file
2. Then find all functions
3. For each function, check if it has a docblock
4. If it doesn't have a docblock, generate one
5. The docblock should include @param tags
6. The @param tags should list the type first, then the name
7. After the @param tags, add a @return tag
...

Gut:

## Task
Add PHPDoc blocks to all public methods missing them.

## Standards
- Follow PSR-5 PHPDoc format
- Infer parameter types from type hints; fall back to mixed
- Include @throws if the method contains throw statements
- Keep descriptions to one sentence — if you need two, the method needs refactoring

Die gute Version hat 6 Zeilen statt 30+. Sie produziert bessere Ausgabe, weil sie Claude Raum gibt, über jeden spezifischen Fall nachzudenken, anstatt mechanisch eine Checkliste abzuarbeiten.

Muster 2: Exit-Bedingungen, Nicht Nur Entry-Bedingungen

Die Frontmatter jeder Skill hat eine Beschreibung, die Claude sagt, wann sie aktiviert werden soll. Die meisten Skill-Ersteller hören hier auf. Aber Claude zu sagen, wann die Skill fertig ist, ist genauso wichtig.

Ohne explizite Exit-Bedingungen neigen Skills dazu, zu viel zu liefern. Meine SEO-Audit-Skill fand immer wieder "noch eine Sache zu prüfen", bis sie 15.000 Token an Analyse für eine einzelne Seite verbraucht hatte. Das Hinzufügen von Exit-Bedingungen löste das:

## Completion Criteria
- All five audit categories scored (Performance, Accessibility, SEO, Best Practices, Content)
- Critical issues listed (severity: high only)
- Three specific, actionable recommendations provided
- Total output: under 500 words

Stop when these criteria are met. Do not continue analyzing.

Muster 3: Fehlerbehandlungs-Anweisungen

Skills, die externe Tools aufrufen — APIs, Shell-Befehle, Datenbankabfragen — werden auf Fehler stoßen. Wenn du Claude nicht sagst, wie es mit Fehlern umgehen soll, hält es entweder unbeholfen an oder beginnt zu improvisieren, was oft schlimmer ist.

Jede Capability Uplift Skill, die ich jetzt baue, enthält einen Abschnitt für Fehlermodi:

## When Things Go Wrong

**API returns 401:** The token has expired. Tell the user to run `gh auth refresh` and retry.
**API returns 404:** The repository doesn't exist or is private. Ask the user to verify the repo name.
**Command timeout (>30s):** The network request is hanging. Suggest checking VPN status or retrying with `--timeout 60`.
**Empty results:** This is valid — not every query has results. Report "no data found" rather than guessing.

Never fabricate data if a command fails. Report the failure and suggest a fix.

Dieses eine Muster eliminierte etwa 80% des unvorhersehbaren Verhaltens, das ich in meinen Skills beobachtete.

Skill-Testen und -Evaluierung: Der Teil, Den Alle Überspringen

Ich werde hier direkt sein: Wenn du Skills baust, ohne sie zu testen, baust du Skills, die ohne Vorwarnung versagen werden.

Ich habe das Testen bei meinen ersten 20 Skills übersprungen. Dann bekam Claude ein Modell-Update, und 6 davon begannen, schlechtere Ausgabe zu produzieren. Nicht kaputt — schlechter. Subtile Verschlechterung. Meine Code-Review-Skill hörte auf, N+1-Queries zu erkennen. Meine Deployment-Skill begann, die Migrationsprüfung zu überspringen. Ich bemerkte es eine Woche lang nicht, weil die Skills noch liefen — sie liefen nur schlecht.

Deshalb hat Anthropic den Skill Creator gebaut.

Der Skill Creator: Eine Skill, Die Andere Skills Baut und Testet

Der Skill Creator ist eine Meta-Skill — eine Skill, die die Entwicklung, das Testen und die Evaluierung anderer Skills automatisiert. Installiere ihn als Plugin, und du erhältst Zugang zu zwei Kern-Workflows:

Eval Mode: Definiere Test-Prompts, beschreibe erwartete Ausgaben, und der Skill Creator führt deine Skill gegen jeden Prompt aus und bewertet die Ergebnisse. Er evaluiert über fünf Dimensionen: Frontmatter-Vollständigkeit, Beschreibungsqualität, Anweisungsklarheit, Erklärungstiefe und Eval-Bestehensrate.

eval: Execute skill on test prompts → Grade outputs → Report scores

Improve Mode: Alles aus dem Eval Mode, plus blinde A/B-Vergleiche, automatisierte Analyse und iterative Verfeinerung. Der Skill Creator führt zwei Claude-Instanzen aus — eine mit deiner Skill, eine ohne — gibt ihnen denselben Prompt und vergleicht die Ausgaben. Wenn die Skill-Version die Vanilla-Version nicht deutlich übertrifft, weißt du, dass die Skill keinen Mehrwert bringt.

improve: Execute → Grade → Blind A/B compare → Analyze → Iterate

Wie Ich Meine Skills Jetzt Teste

Jede Skill, die ich baue, durchläuft diese Pipeline, bevor ich sie als fertig betrachte:

Schritt 1: Definiere 3-5 Test-Prompts. Diese sollten den Happy Path der Skill abdecken, einen Grenzfall und mindestens einen adversarialen Fall (einen Prompt, der dem Skill-Bereich nahe ist, aber die Skill nicht auslösen sollte).

Schritt 2: Führe den Eval Mode aus. Prüfe, ob alle Test-Prompts die erwarteten Ausgaben produzieren. Wenn einer fehlschlägt, überarbeite die Skill-Anweisungen.

Schritt 3: Führe den A/B-Test durch. Dies ist der Schritt, der meine Perspektive auf das Skill-Bauen veränderte. Ich hatte eine Skill, von der ich dachte, sie sei brillant — eine Code-Review-Skill mit detaillierten Standards. Der A/B-Test zeigte, dass Standard-Claude (ohne Skill) für 3 von 5 Testfällen ebenso gute Reviews produzierte. Meine "brillante" Skill fügte nur bei Grenzfällen mit Datenbankabfragen und API-Fehlerbehandlung Wert hinzu. Ich schrieb sie um, um sich ausschließlich auf diese Bereiche zu konzentrieren, kürzte die Anweisungslänge um 60%, und die A/B-Ergebnisse kippten auf 5 von 5.

Schritt 4: Nach Modell-Updates erneut testen. Ich bewahre meine Test-Prompts in einem tests/-Unterordner innerhalb jedes Skill-Verzeichnisses auf. Nach jedem Claude-Modell-Update führe ich die Evals erneut durch. Das dauert etwa 10 Minuten für meine gesamte Skill-Bibliothek und hat in den letzten zwei Monaten dreimal Verschlechterung entdeckt.

Das Evaluierungssystem führt jeden Test parallel in isolierten Kontexten aus, sodass Skills sich während des Testens nicht gegenseitig beeinflussen können. Diese Isolation ist wichtig — ich hatte einmal einen Skill-Test, der einzeln ausgeführt bestand, aber zusammen mit anderen Skills fehlschlug, wegen einer Namenskollision in der Frontmatter.

Diese Testdisziplin fühlt sich wie Overhead an, bis sie dich zum ersten Mal rettet. Dann fühlt sie sich wie die einzig verantwortungsvolle Art an, Skills zu bauen.

Echte Integration: Airtop Cloud-Browser-Automatisierung

Theorie ist nützlich. Lass mich dir zeigen, wie eine vollständig fortgeschrittene Skill in der Produktion aussieht.

Die Skill, auf die ich gerade am stolzesten bin, ist meine Airtop-Browserautomatisierungs-Skill. Airtop bietet einen echten Cloud-Browser — keinen Headless-Scraper, kein simuliertes DOM, eine tatsächliche Chromium-Instanz, die in der Cloud läuft und JavaScript-lastige Seiten, authentifizierte Sitzungen und dynamische Inhalte verarbeiten kann.

Warum das wichtig ist: Die Hälfte der Automatisierungen, die ich Claude ausführen lassen will, betrifft Websites, die keine APIs haben. Wettbewerber-Preisseiten. Lieferantenportale. Behördliche Compliance-Datenbanken. Jobportale. CRMs. Es gibt keine API zum Abfragen — die einzige Schnittstelle ist ein Browser.

Die Airtop-Skill löst das, indem sie alle fortgeschrittenen Funktionen kombiniert:

---
name: airtop-research
description: Automates web research using a real cloud browser via Airtop
context: fork
model: sonnet
---

Sie forkt in ihren eigenen Kontext (weil Browserautomatisierung ausführliche Zwischenausgaben erzeugt). Sie verwendet Dynamic Injection, um meine Airtop-API-Credentials und die Ziel-URLs zu laden. Sie führt Sonnet für die Browser-Interaktionsschritte aus (kosteneffizient für mechanische Navigation) und gibt strukturierte Ergebnisse an meine Opus-Hauptsession zur Analyse zurück.

Ein Workflow, den ich gestern ausgeführt habe: Überwachung von Wettbewerberpreisen über fünf SaaS-Tools hinweg. Ich beschrieb, was ich brauchte, in einfacher Sprache, die Skill kompilierte es in deterministischen Automatisierungscode, startete Cloud-Browser-Sessions gegen jede Website, extrahierte Preistabellen und gab einen strukturierten Vergleich zurück. Gesamtzeit: etwa 90 Sekunden. Manuelles Äquivalent: 20-30 Minuten Tab-Wechseln und Kopieren-Einfügen.

Die kompilierte Automatisierung ist der Teil, der mich am meisten überrascht hat. Airtop spielt meine Anweisungen nicht einfach ab — es generiert tatsächlichen Code daraus, der bei nachfolgenden Ausführungen deterministisch läuft. Der erste Durchlauf ist agentengesteuert und explorativ. Jeder weitere Durchlauf ist schnell und zuverlässig. Es ist ein Muster, das ich in anderen Browserautomatisierungs-Tools nicht gesehen habe, und es macht den Unterschied zwischen "cooler Demo" und "Produktions-Workflow."

Die Verschmelzung von Skills und Custom Commands

Eine architektonische Verschiebung, die erwähnenswert ist: Skills und Custom Slash Commands in Claude Code konvergieren. Frühere Versionen behandelten sie als separate Systeme — Commands waren schnelle Abkürzungen, Skills waren tiefere Wissensmodule. Ab Claude Code 2.1 ist die Grenze verschwommen.

Eine Skill kann sich jetzt über die Frontmatter als Slash Command registrieren:

---
name: security-audit
description: Full OWASP-aligned security review of the current project
command: /audit
context: fork
---

Die Eingabe von /audit in Claude Code löst die vollständige Skill mit all ihren fortgeschrittenen Funktionen aus — Forking, Dynamic Injection, Hintergrundausführung. Keine Notwendigkeit, separate Befehlskonfigurationen zu pflegen.

Diese Konvergenz ist wichtig, weil sie die kognitive Last der Verwaltung deines Toolkits reduziert. Früher pflegte ich eine mentale Karte von "welche Dinge sind Skills und welche Dinge sind Commands." Jetzt ist alles eine Skill, von denen einige Befehlsabkürzungen haben. Ein System. Ein Ort. Ein Testframework.

Der claude-skills-guide-decoded-Post, den ich früher geschrieben habe, behandelt das grundlegende SKILL.md-Format im Detail. Was sich seitdem geändert hat: Das Format unterstützt jetzt deutlich mehr Frontmatter-Optionen — context, model, command, Tool-Einschränkungen und Lifecycle Hooks — und verwandelt eine einfache Markdown-Datei in eine vollständige Agenten-Konfiguration.

Was Ich Falsch Gemacht Habe (Und Was Ich Anders Machen Würde)

Ich möchte mit den Fehlern schließen, weil sie nützlicher sind als die Erfolge.

Fehler 1: Zu viel Forking. Nach der Entdeckung von Context Forking wendete ich es auf alles an. Eine 3-Zeilen-Formatierungs-Skill, die 200 Token Ausgabe generierte? Geforkt. Der Overhead des Startens eines Subagenten überstieg die Kontextkosten des einfachen Inline-Ausführens. Forke Skills, die 2.000+ Token Arbeitsspeicher generieren. Lass einfache Skills in deiner Hauptsession laufen.

Fehler 2: Dynamic Injection ohne Caching. Einige meiner !command-Aufrufe kontaktierten APIs bei jeder Skill-Aktivierung. Wenn du eine Skill 10-mal pro Stunde auslöst, sind das 10 identische API-Aufrufe. Ich verwende jetzt Shell-Befehle, die zuerst auf ein gecachtes Ergebnis prüfen und nur live abfragen, wenn der Cache veraltet ist. Einfaches Muster, im Nachhinein offensichtlich, aber ich hatte meine API-Rate-Limits aufgebraucht, bevor ich es herausfand.

Fehler 3: Skills für Dinge bauen, die Claude bereits gut kann. Das A/B-Testing-Framework lehrte mich das: Wenn Standard-Claude die Aufgabe ohne Skill auf 80%+ Qualität erledigt, ist die Skill den Wartungsaufwand nicht wert. Skills sollten die Lücken adressieren — die projektspezifischen Konventionen, die externen Tool-Integrationen, das Domänenwissen, das Claude nicht hat. Eine Skill für "schreibe guten Python-Code" zu bauen ist verschwendete Mühe. Eine Skill für "schreibe Python-Code, der dem Decorator-Muster unseres Teams für FastAPI-Endpoints mit strukturiertem Logging folgt" zu bauen ist eine echte Verbesserung.

Fehler 4: Die Teststrategie ignorieren, bis es zu spät war. Sechs kaputte Skills nach einem Modell-Update. Das war nötig. Baue die Eval-Suite zusammen mit der Skill, nicht danach.

Die ehrliche Einschätzung, wo Skills gerade stehen: Das System funktioniert. Die fortgeschrittenen Funktionen — Forking, Injection, Background Agents, automatisierte Evals — transformieren Skills von "cleveren Prompt-Vorlagen" zu echter Workflow-Automatisierung. Die Werkzeuge sind noch früh genug, dass du auf raue Kanten stoßen wirst (Fehlermeldungen von geforkten Skills könnten viel aussagekräftiger sein, und das A/B-Test-Setup erfordert mehr manuelle Konfiguration als nötig). Aber die Architektur ist solide, und das Ökosystem bewegt sich in einem Tempo, das ich seit den frühen npm-Tagen nicht mehr gesehen habe.

Siebentausend Skills allein auf SkillsMP, und das Format funktioniert in Claude Code, Codex CLI, Gemini CLI und Cursor. Das ist kein Claude-spezifisches Feature mehr. Es ist ein Industriestandard, der sich in Echtzeit formiert.

Die Frage ist nicht, ob du in das Erlernen der fortgeschrittenen Skill-Funktionen investieren solltest. Die Frage ist, ob du es dir leisten kannst, weiterhin Agenten ohne sie zu bauen.

Häufig Gestellte Fragen

Was ist Context Forking in Claude Code Skills?

Context Forking startet einen dedizierten Subagenten mit eigenem Context Window, um eine Skill in Isolation auszuführen. Füge context: fork zu deiner SKILL.md Frontmatter hinzu, um zu verhindern, dass ressourcenintensive Skills deine Hauptkonversation verschmutzen. Die vollständige Anleitung findest du im Abschnitt Context Forking oben.

Wie installiere ich Claude Code Skills vom Marktplatz?

Führe /plugin install <skill-name>@<marketplace> in Claude Code aus oder füge einen Drittanbieter-Marktplatz mit /plugin marketplace add <repo> hinzu. Skills werden in .claude/skills/ für projektbezogene Nutzung oder ~/.claude/skills/ für persönliche Nutzung installiert.

Was ist Dynamic Context Injection in Claude Code?

Dynamic Context Injection verwendet die !command-Syntax in SKILL.md, um Shell-Befehle auszuführen, bevor die Skill geladen wird. Die Befehlsausgabe ersetzt den Platzhalter, sodass Claude Live-Projektdaten erhält — Git Branch, Umgebungsvariablen, API-Antworten — ohne Token für die Entdeckung aufzuwenden.

Wie teste ich Claude Code Skills mit dem Skill Creator?

Installiere das Skill Creator Plugin, definiere Test-Prompts mit erwarteten Ausgaben und führe den Eval Mode aus. Für tiefere Validierung verwende den Improve Mode, der blinde A/B-Tests durchführt und Claudes Ausgabe mit und ohne aktive Skill vergleicht. Siehe den Abschnitt Testen und Evaluierung oben.

Können Claude Code Skills im Hintergrund laufen?

Ja. Skills mit context: fork können Background Agents starten, die asynchron arbeiten, während deine Hauptsession reaktionsfähig bleibt. Verwende /tasks, um laufende Hintergrund-Skills zu überwachen, ihren Status zu prüfen oder sie abzubrechen.

Lass Uns Zusammenarbeiten

Du möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.

• Fiverr (Individuallösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io