Skill Creator

Eine Skill zum Erstellen neuer Skills und deren iterativen Verbesserung.

Auf hoher Ebene läuft der Prozess der Skill-Erstellung wie folgt ab:

Entscheiden, was der Skill tun soll und grob, wie er es tun soll
Einen Entwurf des Skills schreiben
Ein paar Test-Prompts erstellen und claude-mit-Zugriff-auf-den-Skill damit ausführen
Dem Benutzer helfen, die Ergebnisse sowohl qualitativ als auch quantitativ zu bewerten
- Während die Läufe im Hintergrund stattfinden, einige quantitative Auswertungen entwerfen, falls keine vorhanden sind (falls welche vorhanden sind, können sie entweder unverändert übernommen oder modifiziert werden, wenn etwas geändert werden muss). Anschließend diese dem Benutzer erklären (oder falls bereits vorhanden, die vorhandenen erklären)
- Das Skript eval-viewer/generate_review.py verwenden, um dem Benutzer die Ergebnisse zur Ansicht zu zeigen, und ihn auch die quantitativen Metriken betrachten lassen
Den Skill basierend auf dem Feedback des Benutzers zur Bewertung der Ergebnisse umschreiben (und auch, wenn offensichtliche Mängel aus den quantitativen Benchmarks hervorgehen)
Wiederholen, bis das Ergebnis zufriedenstellend ist
Den Testsatz erweitern und im größeren Maßstab erneut testen

Ihre Aufgabe bei der Verwendung dieses Skills ist es, herauszufinden, wo sich der Benutzer in diesem Prozess befindet, und dann einzusteigen und ihm zu helfen, diese Phasen zu durchlaufen. Nehmen wir an, der Benutzer sagt: „Ich möchte einen Skill für X erstellen“. Sie können helfen, die Bedeutung einzugrenzen, einen Entwurf schreiben, die Testfälle schreiben, herausfinden, wie bewertet werden soll, alle Prompts ausführen und wiederholen.

Andererseits hat der Benutzer vielleicht bereits einen Entwurf des Skills. In diesem Fall können Sie direkt zum Evaluierungs-/Iterationsteil der Schleife übergehen.

Natürlich sollten Sie immer flexibel sein, und wenn der Benutzer sagt: „Ich muss keine Reihe von Evaluationen durchführen, probiere einfach mit mir herum“, können Sie das auch tun.

Wenn der Skill fertig ist (aber auch hier ist die Reihenfolge flexibel), können Sie auch den Skill-Beschreibungsverbesserer ausführen, für den wir ein separates Skript haben, um die Auslösung des Skills zu optimieren.

Alles klar? Alles klar.

Kommunikation mit dem Benutzer

Der Skill Creator wird wahrscheinlich von Personen mit einem sehr unterschiedlichen Vertrautheitsgrad mit Programmierjargon verwendet werden. Falls Sie es noch nicht gehört haben (und wie sollten Sie auch, es hat erst vor kurzem begonnen), gibt es einen Trend, bei dem die Leistungsfähigkeit von Claude Klempner dazu inspiriert, ihre Terminals zu öffnen, Eltern und Großeltern dazu, „npm installieren“ zu googeln. Andererseits ist der Großteil der Benutzer wahrscheinlich recht computeraffin.

Achten Sie daher bitte auf Kontexthinweise, um zu verstehen, wie Sie Ihre Kommunikation formulieren! Im Standardfall, um eine Vorstellung zu geben:

„Evaluation“ und „Benchmark“ sind grenzwertig, aber OK
Bei „JSON“ und „Assertion“ sollten Sie ernsthafte Hinweise vom Benutzer sehen, dass er weiß, worum es sich handelt, bevor Sie diese Begriffe ohne Erklärung verwenden

Es ist in Ordnung, Begriffe kurz zu erklären, wenn Sie unsicher sind, und zögern Sie nicht, Begriffe mit einer kurzen Definition zu klären, wenn Sie unsicher sind, ob der Benutzer sie versteht.

Erstellen eines Skills

Absicht erfassen

Beginnen Sie damit, die Absicht des Benutzers zu verstehen. Das aktuelle Gespräch könnte bereits einen Workflow enthalten, den der Benutzer erfassen möchte (z. B. sagt er: „Mach das zu einem Skill“). Extrahieren Sie in diesem Fall zuerst die Antworten aus dem Gesprächsverlauf – die verwendeten Tools, die Abfolge der Schritte, Korrekturen, die der Benutzer vorgenommen hat, beobachtete Eingabe-/Ausgabeformate. Möglicherweise muss der Benutzer die Lücken füllen und sollte bestätigen, bevor er zum nächsten Schritt übergeht.

