Skill-Ersteller

Was macht Skill-Ersteller?

Ein Skill zum Erstellen neuer Skills und deren iterative Verbesserung.

Auf hoher Ebene läuft der Prozess der Erstellung eines Skills wie folgt ab:

• Entscheiden, was der Skill tun soll und grob, wie er es tun soll
• Einen Entwurf des Skills schreiben
• Einige 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 Evals entwerfen, falls es noch keine gibt (falls es welche gibt, diese entweder so verwenden oder ändern, falls etwas geändert werden muss). Diese dann dem Benutzer erklären (oder, falls sie bereits existieren, die vorhandenen erklären)
  • Das Skript eval-viewer/generate_review.py verwenden, um dem Benutzer die Ergebnisse zur Ansicht zu zeigen, und ihm auch die quantitativen Metriken zeigen
• 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 zufriedenstellend
• Den Testsatz erweitern und erneut in größerem Maßstab 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. Wenn der Benutzer zum Beispiel sagt: "Ich möchte einen Skill für X erstellen", können Sie helfen, die Bedeutung einzugrenzen, einen Entwurf zu schreiben, die Testfälle zu schreiben, herauszufinden, wie er bewerten möchte, alle Prompts ausführen und wiederholen.

Wenn der Benutzer andererseits bereits einen Entwurf des Skills hat, können Sie direkt zum Evaluierungs-/Iterationsteil der Schleife übergehen.

Natürlich sollten Sie immer flexibel sein. Wenn der Benutzer sagt: "Ich brauche keine Reihe von Bewertungen, mach einfach mit mir mit", können Sie das auch tun.

Nachdem 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.

Cool? Cool.

Kommunikation mit dem Benutzer

Der Skill-Ersteller wird wahrscheinlich von Personen mit einem breiten Spektrum an Vertrautheit mit Programmierjargon verwendet. Falls Sie es noch nicht gehört haben (und wie könnten Sie, es ist erst vor kurzem in Mode gekommen), gibt es einen Trend, bei dem die Leistung von Claude Klempner dazu inspiriert, ihre Terminals zu öffnen, und Eltern und Großeltern dazu, zu googeln "wie installiere ich npm". 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 Ihnen eine Vorstellung zu geben:

• "Evaluierung" und "Benchmark" sind grenzwertig, aber in Ordnung
• Bei "JSON" und "Behauptung" sollten Sie ernsthafte Hinweise vom Benutzer sehen, dass er weiß, was diese Dinge sind, bevor Sie sie 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 nicht sicher 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"). Wenn ja, extrahieren Sie zuerst Antworten aus dem Gesprächsverlauf – die verwendeten Werkzeuge, die Reihenfolge der Schritte, Korrekturen des Benutzers, beobachtete Eingabe-/Ausgabeformate. Der Benutzer muss möglicherweise Lücken füllen und sollte vor dem nächsten Schritt bestätigen.

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, festgelegte Workflow-Schritte) profitieren von Testfällen. Skills mit subjektiven Ausgaben (Schreibstil, Kunst) benötigen oft keine. Schlagen Sie den angemessenen Standard basierend auf dem Skill-Typ vor, aber lassen Sie den Benutzer entscheiden.

Interview und Recherche

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

Überprüfen Sie verfügbare MCPs – wenn sie für die Recherche nützlich sind (Dokumentation durchsuchen, ähnliche Skills finden, Best Practices nachschlagen), recherchieren Sie parallel über Sub-Agenten, falls vorhanden, ansonsten inline. Kommen Sie mit Kontext vorbereitet, um die Belastung des Benutzers zu reduzieren.

Die SKILL.md schreiben

Basierend auf dem Benutzerinterview füllen Sie diese Komponenten aus:

• name: Skill-Identifikator
• description: Wann auslösen, was tut es. Dies ist der primäre Auslösemechanismus – geben Sie sowohl an, was der Skill tut, ALS AUCH spezifische Kontexte, wann er verwendet werden soll. Alle "wann verwenden"-Informationen kommen hier, nicht im Hauptteil. Hinweis: Derzeit neigt Claude dazu, Skills zu "unterauszulösen" – sie nicht zu verwenden, wenn sie nützlich wären. Um dem entgegenzuwirken, machen Sie die Skill-Beschreibungen bitte ein wenig "aufdringlich". Anstatt "So bauen Sie ein einfaches, schnelles Dashboard zur Anzeige interner Anthropic-Daten." könnten Sie schreiben: "So bauen Sie ein einfaches, schnelles Dashboard zur Anzeige interner Anthropic-Daten. Stellen Sie sicher, dass Sie diesen Skill immer dann verwenden, wenn der Benutzer Dashboards, Datenvisualisierung, interne Metriken erwähnt oder irgendwelche 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/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:

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

Diese Wortzahlen sind ungefähr und Sie können bei Bedarf gerne länger werden.

Wichtige Muster:

• Halten Sie SKILL.md unter 500 Zeilen; wenn Sie sich dieser Grenze nähern, fügen Sie eine zusätzliche Hierarchieebene mit klaren Hinweisen hinzu, wohin das Modell, das den Skill verwendet, als nächstes gehen soll.
• Verweisen Sie klar auf Dateien in der SKILL.md mit Anleitungen, wann sie gelesen werden sollen
• Für große 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. Die Inhalte eines Skills sollten den Benutzer nicht in ihrer Absicht überraschen, wenn sie beschrieben werden. Gehen Sie nicht auf Anfragen ein, irreführende Skills zu erstellen oder Skills, die für unbefugten Zugriff, Datenextraktion oder andere böswillige Aktivitäten entwickelt wurden. Dinge wie "Rollenspiel als XYZ" sind jedoch in Ordnung.

