Skill-Ersteller

Was macht Skill-Ersteller?

Ein Skill zum Erstellen neuer Skills und deren iterative Verbesserung.

Auf hoher Ebene läuft der Prozess der Skillerstellung wie folgt ab:

• Lege fest, was der Skill tun soll und grob, wie er es tun soll
• Schreibe einen Entwurf des Skills
• Erstelle ein paar Test-Prompts und führe sie mit Claude aus, der Zugriff auf den Skill hat
• Hilf dem Benutzer, die Ergebnisse sowohl qualitativ als auch quantitativ zu bewerten
  • Während die Läufe im Hintergrund laufen, entwirf einige quantitative Evaluierungen, falls keine vorhanden sind (falls es welche gibt, kannst du sie entweder unverändert verwenden oder anpassen, wenn du denkst, dass etwas geändert werden muss). Erkläre sie dem Benutzer (oder falls sie bereits existieren, erkläre die, die bereits existieren)
  • Verwende das Skript eval-viewer/generate_review.py, um dem Benutzer die Ergebnisse zur Ansicht zu zeigen, und lass ihn auch die quantitativen Metriken betrachten
• Schreibe den Skill basierend auf dem Feedback des Benutzers aus der Auswertung der Ergebnisse um (und auch, wenn offensichtliche Mängel aus den quantitativen Benchmarks hervorgehen)
• Wiederhole den Vorgang, bis du zufrieden bist
• Erweitere den Testsatz und versuche es in größerem Maßstab erneut

Deine Aufgabe bei der Verwendung dieses Skills ist es, herauszufinden, wo sich der Benutzer in diesem Prozess befindet, und dann einzuspringen und ihm zu helfen, diese Phasen zu durchlaufen. Wenn er beispielsweise sagt: „Ich möchte einen Skill für X erstellen“, kannst du helfen, einzugrenzen, was gemeint ist, einen Entwurf schreiben, die Testfälle schreiben, herausfinden, wie er evaluieren möchte, alle Prompts ausführen und wiederholen.

Wenn der Benutzer hingegen bereits einen Entwurf des Skills hat, kannst du direkt zum Evaluierungs-/Iterationsteil der Schleife übergehen.

Natürlich solltest du immer flexibel sein, und wenn der Benutzer sagt „Ich muss keine Reihe von Evaluierungen durchführen, lass es einfach auf mich wirken“, kannst du das auch tun.

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

Cool? Cool.

Kommunikation mit dem Benutzer

Der Skill-Ersteller wird wahrscheinlich von Personen mit einem sehr breiten Spektrum an Vertrautheit mit Programmierjargon verwendet werden. Falls du es noch nicht gehört hast (und wie könntest du, es ist erst seit kurzem so), gibt es jetzt einen Trend, bei dem die Leistungsfähigkeit von Claude Klempner dazu inspiriert, ihre Terminals zu öffnen, und Eltern und Großeltern dazu, zu googeln, „wie man npm installiert“. Auf der anderen Seite ist der Großteil der Benutzer wahrscheinlich ziemlich computeraffin.

Achte also bitte auf Kontexthinweise, um zu verstehen, wie du deine Kommunikation formulieren solltest! Im Standardfall, nur um dir eine Vorstellung zu geben:

• „Evaluation“ und „Benchmark“ sind grenzwertig, aber in Ordnung
• Bei „JSON“ und „Assertion“ solltest du ernsthafte Hinweise vom Benutzer sehen, dass er weiß, was diese Dinge sind, bevor du sie ohne Erklärung verwendest

Es ist in Ordnung, Begriffe kurz zu erklären, wenn du dir unsicher bist, und zögere nicht, Begriffe mit einer kurzen Definition zu klären, wenn du nicht sicher bist, ob der Benutzer sie versteht.

Erstellen eines Skills

Intent erfassen

Beginne 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“). Wenn ja, extrahiere zuerst Antworten aus dem Gesprächsverlauf – die verwendeten Werkzeuge, die Abfolge der Schritte, Korrekturen, die der Benutzer vorgenommen hat, beobachtete Eingabe-/Ausgabeformate. Der Benutzer muss möglicherweise die Lücken füllen und sollte bestätigen, bevor er zum nächsten Schritt übergeht.

1. Was soll dieser Skill Claude ermöglichen zu tun?
2. Wann soll dieser Skill ausgelöst werden? (welche Benutzerphrasen/Kontexte)
3. Was ist das erwartete Ausgabeformat?
4. Sollten wir Testfälle einrichten, um zu überprüfen, ob der Skill funktioniert? Skills mit objektiv überprüfbaren Ausgaben (Dateitransformationen, Datenextraktion, Codegenerierung, feste Workflow-Schritte) profitieren von Testfällen. Skills mit subjektiven Ausgaben (Schreibstil, Kunst) brauchen sie oft nicht. Schlage den geeigneten Standard basierend auf dem Skill-Typ vor, aber überlasse dem Benutzer die Entscheidung.

Interview und Recherche