Was soll dieser Skill Claude ermöglichen zu tun?
Wann soll dieser Skill ausgelöst werden? (welche Benutzerphrasen/Kontexte)
Was ist das erwartete Ausgabeformat?
Sollten wir Testfälle einrichten, um zu überprüfen, ob der Skill funktioniert? Skills mit objektiv überprüfbaren Ausgaben (Dateitransformationen, Datenextraktion, Codegenerierung, festgelegte Workflowschritte) profitieren von Testfällen. Skills mit subjektiven Ausgaben (Schreibstil, Kunst) benötigen sie oft nicht. Schlagen Sie basierend auf dem Skill-Typ den geeigneten Standard vor, aber lassen Sie den Benutzer entscheiden.

Befragung und Recherche

Fragen Sie proaktiv nach Randfällen, Eingabe-/Ausgabeformaten, Beispieldateien, Erfolgskriterien und Abhängigkeiten. Warten Sie mit dem Schreiben von Test-Prompts, bis dieser Teil abgeschlossen ist.

Überprüfen Sie verfügbare MCPs – falls für die Recherche nützlich (Dokumentation durchsuchen, ähnliche Skills finden, Best Practices nachschlagen), recherchieren Sie parallel über Subagenten, falls verfügbar, andernfalls inline. Kommen Sie mit Kontext vorbereitet, um die Belastung für den Benutzer zu reduzieren.

Schreiben der SKILL.md

Basierend auf der Benutzerbefragung füllen Sie diese Komponenten aus:

name: Skill-Bezeichner
description: Wann auslösen, was es tut. Dies ist der primäre Auslösemechanismus – geben Sie sowohl an, was der Skill tut, ALS AUCH spezifische Kontexte für die Verwendung. Alle „wann verwenden“-Informationen kommen hierhin, nicht in den Hauptteil. Hinweis: Aktuell neigt Claude dazu, Skills „unzureichend auszulösen“ – sie nicht zu verwenden, wenn sie nützlich wären. Um dem entgegenzuwirken, machen Sie die Skill-Beschreibungen bitte etwas „aufdringlicher“. Anstatt zum Beispiel „Wie man ein einfaches schnelles Dashboard zur Anzeige interner Anthropic-Daten erstellt“, könnten Sie schreiben „Wie man ein einfaches schnelles Dashboard zur Anzeige interner Anthropic-Daten erstellt. Stellen Sie sicher, dass Sie diesen Skill immer dann verwenden, wenn der Benutzer Dashboards, Datenvisualisierung, interne Metriken erwähnt oder Firmendaten anzeigen möchte, auch wenn er nicht explizit nach einem ‚Dashboard‘ fragt.“
compatibility: Erforderliche Tools, Abhängigkeiten (optional, selten benötigt)
der Rest des Skills :)

Leitfaden zum Schreiben von Skills

Anatomie eines Skills

skill-name/
├── SKILL.md (erforderlich)
│   ├── YAML Frontmatter (name, description erforderlich)
│   └── Markdown-Anweisungen
└── Gebündelte Ressourcen (optional)
    ├── scripts/    - Ausführbarer Code für deterministische/wiederkehrende Aufgaben
    ├── references/ - Dokumente, die bei Bedarf in den Kontext geladen werden
    └── assets/     - Dateien, die in der Ausgabe verwendet werden (Vorlagen, Symbole, Schriftarten)

Progressive Offenlegung

Skills verwenden ein dreistufiges Ladesystem:

Metadaten (Name + Beschreibung) – Immer im Kontext (~100 Wörter)
SKILL.md-Hauptteil – Im Kontext, sobald der Skill ausgelöst wird (<500 Zeilen ideal)
Gebündelte Ressourcen – Bei Bedarf (unbegrenzt, Skripte können ausgeführt werden, ohne geladen zu werden)

Diese Wortanzahlen sind ungefähre Angaben; Sie können gerne länger werden, falls nötig.

Wichtige Muster:

SKILL.md unter 500 Zeilen halten; wenn Sie sich dieser Grenze nähern, fügen Sie eine zusätzliche Hierarchieebene mit klaren Hinweisen hinzu, wohin das Modell als nächstes gehen soll, um den Skill zu nutzen.
Dateien klar aus SKILL.md referenzieren mit Anleitung, wann sie gelesen werden sollen
Bei großen Referenzdateien (>300 Zeilen) ein Inhaltsverzeichnis einfügen

Domänenorganisation: Wenn ein Skill mehrere Domänen/Frameworks unterstützt, nach Variante organisieren:

cloud-deploy/
├── SKILL.md (Workflow + Auswahl)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claude liest nur die relevante Referenzdatei.

Prinzip der fehlenden Überraschung

