Automatisch Claude Code Skills erstellen mit Skill Creator

Kurz gesagt (TL;DR)

Claude Code Skills sind benutzerdefinierte Fähigkeiten, die die Funktionalität von Claude für spezifische Arbeitsabläufe erweitern. Das Skill Creator System automatisiert die Skill-Erstellung durch einen strukturierten Prozess: Definieren Sie den Zweck Ihres Skills, entwerfen Sie die SKILL.md-Datei, erstellen Sie Testfälle, führen Sie Bewertungen mit quantitativen Benchmarks durch und verbessern Sie iterativ auf Basis von Feedback.

Einleitung

Sie verwenden Claude Code täglich. Sie bemerken, dass Sie dieselben Abläufe wiederholen: Projekteinrichtungen, Ausführen spezifischer Testbefehle, Formatieren von Ausgaben auf eine bestimmte Weise. Jedes Mal erklären Sie den Workflow von Grund auf neu. Was wäre, wenn Claude sich erinnern würde? Was wäre, wenn Sie diesen Workflow einmal erfassen und für immer verfügbar machen könnten? Genau das tun Claude Code Skills. Es sind benutzerdefinierte Fähigkeiten, die Sie erstellen, um Claudes Funktionalität für Ihre spezifischen Arbeitsabläufe zu erweitern. Und mit dem Skill Creator ist der Prozess automatisiert und systematisch.

Dieser Leitfaden führt Sie durch den gesamten Prozess. Sie lernen die Skill-Anatomie, den Erstellungsworkflow, das Bewertungssystem und wie Sie für eine zuverlässige Auslösung optimieren. Sie sehen funktionierende Beispiele aus dem offiziellen Anthropic Skill-Repository.

💡

Wenn Sie API-bezogene Skills erstellen, lässt sich Apidog nahtlos integrieren. Testen Sie Ihre API-Endpunkte, validieren Sie Antworten und generieren Sie Dokumentationen – alles innerhalb eines einzigen Skill-Workflows.

Button

Was sind Claude Code Skills?

Claude Code Skills sind spezialisierte Anweisungssätze, die die Fähigkeiten von Claude für bestimmte Domänen oder Arbeitsabläufe erweitern. Stellen Sie sich diese als benutzerdefinierte Plugins vor, die in Markdown-Dateien leben.

Die Architektur des Skill-Systems

Skills verwenden ein dreistufiges Ladesystem:

Metadaten (~100 Wörter) – Name und Beschreibung, immer im Kontext
SKILL.md-Hauptteil (<500 Zeilen) – Kernanweisungen, werden geladen, wenn der Skill ausgelöst wird
Gebündelte Ressourcen (unbegrenzt) – Skripte, Referenzen, Assets, die bei Bedarf geladen werden

skill-name/
├── SKILL.md (erforderlich)
│   ├── YAML Frontmatter (Name, Beschreibung)
│   └── Markdown Anweisungen
└── Gebündelte Ressourcen (optional)
    ├── scripts/    - Ausführbarer Code für wiederkehrende Aufgaben
    ├── references/ - Bei Bedarf geladene Dokumentation
    └── assets/     - Vorlagen, Icons, Schriftarten

Wann Skills ausgelöst werden

Skills erscheinen in Claudes available_skills-Liste mit ihrem Namen und ihrer Beschreibung. Claude entscheidet, ob ein Skill konsultiert werden soll, basierend auf dieser Beschreibung.

Wichtig: Skills werden nur für Aufgaben ausgelöst, die Claude nicht direkt bearbeiten kann. Einfache Anfragen wie „Diese Datei lesen“ lösen keinen Skill aus, selbst bei einer passenden Beschreibung. Komplexe, mehrstufige Arbeitsabläufe werden zuverlässig ausgelöst, wenn die Beschreibung übereinstimmt.

Praxisbeispiele aus dem Anthropic Repository