Stelle proaktiv Fragen zu Randfällen, Ein-/Ausgabeformaten, Beispieldateien, Erfolgskriterien und Abhängigkeiten. Warte mit dem Schreiben von Test-Prompts, bis dieser Teil geklärt ist.

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

Schreibe die SKILL.md

Basierend auf dem Benutzerinterview fülle diese Komponenten aus:

• name: Skill-Identifikator
• description: Wann auslösen, was er tut. Dies ist der primäre Auslösemechanismus – sowohl das, was der Skill tut, als auch spezifische Kontexte, wann er verwendet werden soll. Alle „wann verwenden“-Informationen gehören hierhin, nicht in den Hauptteil. Hinweis: Claude neigt derzeit dazu, Skills „zu wenig auszulösen“ – sie nicht zu verwenden, wenn sie nützlich wären. Um dem entgegenzuwirken, mache die Skill-Beschreibungen bitte ein wenig „aufdringlich“. Anstatt „Wie man ein einfaches schnelles Dashboard zur Anzeige interner Anthropic-Daten erstellt“ könntest du schreiben: „Wie man ein einfaches schnelles Dashboard zur Anzeige interner Anthropic-Daten erstellt. Stelle sicher, dass dieser Skill immer dann verwendet wird, wenn der Benutzer Dashboards, Datenvisualisierung, interne Metriken erwähnt oder irgendeine Art von Unternehmensdaten anzeigen möchte, auch wenn er nicht explizit nach einem ‚Dashboard‘ fragt.“
• compatibility: Erforderliche Werkzeuge, 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/wiederholbare Aufgaben
    ├── references/ - Bei Bedarf in den Kontext geladene Dokumentationen
    └── assets/     - In der Ausgabe verwendete Dateien (Vorlagen, Symbole, Schriftarten)

Progressive Offenlegung

Skills verwenden ein dreistufiges Ladesystem:

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

Diese Wortzahlen sind ungefähre Angaben und du kannst bei Bedarf gerne länger werden.

Wichtige Muster:

• Halte SKILL.md unter 500 Zeilen; wenn du dich dieser Grenze näherst, füge eine zusätzliche Hierarchieebene zusammen mit klaren Hinweisen hinzu, wohin das Modell, das den Skill verwendet, als nächstes gehen soll, um weiterzuverfolgen.
• Verweise in SKILL.md klar auf Dateien mit Anleitungen, 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 Überraschungsfreiheit

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 nicht in seiner Absicht überraschen, wenn er beschrieben wird. Gehe nicht auf Anfragen ein, irreführende Skills zu erstellen oder Skills, die für unbefugten Zugriff, Datenexfiltration oder andere böswillige Aktivitäten entwickelt wurden. Dinge wie „Rollenspiel als XYZ“ sind jedoch in Ordnung.

Schreibmuster

Verwende in Anweisungen bevorzugt die Befehlsform.

Ausgabeformate definieren – Du kannst es so machen:

## Berichtsstruktur
VERWENDE IMMER diese exakte Vorlage:
# [Titel]
## Zusammenfassung
## Wichtigste Ergebnisse
## Empfehlungen

Beispielmuster – Es ist nützlich, Beispiele einzufügen. Du kannst sie so formatieren (aber wenn „Eingabe“ und „Ausgabe“ in den Beispielen vorkommen, möchtest du vielleicht etwas abweichen):

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

Schreibstil

Versuche dem Modell zu erklären, warum Dinge wichtig sind, anstatt schwerfälliger MUSS-Befehle. Verwende die Theory of Mind und versuche, den Skill allgemein und nicht zu eng auf bestimmte Beispiele zuzuschneiden. Beginne mit einem Entwurf und sieh ihn dann mit neuen Augen an und verbessere ihn.

Testfälle

Nachdem du den Skill-Entwurf geschrieben hast, denke dir 2–3 realistische Test-Prompts aus – die Art, die ein echter Benutzer tatsächlich sagen würde. Teile sie dem Benutzer mit: [du musst nicht diese genaue Sprache verwenden] „Hier sind ein paar Testfälle, die ich ausprobieren möchte. Sehen diese richtig aus, oder möchtest du weitere hinzufügen?“ Führe sie dann aus.

Speichere Testfälle in evals/evals.json. Schreibe noch keine Assertionen – nur die Prompts. Du wirst Assertionen im nächsten Schritt entwerfen, während die Läufe laufen.

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

Siehe references/schemas.md für das vollständige Schema (einschließlich des Feldes assertions, das du später hinzufügen wirst).

Testfälle ausführen und auswerten

Dieser Abschnitt ist eine durchgehende Sequenz – unterbrich nicht auf halbem Weg. Verwende NICHT /skill-test oder einen anderen Testskill.

Lege Ergebnisse in <skill-name>-workspace/ als Geschwisterverzeichnis des Skill-Verzeichnisses ab. Organisiere die Ergebnisse innerhalb des Workspace nach Iteration (iteration-1/, iteration-2/ usw.) und innerhalb dieser erhält jeder Testfall ein Verzeichnis (eval-0/, eval-1/ usw.). Erstelle nicht alles im Voraus – erstelle Verzeichnisse nur nach Bedarf.