Schreibmuster

Verwenden Sie in Anweisungen bevorzugt den Imperativ.

Ausgabeformate definieren – Sie können es so machen:

## Berichtsstruktur
VERWENDEN SIE IMMER diese exakte Vorlage:
# [Titel]
## Zusammenfassung für die Geschäftsführung
## Wichtigste Erkenntnisse
## Empfehlungen

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

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

Schreibstil

Versuchen Sie, dem Modell zu erklären, warum Dinge wichtig sind, anstatt schwerfällige, veraltete MÜSSEN zu verwenden. 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

Nachdem Sie den Skill-Entwurf geschrieben haben, überlegen Sie sich 2-3 realistische Test-Prompts – die Art, 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 diese richtig aus, oder möchten Sie weitere hinzufügen?" Führen Sie sie dann aus.

Speichern Sie Testfälle in evals/evals.json. Schreiben Sie noch keine Behauptungen – nur die Prompts. Sie werden Behauptungen 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 assertions-Feldes, das Sie später hinzufügen werden).

Ausführen und Bewerten von Testfällen

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

Legen Sie Ergebnisse in <skill-name>-workspace/ als Geschwisterverzeichnis zum Skill-Verzeichnis ab. Innerhalb des Workspace organisieren Sie Ergebnisse nach Iteration (iteration-1/, iteration-2/ usw.) und innerhalb dieser erhält jeder Testfall ein Verzeichnis (eval-0/, eval-1/ usw.). Erstellen Sie nicht alles im Voraus – erstellen Sie einfach Verzeichnisse, während Sie fortschreiten.

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

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

Mit-Skill-Lauf:

Führe diese Aufgabe aus:
- Skill-Pfad: <pfad-zum-skill>
- Aufgabe: <eval-prompt>
- Eingabedateien: <eval-dateien, falls vorhanden, oder "keine">
- Speichere Ausgaben in: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Zu speichernde Ausgaben: <was für den Benutzer wichtig ist – 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: gar kein Skill. Gleicher Prompt, kein Skill-Pfad, speichere in without_skill/outputs/.
• Verbessern eines bestehenden Skills: die alte Version. Vor dem Bearbeiten einen Schnappschuss des Skills erstellen (cp -r <skill-pfad> <workspace>/skill-snapshot/), dann den Baseline-Sub-Agenten auf den Schnappschuss verweisen. Speichere in old_skill/outputs/.

Schreiben Sie eine eval_metadata.json für jeden Testfall (Behauptungen können vorerst leer sein). Geben Sie jedem Eval einen beschreibenden Namen basierend auf dem, was getestet wird – nicht nur "eval-0". Verwenden Sie diesen Namen auch für das Verzeichnis. Wenn diese Iteration neue oder geänderte Eval-Prompts verwendet, erstellen Sie diese Dateien für jedes neue Eval-Verzeichnis – gehen Sie nicht davon aus, dass sie von 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, Behauptungen entwerfen

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

Gute Behauptungen 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 prüft. Subjektive Skills (Schreibstil, Designqualität) werden besser qualitativ bewertet – erzwingen Sie keine Behauptungen für Dinge, die menschliches Urteilsvermögen erfordern.

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

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

Wenn jede Sub-Agenten-Aufgabe 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 Aufgabenbenachrichtigung und werden nicht anderswo gespeichert. Verarbeiten Sie jede Benachrichtigung, sobald sie eintrifft, anstatt zu versuchen, sie zu sammeln.

Schritt 4: Bewerten, aggregieren und den Viewer starten

Sobald alle Läufe abgeschlossen sind:

1. Jeden Lauf bewerten – Starten Sie einen Bewertungs-Sub-Agenten (oder bewerten Sie inline), der agents/grader.md liest und jede Behauptung gegen die Ausgaben bewertet. Speichern Sie Ergebnisse in grading.json in jedem Laufverzeichnis. Das grading.json-Erwartungen-Array 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 Behauptungen, die programmatisch überprüft werden können, schreiben und führen Sie ein Skript aus, anstatt sie nach Augenmaß zu beurteilen – Skripte sind schneller, zuverlässiger und können über Iterationen hinweg wiederverwendet werden.

2. Zur Benchmark aggregieren – Führen Sie 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 Pass-Rate, Zeit und Tokens für jede Konfiguration, mit Mittelwert ± Stdabw. und dem Delta. Wenn Sie benchmark.json manuell generieren, siehe references/schemas.md für das genaue Schema, das der Viewer erwartet. Setzen Sie jede mit-Skill-Version vor ihr Baseline-Gegenstück.

3. Eine Analyse durchführen – Lesen Sie die Benchmark-Daten und decken Sie Muster auf, die die aggregierten Statistiken verbergen könnten. Siehe agents/analyzer.md (der Abschnitt "Analyzing Benchmark Results") für das, wonach Sie suchen sollten – Dinge wie Behauptungen, die unabhängig vom Skill immer bestanden werden (nicht diskriminierend), Evals mit hoher Varianz (möglicherweise fehlerhaft) und Zeit-/Token-Kompromisse.

4. Starten Sie den Viewer mit sowohl qualitativen Ausgaben als auch quantitativen Daten:

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