Skill	Zweck	Hauptmerkmale
skill-creator	Neue Skills erstellen	Generierung von Testfällen, Benchmark-Evaluierung, Beschreibung-Optimierung
mcp-builder	MCP-Server erstellen	Python/Node-Vorlagen, Evaluierungsframework, Best Practices
docx	Word-Dokumente generieren	python-docx Skripte, Vorlagensystem, Styling-Leitfaden
pdf	PDFs extrahieren und bearbeiten	Formularbearbeitung, Textextraktion, Referenzdokumente
frontend-design	Web-Interfaces erstellen	Komponentenbibliothek, Tailwind-Muster, Zugänglichkeitsprüfungen

Der Skill-Erstellungsworkflow

Der Skill-Erstellungsprozess folgt einem systematischen Kreislauf:

Absicht erfassen – Was soll der Skill tun?
Einen Entwurf schreiben – Die SKILL.md-Datei erstellen
Testfälle erstellen – Realistische Prompts definieren
Bewertungen durchführen – Ausführung mit und ohne Skill
Ergebnisse überprüfen – Qualitatives Feedback + quantitative Metriken
Iterieren – Basierend auf den Erkenntnissen verbessern
Beschreibung optimieren – Auslösegenauigkeit maximieren
Paket schnüren – Als .skill-Datei verteilen

Gehen wir jeden Schritt durch.

Schritt 1: Absicht erfassen

Beginnen Sie damit, zu verstehen, was der Skill erreichen soll. Wenn Sie einen Workflow erfassen, den Sie bereits durchgeführt haben, extrahieren Sie das Muster aus Ihrer Konversationshistorie.

Stellen Sie diese vier Fragen:

Was soll dieser Skill Claude ermöglichen? Seien Sie spezifisch bezüglich des Ergebnisses.
Wann soll dieser Skill ausgelöst werden? Welche Benutzerphrasen oder Kontexte?
Welches Ausgabeformat wird erwartet? Dateien, Code, Berichte?
Sollen wir Testfälle einrichten? Skills mit überprüfbaren Ausgaben (Code-Generierung, Datenextraktion, Dateiumwandlungen) profitieren von Testfällen. Skills mit subjektiven Ausgaben (Schreibstil, Design) benötigen diese oft nicht.

Beispiel: API-Test-Skill

Absicht: Entwicklern helfen, REST-APIs systematisch zu testen
Auslöser: Wenn der Benutzer API-Tests, Endpunkte, REST, GraphQL erwähnt oder Antworten validieren möchte
Ausgabe: Testberichte mit Bestanden/Fehlgeschlagen-Status, Curl-Befehle, Antwortvergleiche
Testfälle: Ja – Ausgaben sind objektiv überprüfbar

Schritt 2: Die SKILL.md-Datei schreiben

Jeder Skill beginnt mit einer SKILL.md-Datei, die YAML-Frontmatter und Markdown-Anweisungen enthält.

Skill-Anatomie

---
name: api-tester
description: So testen Sie REST-APIs systematisch. Verwenden Sie diesen Skill, wenn Benutzer API-Tests, Endpunkte, REST, GraphQL erwähnen oder API-Antworten validieren möchten. Achten Sie darauf, diesen Skill immer dann vorzuschlagen, wenn Tests involviert sind.
compatibility: Erfordert curl oder HTTP-Client-Tools
---

# API Tester Skill

## Kern-Workflow

Beim Testen einer API befolgen Sie diese Schritte:

1. **Den Endpunkt verstehen** – Die Spezifikation lesen oder nach dem Schema fragen
2. **Testfälle entwerfen** – Happy Path, Grenzfälle, Fehlerbedingungen
3. **Tests ausführen** – Curl oder Apidog für Anfragen verwenden
4. **Antworten validieren** – Statuscodes, Header, Body-Struktur prüfen
5. **Ergebnisse berichten** – Bestanden/Fehlgeschlagen zusammenfassen mit Nachweisen

## Testfall-Vorlage

Für jeden Endpunkt testen:

- Gültige Authentifizierung mit korrekter Nutzlast
- Gültige Authentifizierung mit fehlenden erforderlichen Feldern
- Ungültige Authentifizierung (401 erwartet)
- Rate Limiting Verhalten
- Antwortzeit unter Last

## Ausgabeformat

Berichte immer so strukturieren:

# API Testbericht

## Zusammenfassung
- Ausgeführte Tests: X
- Bestanden: Y
- Fehlgeschlagen: Z

## Fehlgeschlagene Tests

### Testname
**Erwartet:** 200 OK
**Tatsächlich:** 400 Bad Request
**Antwort:** {...}

## Empfehlungen
...

Best Practices für das Schreiben

Progressive Offenlegung verwenden: Halten Sie SKILL.md unter 500 Zeilen. Verschieben Sie detaillierte Referenzen in separate Dateien.

api-tester/
├── SKILL.md (Workflow-Übersicht)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

Das Warum erklären: Listen Sie nicht nur Regeln auf. Erklären Sie, warum sie wichtig sind.

## Warum wir zuerst Fehlerfälle testen

Das Testen von Fehlerbedingungen vor den "Happy Paths" fängt 80% der Probleme schneller ab.
Wenn die Authentifizierung stillschweigend fehlschlägt, werden die "Happy Path"-Tests bedeutungslos.
Beginnen Sie mit der 401-Prüfung.

Imperative Form verwenden: „Immer zuerst den Statuscode validieren“ nicht „Sie sollten validieren…“

Beispiele einfügen: Zeigen Sie Eingabe und erwartete Ausgabe.

## Commit-Nachrichtenformat

**Beispiel:**
Eingabe: Benutzerauthentifizierung mit JWT-Tokens hinzugefügt
Ausgabe: feat(auth): Implementierung der JWT-basierten Authentifizierung

Schritt 3: Testfälle erstellen

Nachdem Sie den Skill entworfen haben, erstellen Sie 2-3 realistische Test-Prompts. Dies sind die Art von Anfragen, die ein echter Benutzer tatsächlich stellen würde.

Testfall-Format

Speichern Sie Testfälle in evals/evals.json:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "Testen Sie den /users-Endpunkt auf api.example.com – er benötigt einen Bearer-Token und gibt eine Liste von Benutzern mit id, name, email-Feldern zurück",
      "expected_output": "Testbericht mit mindestens 5 Testfällen, einschließlich Authentifizierungsfehler, Erfolg und Paginierungstests",
      "files": []
    },
    {
      "id": 2,
      "prompt": "Ich muss überprüfen, ob unser neuer POST /orders-Endpunkt ungültige Mengen korrekt verarbeitet",
      "expected_output": "Testfälle, die negative, null und nicht-numerische Mengen mit entsprechenden Fehlermeldungen senden",
      "files": ["openapi.yaml"]
    }
  ]
}

Was einen guten Test-Prompt ausmacht

Schlecht: „Teste diese API“

Gut: „ok, mein Team hat gerade diesen neuen Payments-Endpunkt unter https://api.stripe.com/v1/charges bereitgestellt, und ich muss überprüfen, ob er Grenzfälle verarbeitet – insbesondere, was passiert, wenn man einen negativen Betrag oder einen nicht existierenden Währungscode sendet. Die Dokumente sagen, dass er 400 zurückgeben sollte, aber ich möchte die tatsächlichen Fehlermeldungen sehen“

Der gute Test-Prompt enthält:

Spezifische URL
Konkretes Szenario
Erwartetes Verhalten
Realweltlicher Kontext

Teilen Sie Ihre Testfälle dem Benutzer vor dem Ausführen mit: „Hier sind ein paar Testszenarien, die ich ausprobieren möchte. Sehen diese richtig aus, oder möchten Sie weitere hinzufügen?“

Schritt 4: Bewertungen durchführen