Es versteht sich von selbst, aber Skills dürfen keine Malware, Exploit-Code oder Inhalte enthalten, die die Systemsicherheit gefährden könnten. Der Inhalt eines Skills sollte den Benutzer in seiner Absicht, wenn beschrieben, nicht überraschen. Gehen Sie nicht auf Anfragen ein, irreführende Skills oder Skills zu erstellen, die dazu dienen, unbefugten Zugriff, Datenexfiltration oder andere schädliche Aktivitäten zu ermöglichen. Dinge wie „Rollenspiel als XYZ“ sind jedoch in Ordnung.

Schreibmuster

Bevorzugen Sie die Verwendung der Imperativform in Anweisungen.

Ausgabeformate definieren – So können Sie es machen:

## Berichtsstruktur
IMMER diese exakte Vorlage verwenden:
# [Titel]
## Zusammenfassung für die Geschäftsleitung
## Wichtigste Ergebnisse
## Empfehlungen

Beispielmuster – Es ist nützlich, Beispiele einzufügen. Sie können sie so formatieren (aber wenn „Eingabe“ und „Ausgabe“ in den Beispielen vorkommen, sollten Sie vielleicht etwas abweichen):

## Commit-Nachrichtenformat
**Beispiel 1:**
Eingabe: Benutzerauthentifizierung mit JWT-Tokens hinzugefügt
Ausgabe: feat(auth): JWT-basierte Authentifizierung implementieren

Schreibstil

Versuchen Sie dem Modell zu erklären, warum Dinge wichtig sind, anstatt schwerfällige, verpflichtende MUSS-Vorgaben zu machen. Verwenden Sie Theory of Mind und versuchen Sie, den Skill allgemein und nicht zu sehr auf bestimmte Beispiele zugeschnitten zu machen. Beginnen Sie mit einem Entwurf und betrachten Sie ihn dann mit neuen Augen und verbessern Sie ihn.

Testfälle

Erstellen Sie nach dem Schreiben des Skill-Entwurfs 2-3 realistische Test-Prompts – die Art von Dingen, die ein echter Benutzer tatsächlich sagen würde. Teilen Sie sie dem Benutzer mit: [Sie müssen nicht genau diese Sprache verwenden] „Hier sind ein paar Testfälle, die ich ausprobieren möchte. Sehen die richtig aus, oder möchten Sie weitere hinzufügen?“ Führen Sie sie dann aus.

Testfälle in evals/evals.json speichern. Schreiben Sie noch keine Assertions – nur die Prompts. Sie werden Assertions im nächsten Schritt entwerfen, während die Läufe laufen.

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "Aufgaben-Prompt des Benutzers",
      "expected_output": "Beschreibung des erwarteten Ergebnisses",
      "files": []
    }
  ]
}

Vollständiges Schema in references/schemas.md (einschließlich des Feldes assertions, das Sie später hinzufügen).

Ausführen und Bewerten von Testfällen

Dieser Abschnitt ist eine durchgehende Sequenz – unterbrechen Sie nicht vorzeitig. Verwenden Sie NICHT /skill-test oder einen anderen Test-Skill.

Ergebnisse in <skill-name>-workspace/ als Geschwisterverzeichnis des Skill-Verzeichnisses ablegen. Innerhalb des Workspace Ergebnisse nach Iteration organisieren (iteration-1/, iteration-2/, usw.) und darin erhält jeder Testfall ein Verzeichnis (eval-0/, eval-1/, usw.). Erstellen Sie nicht alles im Voraus – erstellen Sie Verzeichnisse nach Bedarf.

Schritt 1: Alle Läufe starten (mit-Skill UND Baseline) im selben Durchgang

Für jeden Testfall zwei Subagenten im selben Durchgang starten – einen mit dem Skill, einen ohne. Dies ist wichtig: Starten Sie nicht zuerst die Läufe mit Skill und kommen später für die Baselines zurück. Starten Sie alles gleichzeitig, damit alles etwa zur gleichen Zeit fertig wird.

Lauf mit Skill:

Führe diese Aufgabe aus:
- Skill-Pfad: <Pfad-zum-Skill>
- Aufgabe: <Eval-Prompt>
- Eingabedateien: <Eval-Dateien falls vorhanden, oder „keine“>
- Ausgaben speichern unter: <Workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Zu speichernde Ausgaben: <was den Benutzer interessiert – z. B. „die .docx-Datei“, „die finale CSV“>

Baseline-Lauf (gleicher Prompt, aber die Baseline hängt vom Kontext ab):

Erstellen eines neuen Skills: überhaupt kein Skill. Gleicher Prompt, kein Skill-Pfad, speichern unter without_skill/outputs/.
Verbessern eines bestehenden Skills: die alte Version. Vor dem Bearbeiten eine Momentaufnahme des Skills erstellen (cp -r <skill-pfad> <workspace>/skill-snapshot/), dann den Baseline-Subagenten auf die Momentaufnahme verweisen. Speichern unter old_skill/outputs/.