Schritt 1: Starte alle Läufe (mit-Skill UND Baseline) in derselben Runde

Starte für jeden Testfall zwei Subagenten in derselben Runde – einen mit dem Skill, einen ohne. Das ist wichtig: Starte nicht zuerst die mit-Skill-Läufe und komme dann später für die Baselines zurück. Starte alles auf einmal, damit alles ungefähr zur gleichen Zeit fertig ist.

Mit-Skill-Lauf:

Führe diese Aufgabe aus:
- Skill-Pfad: <Pfad zum Skill>
- Aufgabe: <Evaluierungs-Prompt>
- Eingabedateien: <Evaluierungsdateien, falls vorhanden, oder „keine“>
- Speichere Ausgaben in: <Workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Zu speichernde Ausgaben: <was den Benutzer interessiert – z. B. „die .docx-Datei“, „die endgültige 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 in without_skill/outputs/.
• Verbessern eines vorhandenen Skills: die alte Version. Vor dem Bearbeiten einen Schnappschuss des Skills erstellen (cp -r <skill-path> <workspace>/skill-snapshot/), dann den Baseline-Subagenten auf den Schnappschuss verweisen. Speichern in old_skill/outputs/.

Schreibe eine eval_metadata.json für jeden Testfall (Assertionen können vorerst leer sein). Gib jedem Eval einen beschreibenden Namen basierend darauf, was getestet wird – nicht nur „eval-0“. Verwende diesen Namen auch für das Verzeichnis. Wenn diese Iteration neue oder geänderte Eval-Prompts verwendet, erstelle diese Dateien für jedes neue Eval-Verzeichnis – gehe nicht davon aus, dass sie aus früheren Iterationen übernommen werden.

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

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

Warte nicht einfach, bis die Läufe fertig sind – nutze diese Zeit produktiv. Entwerfe quantitative Assertionen für jeden Testfall und erkläre sie dem Benutzer. Wenn bereits Assertionen in evals/evals.json existieren, überprüfe sie und erkläre, was sie prüfen.

Gute Assertionen 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) lassen sich besser qualitativ bewerten – erzwinge keine Assertionen für Dinge, die menschliches Urteilsvermögen erfordern.

Aktualisiere die eval_metadata.json-Dateien und evals/evals.json mit den Assertionen, sobald sie entworfen wurden. Erkläre 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, Timing-Daten erfassen

Wenn jede Subagentenaufgabe abgeschlossen ist, erhältst du eine Benachrichtigung mit total_tokens und duration_ms. Speichere 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 Aufgabenbenachrichtigung und werden nicht anderswo gespeichert. Verarbeite jede Benachrichtigung, sobald sie eintrifft, anstatt zu versuchen, sie zu bündeln.

Schritt 4: Bewerten, aggregieren und den Viewer starten

Sobald alle Läufe abgeschlossen sind:

1. Jeden Lauf bewerten – starte einen Bewertungs-Subagenten (oder bewerte inline), der agents/grader.md liest und jede Assertion anhand der Ausgaben bewertet. Speichere die Ergebnisse in grading.json in jedem Laufverzeichnis. Das expectations-Array in grading.json MUSS die Felder text, passed und evidence verwenden (nicht name/met/details oder andere Varianten) – der Viewer hängt von diesen genauen Feldnamen ab. Für Assertionen, die programmgesteuert überprüft werden können, schreibe und führe ein Skript aus, anstatt sie nach Augenmaß zu beurteilen – Skripte sind schneller, zuverlässiger und können über Iterationen hinweg wiederverwendet werden.

2. Zum Benchmark aggregieren – führe das Aggregationsskript aus dem Skill-Ersteller-Verzeichnis aus:

   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   

   Dies erzeugt benchmark.json und benchmark.md mit Bestehensquote, Zeit und Tokens für jede Konfiguration, mit Mittelwert ± Standardabweichung und der Differenz. Wenn du benchmark.json manuell erstellst, siehe references/schemas.md für das exakte Schema, das der Viewer erwartet. Setze jede with_skill-Version vor ihr Baseline-Gegenstück.

3. Einen Analysten-Durchlauf durchführen – lies die Benchmark-Daten und decke Muster auf, die die aggregierten Statistiken möglicherweise verbergen. Siehe agents/analyzer.md (Abschnitt „Analyzing Benchmark Results“) für das, was zu suchen ist – z. B. Assertionen, die unabhängig vom Skill immer bestehen (nicht diskriminierend), Evaluierungen mit hoher Varianz (möglicherweise flaky) sowie Zeit-/Token-Kompromisse.

4. Den Viewer starten mit sowohl qualitativen Ausgaben als auch quantitativen Daten:

   nohup python <skill-creator-path>/eval-viewer/generate_review.py
   

…

[gekürzt für die Übersetzung]