Hier glänzt der Skill Creator. Sie führen jeden Testfall zweimal aus: einmal mit dem Skill, einmal ohne (oder mit der alten Version, wenn Sie einen bestehenden Skill verbessern).

Workspace-Struktur

Ergebnisse landen in <skill-name>-workspace/ als Geschwisterverzeichnis zum Skill-Verzeichnis:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

Parallele Läufe starten

Für jeden Testfall zwei Subagenten im selben Durchlauf starten:

Lauf mit Skill:

Führe diese Aufgabe aus:
- Skill-Pfad: /pfad/zu/api-tester
- Aufgabe: Teste den /users-Endpunkt auf api.example.com
- Eingabedateien: keine
- Ausgaben speichern unter: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

Baseline-Lauf:

Führe diese Aufgabe aus:
- Skill-Pfad: (keine)
- Aufgabe: Teste den /users-Endpunkt auf api.example.com
- Eingabedateien: keine
- Ausgaben speichern unter: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

Zeitdaten erfassen

Wenn jeder Subagent abgeschlossen ist, erhalten Sie total_tokens und duration_ms. Sofort in timing.json speichern:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

Diese Daten kommen nur über die Task-Benachrichtigung. Verarbeiten Sie jede, sobald sie eintrifft.

Schritt 5: Behauptungen entwerfen, während Läufe abgeschlossen werden

Warten Sie nicht einfach, bis die Läufe beendet sind. Nutzen Sie diese Zeit produktiv, indem Sie quantitative Behauptungen entwerfen.

Was eine gute Behauptung ausmacht

Gute Behauptungen sind:

Objektiv überprüfbar – Bestanden/Fehlgeschlagen ist eindeutig
Deskriptiv benannt – Klar, was geprüft wird
Wiederverwendbar – Funktioniert über Iterationen hinweg

Beispielaussagen für den API-Test-Skill:

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "Testbericht enthält mindestens einen Authentifizierungsfehler-Testfall",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "Testbericht enthält mindestens einen erfolgreichen Anfragetest",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "Jeder Testfall enthält ausführbare Curl-Befehle",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "Bericht validiert die Antwortstruktur gegen das Schema",
      "type": "contains",
      "value": "schema"
    }
  ]
}

Aktualisieren Sie eval_metadata.json und evals/evals.json mit Behauptungen, sobald diese entworfen wurden.

Schritt 6: Bewerten und Aggregieren

Sobald alle Läufe abgeschlossen sind:

Jeden Lauf bewerten

Starten Sie einen Grader-Subagenten, der agents/grader.md liest und jede Behauptung gegen die Ausgaben bewertet. Speichern Sie die Ergebnisse in grading.json in jedem Lauf-Verzeichnis:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "401 Statuscode in Testfall 3 gefunden"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "'curl -X POST' in Testfall 1 gefunden"
    }
  ]
}

Wichtig: Das Erwartungs-Array von grading.json muss die Feldnamen text, passed und evidence verwenden. Der Viewer hängt von diesen exakten Namen ab.

Zu Benchmark aggregieren

Führen Sie das Aggregationsskript aus dem skill-creator-Verzeichnis aus:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

Dies erzeugt benchmark.json und benchmark.md mit Durchlaufrate, Zeit und Tokens für jede Konfiguration, einschließlich Mittelwert ± Standardabweichung und Delta.

Eine Analystenprüfung durchführen

Lesen Sie die Benchmark-Daten und erkennen Sie Muster:

Nicht-diskriminierende Behauptungen – Bestehen immer, unabhängig vom Skill (nicht nützlich)
Evals mit hoher Varianz – Möglicherweise instabil, muss untersucht werden
Zeit-/Token-Kompromisse – Verbessert der Skill die Qualität zu angemessenen Kosten?

Siehe agents/analyzer.md für detaillierte Anweisungen.

Schritt 7: Den Eval Viewer starten

Der Eval Viewer zeigt sowohl qualitative Ausgaben als auch quantitative Metriken in einer Browser-Oberfläche an.

Den Viewer generieren

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