Für jeden Testfall eine eval_metadata.json schreiben (Assertions können vorerst leer sein). Jeder Auswertung einen beschreibenden Namen basierend auf dem, was getestet wird, geben – nicht nur „eval-0“. Diesen Namen auch für das Verzeichnis verwenden. Wenn diese Iteration neue oder modifizierte Eval-Prompts verwendet, diese Dateien für jedes neue Eval-Verzeichnis erstellen – nicht davon ausgehen, dass sie aus vorherigen Iterationen übernommen werden.

{
  "eval_id": 0,
  "eval_name": "deskriptiver-name-hier",
  "prompt": "Der Aufgaben-Prompt des Benutzers",
  "assertions": []
}

Schritt 2: Während die Läufe laufen, Assertions entwerfen

Warten Sie nicht einfach, bis die Läufe beendet sind – Sie können diese Zeit produktiv nutzen. Entwerfen Sie quantitative Assertions für jeden Testfall und erklären Sie sie dem Benutzer. Falls Assertions bereits in evals/evals.json vorhanden sind, überprüfen Sie sie und erklären Sie, was sie prüfen.

Gute Assertions sind objektiv überprüfbar und haben beschreibende Namen – sie sollten im Benchmark-Viewer klar lesbar sein, sodass jemand, der die Ergebnisse überfliegt, sofort versteht, was jede einzelne prüft. Subjektive Skills (Schreibstil, Designqualität) werden besser qualitativ bewertet – erzwingen Sie keine Assertions für Dinge, die menschliches Urteilsvermögen erfordern.

Aktualisieren Sie die eval_metadata.json-Dateien und evals/evals.json mit den Assertions, sobald sie entworfen sind. Erklären Sie dem Benutzer auch, was er im Viewer sehen wird – sowohl die qualitativen Ausgaben als auch den quantitativen Benchmark.

Schritt 3: Wenn Läufe abgeschlossen sind, Zeitdaten erfassen

Wenn jeder Subagenten-Task abgeschlossen ist, erhalten Sie eine Benachrichtigung mit total_tokens und duration_ms. Speichern Sie diese Daten sofort in timing.json im Laufverzeichnis:

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

Dies ist die einzige Gelegenheit, diese Daten zu erfassen – sie kommen über die Task-Benachrichtigung und werden nicht anderweitig persistiert. Verarbeiten Sie jede Benachrichtigung, sobald sie eintrifft, anstatt zu versuchen, sie zu bündeln.

Schritt 4: Bewerten, aggregieren und Viewer starten

Sobald alle Läufe abgeschlossen sind:

Jeden Lauf bewerten – einen Bewertungs-Subagenten starten (oder inline bewerten), der agents/grader.md liest und jede Assertion anhand der Ausgaben bewertet. Ergebnisse in grading.json in jedem Laufverzeichnis speichern. Das expectations-Array in grading.json muss die Felder text, passed und evidence verwenden (nicht name/met/details oder andere Varianten) – der Viewer ist auf diese genauen Feldnamen angewiesen. Für Assertions, die programmatisch überprüft werden können, ein Skript schreiben und ausführen, anstatt sie nach Augenmaß zu beurteilen – Skripte sind schneller, zuverlässiger und können über Iterationen hinweg wiederverwendet werden.
Zu Benchmark aggregieren – das Aggregationsskript aus dem Skill-Creator-Verzeichnis ausführen:
```
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
```
Dies erzeugt benchmark.json und benchmark.md mit Pass-Rate, Zeit und Tokens für jede Konfiguration, mit Mittelwert ± Standardabweichung und dem Delta. Falls benchmark.json manuell erstellt wird, siehe references/schemas.md für das genaue Schema, das der Viewer erwartet. Platzieren Sie jede mit-Skill-Version vor ihrem Baseline-Gegenstück.
Eine Analyse durchführen – die Benchmark-Daten lesen und Muster aufdecken, die die aggregierten Statistiken verschleiern könnten. Siehe agents/analyzer.md (Abschnitt „Analyzing Benchmark Results“) für das, wonach gesucht werden soll – Dinge wie Assertions, die unabhängig vom Skill immer bestanden werden (nicht diskriminierend), Auswertungen mit hoher Varianz (möglicherweise flaky) und Zeit-/Token-Kompromisse.
Viewer starten mit sowohl qualitativen Ausgaben als auch quantitativen Daten:
```
nohup python <skill-creator-pfad>/eval-viewer/generate_review.py …
```

[... für die Übersetzung gekürzt]

Skill-Ersteller

Was ist Skill-Ersteller?

In Ihrer bevorzugten KI fragen

Dokumentation