Für Iteration 2+ auch --previous-workspace übergeben:

--previous-workspace api-tester-workspace/iteration-1

Was der Benutzer sieht

Der Tab Ausgaben zeigt jeweils einen Testfall an:

Prompt – Die gegebene Aufgabe
Ausgabe – Erzeugte Dateien, inline gerendert
Vorherige Ausgabe (Iteration 2+) – Eingeklappter Abschnitt mit der Ausgabe der letzten Iteration
Formale Bewertungen – Eingeklapptes Bestanden/Fehlgeschlagen der Behauptungen
Feedback – Textfeld, das automatisch speichert, während getippt wird
Vorheriges Feedback (Iteration 2+) – Kommentare aus der letzten Iteration

Der Tab Benchmark zeigt:

Erfolgsquoten für jede Konfiguration
Zeitvergleiche
Token-Nutzung
Aufschlüsselungen pro Eval
Analystenbeobachtungen

Sagen Sie dem Benutzer: „Ich habe die Ergebnisse in Ihrem Browser geöffnet. Es gibt zwei Tabs – ‚Ausgaben‘ lässt Sie jeden Testfall durchklicken und Feedback hinterlassen, ‚Benchmark‘ zeigt den quantitativen Vergleich. Wenn Sie fertig sind, kommen Sie hierher zurück und lassen Sie es mich wissen.“

Zusammenarbeit / Headless-Umgebungen

Wenn webbrowser.open() nicht verfügbar ist, verwenden Sie --static, um eine eigenständige HTML-Datei zu schreiben:

--static /pfad/zum/output/review.html

Feedback wird als feedback.json heruntergeladen, wenn der Benutzer auf „Alle Bewertungen senden“ klickt.

Schritt 8: Feedback lesen und iterieren

Wenn der Benutzer fertig ist, lesen Sie feedback.json:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "Im Diagramm fehlen Achsenbeschriftungen",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "perfekt, gefällt mir sehr",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

Leeres Feedback bedeutet, der Benutzer fand es in Ordnung. Konzentrieren Sie Verbesserungen auf Testfälle mit spezifischen Beschwerden.

Wie man über Verbesserungen nachdenkt

Aus Feedback verallgemeinern: Sie erstellen Skills, die Tausende Male über viele Prompts hinweg verwendet werden. Passen Sie nicht zu stark an spezifische Testfälle an. Wenn es ein hartnäckiges Problem gibt, versuchen Sie verschiedene Metaphern oder Muster anstelle von restriktiven MUSS-Anweisungen.

Den Prompt schlank halten: Entfernen Sie, was nicht zielführend ist. Lesen Sie die Transkripte, nicht nur die Endergebnisse. Wenn der Skill das Modell dazu bringt, Zeit mit unproduktiven Schritten zu verschwenden, entfernen Sie diese Teile.

Das Warum erklären: LLMs haben eine gute „Theory of Mind“. Wenn sie eine gute Führung erhalten, gehen sie über reine Anweisungen hinaus. Erklären Sie, warum jede Anforderung wichtig ist. Wenn Sie sich dabei ertappen, IMMER oder NIEMALS in Großbuchstaben zu schreiben, formulieren Sie es um und erklären Sie stattdessen die Begründung.

Nach wiederholter Arbeit suchen: Haben alle Testfälle unabhängig voneinander ähnliche Hilfsskripte geschrieben? Das ist ein Signal, dass der Skill dieses Skript bündeln sollte. Schreiben Sie es einmal, legen Sie es in scripts/ ab und weisen Sie den Skill an, es zu verwenden.

Die Iterationsschleife

Verbesserungen am Skill anwenden
Alle Testfälle erneut in iteration-<N+1>/ mit Baseline-Läufen ausführen
Den Viewer mit --previous-workspace starten, das auf die vorherige Iteration zeigt
Auf Benutzerprüfung warten
Neues Feedback lesen, erneut verbessern, wiederholen

Fahren Sie fort, bis:

Der Benutzer sagt, er sei zufrieden
Das Feedback ist komplett leer (alles sieht gut aus)
Sie keine sinnvollen Fortschritte mehr machen

Beenden Sie den Viewer, wenn Sie fertig sind:

kill $VIEWER_PID 2>/dev/null

Schritt 9: Die Skill-Beschreibung optimieren

Das Beschreibungsfeld im Frontmatter von SKILL.md ist der primäre Auslösemechanismus. Nach der Erstellung oder Verbesserung eines Skills optimieren Sie ihn für eine bessere Auslösegenauigkeit.

Auslöser-Evaluierungsabfragen generieren

Erstellen Sie 20 Evaluierungsabfragen – eine Mischung aus „sollte auslösen“ und „sollte nicht auslösen“:

[
  {
    "query": "ok, mein Chef hat mir gerade diese xlsx-Datei geschickt (sie ist in meinen Downloads, heißt so etwas wie 'Q4 sales final FINAL v2.xlsx') und sie möchte, dass ich eine Spalte hinzufüge, die die Gewinnmarge als Prozentsatz anzeigt. Der Umsatz ist in Spalte C und die Kosten sind, glaube ich, in Spalte D",
    "should_trigger": true
  },
  {
    "query": "Ich muss aus dieser CSV eine Pivot-Tabelle erstellen und sie an das Team mailen",
    "should_trigger": false
  }
]

Für „sollte auslösen“-Abfragen (8-10):

Verschiedene Formulierungen derselben Absicht
Formelle und informelle Sprache
Fälle, in denen Benutzer den Skill nicht explizit benennen, ihn aber eindeutig benötigen
Grenzfälle und ungewöhnliche Anwendungsfälle

Für „sollte nicht auslösen“-Abfragen (8-10):

Beinahe-Treffer, die Schlüsselwörter teilen, aber etwas anderes benötigen
Angrenzende Domänen, wo ein anderes Tool besser geeignet ist
Zweideutige Formulierungen, bei denen ein naives Keyword-Matching fälschlicherweise auslösen würde

Schlechte Negativtests: „Eine Fibonacci-Funktion schreiben“ als Negativtest für einen PDF-Skill ist zu einfach. Die negativen Fälle sollten wirklich knifflig sein.

Mit Benutzer überprüfen

Präsentieren Sie den Evaluierungssatz mit der HTML-Vorlage:

Lesen Sie assets/eval_review.html
Ersetzen Sie Platzhalter durch Evaluierungsdaten, Skill-Namen und Beschreibung
In temporäre Datei schreiben und öffnen: open /tmp/eval_review_api-tester.html
Benutzer kann Abfragen bearbeiten, „sollte auslösen“ umschalten, Einträge hinzufügen/entfernen
Benutzer klickt auf „Evaluierungssatz exportieren“
Datei wird nach ~/Downloads/eval_set.json heruntergeladen

Dieser Schritt ist wichtig. Schlechte Evaluierungsabfragen führen zu schlechten Beschreibungen.

Die Optimierungsschleife ausführen

python -m scripts.run_loop \
  --eval-set /pfad/zu/trigger-eval.json \
  --skill-path /pfad/zu/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

Verwenden Sie die Modell-ID, die Ihre aktuelle Sitzung antreibt, damit die Auslösetests dem entsprechen, was Benutzer erleben.

Das Skript:

Teilt den Evaluierungssatz in 60 % Trainings- und 40 % gehaltene Testdaten auf
Bewertet die aktuelle Beschreibung (jeweils 3 Läufe für Zuverlässigkeit)
Ruft Claude auf, um Verbesserungen basierend auf Fehlern vorzuschlagen
Bewertet erneut auf Trainings- und Testdaten
Iteriert bis zu 5 Mal
Gibt best_description zurück, ausgewählt nach Test-Score (nicht Trainings-Score, um Überanpassung zu vermeiden)

Das Ergebnis anwenden

Nehmen Sie best_description aus der JSON-Ausgabe und aktualisieren Sie das Frontmatter der SKILL.md-Datei des Skills. Zeigen Sie dem Benutzer Vorher/Nachher mit Scores.

Vorher:

description: Ein Skill zum systematischen Testen von REST-APIs

Nachher:

description: So testen Sie REST-APIs systematisch. Verwenden Sie diesen Skill, wenn Benutzer API-Tests, Endpunkte, REST, GraphQL erwähnen oder API-Antworten validieren möchten. Achten Sie darauf, diesen Skill immer dann vorzuschlagen, wenn Tests involviert sind, auch wenn sie 'Testing' nicht explizit erwähnen.

Schritt 10: Paketieren und Verteilen

Sobald der Skill fertig ist, verpacken Sie ihn zur Verteilung:

python -m scripts.package_skill /pfad/zu/api-tester

Dies erstellt eine .skill-Datei, die Benutzer installieren können. Weisen Sie Benutzer auf den resultierenden Dateipfad hin.

Installation

Benutzer installieren Skills, indem sie die .skill-Datei in ihr Skill-Verzeichnis legen oder den Claude Code Skill-Installationsbefehl verwenden.

Häufige Fehler bei der Skill-Erstellung

Fehler 1: Vage Beschreibung

Schlecht:

description: Ein Skill für die Arbeit mit APIs

Gut:

description: So testen Sie REST-APIs systematisch. Verwenden Sie diesen Skill, wenn Benutzer API-Tests, Endpunkte, REST, GraphQL erwähnen oder API-Antworten validieren möchten. Achten Sie darauf, diesen Skill immer dann vorzuschlagen, wenn Tests involviert sind, auch wenn sie 'Testing' nicht explizit erwähnen.

Fehler 2: Übermäßig restriktive Anweisungen

Schlecht:

Verwenden Sie IMMER genau dieses Format. Weichen Sie NIEMALS ab. MUSS diese Abschnitte enthalten.

Gut:

Verwenden Sie dieses Format, da es sicherstellt, dass Stakeholder die benötigten Informationen schnell finden. Wenn Ihr Publikum andere Bedürfnisse hat, passen Sie die Struktur entsprechend an.

Fehler 3: Das Überspringen von Testfällen

Testfälle fangen Probleme ab, bevor Benutzer darauf stoßen. Selbst bei subjektiven Skills sollten Sie 2-3 Beispiele durchführen, um die Qualität der Ausgabe zu überprüfen.

Fehler 4: Ignorieren von Zeitdaten

Skills, die 10x länger dauern, sind nicht nachhaltig. Erfassen Sie Zeitdaten und optimieren Sie die Effizienz parallel zur Qualität.

Fehler 5: Wiederholte Skripte nicht bündeln

Wenn jeder Testlauf unabhängig ein generate_report.py schreibt, bündeln Sie es im Skill. Das spart Zeit und gewährleistet Konsistenz.

Praxisbeispiele für Skills

MCP Builder Skill

Von Anthropic zum Erstellen von MCP (Model Context Protocol)-Servern entwickelt.

Hauptmerkmale:

Python- und Node.js-Vorlagen
Evaluierungsframework für MCP-Server
Best Practices Referenzdokumente

Struktur:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Docx Skill

Generiert Word-Dokumente programmatisch.

Hauptmerkmale:

Gebündelte python-docx-Skripte
Vorlagensystem für gängige Dokumente
Styling-Leitfaden für konsistente Formatierung

Workflow:

Dokumentanforderungen verstehen
Vorlage auswählen oder erstellen
Über python-docx-Skript generieren
Ausgabe-Struktur validieren

Frontend Design Skill

Erstellt Web-Interfaces mit modernen Mustern.

Hauptmerkmale:

Komponentenbibliothek
Tailwind CSS Muster
Zugänglichkeitsprüfungen

Progressive Offenlegung: Kern-Workflow in SKILL.md, Komponentendokumentation in references/.

Testen Ihres Skills mit Apidog

Wenn Sie API-bezogene Skills entwickeln, lässt sich Apidog nahtlos in den Workflow integrieren.

Beispiel: API-Test-Skill-Integration

## API-Tests ausführen

Verwenden Sie Apidog für systematische Tests:

1. Importieren Sie die OpenAPI-Spezifikation in Apidog
2. Generieren Sie Testfälle aus der Spezifikation
3. Führen Sie Tests aus und exportieren Sie die Ergebnisse als JSON
4. Validieren Sie die Antworten anhand der erwarteten Schemas

Für benutzerdefinierte Behauptungen verwenden Sie die Skripting-Funktion von Apidog.

Apidog-Skripte bündeln

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

Das erspart jede zukünftige Aufrufung, das Rad neu zu erfinden.

Fazit

Claude Code Skills erweitern Claudes Fähigkeiten für Ihre spezifischen Arbeitsabläufe. Das Skill Creator System bietet einen systematischen Prozess:

Absicht erfassen – Definieren Sie, was der Skill tun soll
SKILL.md entwerfen – Schreiben Sie klare Anweisungen mit Beispielen
Testfälle erstellen – Realistische Prompts, die Benutzer tatsächlich stellen würden
Bewertungen durchführen – Parallele Ausführung mit und ohne Skill
Ergebnisse überprüfen – Qualitatives Feedback + quantitative Benchmarks
Iterieren – Basierend auf den Erkenntnissen verbessern
Beschreibung optimieren – Auslösegenauigkeit maximieren
Paket schnüren – Als .skill-Datei verteilen

Button

FAQ

Wie lange dauert es, einen Skill zu erstellen?

Einfache Skills dauern 15-30 Minuten. Komplexe Skills mit mehreren Referenzdateien und gebündelten Skripten können 2-3 Stunden einschließlich Evaluierungs-Iterationen in Anspruch nehmen.

Muss ich für jeden Skill Testfälle schreiben?

Nein. Skills mit objektiv überprüfbaren Ausgaben (Code-Generierung, Dateiumwandlungen, Datenextraktion) profitieren von Testfällen. Skills mit subjektiven Ausgaben (Schreibstil, Designqualität) werden besser qualitativ bewertet.

Was, wenn mein Skill nicht zuverlässig ausgelöst wird?

Optimieren Sie das Beschreibungsfeld. Fügen Sie spezifische Auslösephrasen und Kontexte hinzu. Machen Sie es etwas „aufdringlich“ – geben Sie explizit an, wann der Skill verwendet werden soll. Führen Sie die Beschreibung-Optimierungsschleife mit 20 Evaluierungsabfragen aus.

Wie teile ich Skills mit meinem Team?

Paketieren Sie den Skill mit python -m scripts.package_skill <Pfad> und verteilen Sie dann die .skill-Datei. Teammitglieder legen sie in ihr Skills-Verzeichnis.

Können Skills externe APIs aufrufen?

Ja. Bündeln Sie Skripte, die API-Aufrufe tätigen. Die Skill-Anweisungen sagen Claude, wann und wie sie diese verwenden soll. Speichern Sie API-Schlüssel in Umgebungsvariablen, nicht im Skill selbst.

Wie groß ist die Dateigrößenbegrenzung für Skills?

Es gibt keine feste Begrenzung, aber halten Sie SKILL.md unter 500 Zeilen. Verschieben Sie detaillierte Referenzen in separate Dateien. Skripte und Assets zählen nicht zur Zeilenbegrenzung, da sie bei Bedarf geladen werden.

Wie aktualisiere ich einen bestehenden Skill?

Kopieren Sie den installierten Skill an einen beschreibbaren Ort, bearbeiten Sie ihn dort und paketieren Sie ihn neu. Behalten Sie den Originalnamen bei – fügen Sie keine Versionssuffixe hinzu, es sei denn, Sie erstellen eine eigenständige Variante.