Modifiziert für DeepSeek Harness. Upstream: Anthropic's skill-creator (Apache-2.0, siehe LICENSE.txt).

Skill Creator

Eine Fähigkeit zum Erstellen neuer Fähigkeiten und zur iterativen Verbesserung.

Auf hoher Ebene läuft der Prozess der Erstellung einer Fähigkeit wie folgt ab:

Entscheide, was die Fähigkeit tun soll und grob, wie sie es tun soll
Schreibe einen Entwurf der Fähigkeit
Erstelle ein paar Test-Prompts und führe das Modell mit installierter Fähigkeit aus
Hilf dem Benutzer, die Ergebnisse sowohl qualitativ als auch quantitativ zu bewerten
- Während die Läufe im Hintergrund stattfinden, skizziere einige quantitative Evals, falls keine vorhanden sind (falls es welche gibt, kannst du sie entweder unverändert verwenden oder modifizieren, falls du der Meinung bist, dass etwas geändert werden muss). Erkläre sie dann dem Benutzer (oder falls sie bereits existieren, erkläre die vorhandenen)
- Verwende das Skript eval-viewer/generate_review.py, um dem Benutzer die Ergebnisse anzuzeigen, und lass ihn auch die quantitativen Metriken einsehen
Schreibe die Fähigkeit basierend auf dem Feedback des Benutzers zur Bewertung der Ergebnisse um (und auch, wenn offensichtliche Mängel aus den quantitativen Benchmarks hervorgehen)
Wiederhole, bis du zufrieden bist
Erweitere den Testsatz und versuche es erneut in größerem Maßstab

Deine Aufgabe bei der Verwendung dieser Fähigkeit ist es, herauszufinden, wo sich der Benutzer in diesem Prozess befindet, und dann einzusteigen und ihm zu helfen, diese Phasen zu durchlaufen. Vielleicht sagt er: "Ich möchte eine Fähigkeit für X erstellen". Du kannst helfen einzugrenzen, was er meint, einen Entwurf schreiben, die Testfälle schreiben, herausfinden, wie er bewerten möchte, alle Prompts ausführen und wiederholen.

Andererseits hat der Benutzer vielleicht bereits einen Entwurf der Fähigkeit. In diesem Fall kannst du direkt zum Evaluierungs-/Iterationsteil der Schleife übergehen.

Natürlich solltest du immer flexibel sein. Wenn der Benutzer sagt: "Ich muss keine Reihe von Evaluierungen durchführen, mach einfach mit mir mit", kannst du das auch tun.

Nachdem die Fähigkeit fertig ist (aber auch hier ist die Reihenfolge flexibel), kannst du auch den Verbesserer der Fähigkeitsbeschreibung ausführen, für den wir ein separates Skript haben, um die Auslösung der Fähigkeit zu optimieren.

Cool? Cool.

Kommunikation mit dem Benutzer

Der Skill Creator kann von Personen mit sehr unterschiedlichen Kenntnissen im Programmieren verwendet werden. Falls du es noch nicht gehört hast (und wie könntest du, es ist erst vor kurzem losgegangen), gibt es jetzt einen Trend, bei dem die Macht von DSH Klempner dazu inspiriert, ihre Terminals zu öffnen, und Eltern und Großeltern googeln "Wie installiere ich npm". Auf der anderen Seite sind die meisten Benutzer wahrscheinlich recht computeraffin.

Achte also bitte auf Kontexthinweise, um zu verstehen, wie deine Kommunikation formuliert sein sollte! Im Standardfall, nur um dir eine Vorstellung zu geben:

"Evaluierung" und "Benchmark" sind grenzwertig, aber in Ordnung
Für "JSON" und "Behauptung" solltest du ernsthafte Hinweise des Benutzers 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 unsicher bist, und zögere nicht, Begriffe mit einer kurzen Definition zu klären, wenn du dir nicht sicher bist, ob der Benutzer sie versteht.

Erstellen einer Fähigkeit

Absicht erfassen

Beginne damit, die Absicht des Benutzers zu verstehen. Das aktuelle Gespräch könnte bereits einen Arbeitsablauf enthalten, den der Benutzer erfassen möchte (z. B. wenn er sagt: "Mach das zu einer Fähigkeit"). Wenn ja, extrahiere die Antworten zunächst aus dem Gesprächsverlauf – die verwendeten Werkzeuge, die Reihenfolge der Schritte, Korrekturen des Benutzers, beobachtete Eingabe-/Ausgabeformate. Der Benutzer muss möglicherweise die Lücken füllen und sollte vor dem nächsten Schritt bestätigen.

Was soll diese Fähigkeit DSH ermöglichen?
Wann sollte diese Fähigkeit auslösen? (welche Benutzerphrasen/Kontexte)
Was ist das erwartete Ausgabeformat?
Sollten wir Testfälle einrichten, um zu überprüfen, ob die Fähigkeit funktioniert? Fähigkeiten mit objektiv überprüfbaren Ausgaben (Datei-Transformationen, Datenextraktion, Codegenerierung, festgelegte Arbeitsschritte) profitieren von Testfällen. Fähigkeiten mit subjektiven Ausgaben (Schreibstil, Kunst) benötigen sie oft nicht. Schlagen Sie den geeigneten Standard basierend auf dem Fähigkeitstyp vor, aber lassen Sie den Benutzer entscheiden.

Interview und Recherche

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

Überprüfe verfügbare MCPs – wenn sie für die Recherche nützlich sind (Dokumente durchsuchen, ähnliche Fähigkeiten finden, Best Practices nachschlagen), recherchiere parallel über Subagenten, falls verfügbar, andernfalls inline. Komme mit Kontext, um die Belastung des Benutzers zu verringern.

Die SKILL.md schreiben

Fülle basierend auf dem Benutzerinterview diese Komponenten aus:

name: Identifikator der Fähigkeit
description: Wann auslösen, was sie tut. Dies ist der primäre Auslösemechanismus – gib sowohl an, was die Fähigkeit tut, ALS AUCH spezifische Kontexte für die Verwendung. Alle "Wann-verwenden"-Informationen gehören hierher, nicht in den Hauptteil. Hinweis: Das Modell neigt derzeit dazu, Fähigkeiten "zu wenig auszulösen" – sie nicht zu verwenden, wenn sie nützlich wären. Um dem entgegenzuwirken, gestalte die Fähigkeitsbeschreibungen bitte ein wenig "aufdringlich". Anstatt "Wie man ein einfaches schnelles Dashboard zur Anzeige interner Unternehmensdaten erstellt", schreibe vielleicht "Wie man ein einfaches schnelles Dashboard zur Anzeige interner Unternehmensdaten erstellt. Verwende diese Fähigkeit unbedingt, wenn der Benutzer Dashboards, Datenvisualisierung, interne Metriken erwähnt oder irgendeine Art von Unternehmensdaten anzeigen möchte, selbst wenn er nicht explizit nach einem 'Dashboard' fragt."
whenToUse / metadata / disable-model-invocation / user-invocable: die optionalen Frontmatter-Schlüssel, die DSH erkennt. DSH liest name, description, whenToUse, metadata, disable-model-invocation und user-invocable aus dem Frontmatter; setze alles andere, was du aufzeichnen möchtest (eine Lizenz, eine Version), unter metadata und nicht als Schlüssel der obersten Ebene.
den Rest der Fähigkeit :)

Leitfaden zum Schreiben von Fähigkeiten

Anatomie einer Fähigkeit

skill-name/
├── SKILL.md (erforderlich)
│   ├── YAML-Frontmatter (name, description erforderlich)
│   └── Markdown-Anweisungen
└── Gebündelte Ressourcen (optional)
    ├── scripts/    - Ausführbarer Code für deterministische/sich wiederholende 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, wann immer die Fähigkeit auslöst (<500 Zeilen ideal)
Gebündelte Ressourcen – Nach Bedarf (unbegrenzt, Skripte können ohne Laden ausgeführt werden)

Diese Wortzahlen sind ungefähr und du kannst gerne länger gehen, falls nötig.

Wichtige Muster:

Halte SKILL.md unter 500 Zeilen; wenn du dich dieser Grenze näherst, füge eine zusätzliche Hierarchieebene mit klaren Hinweisen hinzu, wohin das Modell, das die Fähigkeit verwendet, als nächstes gehen soll, um nachzufassen.
Verweise in SKILL.md klar auf Dateien mit Hinweisen, wann sie gelesen werden sollen
Füge bei großen Referenzdateien (>300 Zeilen) ein Inhaltsverzeichnis hinzu

Domänenorganisation: Wenn eine Fähigkeit mehrere Domänen/Frameworks unterstützt, organisiere nach Variante:

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

DSH liest nur die relevante Referenzdatei.

Prinzip der Nicht-Überraschung

Dies versteht sich von selbst, aber Fähigkeiten dürfen keine Malware, Exploit-Code oder Inhalte enthalten, die die Systemsicherheit gefährden könnten. Der Inhalt einer Fähigkeit sollte den Benutzer in seiner Absicht nicht überraschen, wenn sie beschrieben wird. Folge keinen Anfragen, irreführende Fähigkeiten oder Fähigkeiten zu erstellen, die für unbefugten Zugriff, Datendiebstahl 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 Erkenntnisse
## Empfehlungen

Beispiel-Muster – 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, anstelle von schwerfälligen „MUSS”-Anforderungen. Verwende die Theory of Mind und versuche, die Fähigkeit allgemein und nicht zu sehr auf bestimmte Beispiele zugeschnitten zu machen. Beginne damit, einen Entwurf zu schreiben, und betrachte ihn dann mit frischen Augen und verbessere ihn.

Testfälle

Nach dem Schreiben des Fähigkeitsentwurfs entwickle 2-3 realistische Test-Prompts – die Art von Dingen, die ein echter Benutzer tatsächlich sagen würde. Teile sie mit dem Benutzer: [du musst nicht genau diese 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 Behauptungen – nur die Prompts. Du wirst Behauptungen im nächsten Schritt skizzieren, 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": []
    }
  ]
}

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

Ausführen und Bewerten von Testfällen

Dieser Abschnitt ist eine durchgehende Sequenz – unterbrich nicht mittendrin. Verwende NICHT /skill-test oder eine andere Testfähigkeit.

Lege Ergebnisse in <skill-name>-workspace/ als Geschwisterverzeichnis des Fähigkeitsverzeichnisses ab. Organisiere innerhalb des Arbeitsbereichs die Ergebnisse nach Iteration (iteration-1/, iteration-2/, usw.) und darin erhält jeder Testfall ein Verzeichnis (eval-0/, eval-1/, usw.). Erstelle nicht alles im Voraus – erstelle Verzeichnisse, während du vorgehst.

Schritt 1: Alle Läufe starten (mit-Fähigkeit UND Baseline) im selben Durchlauf

Starte für jeden Testfall zwei Subagenten im selben Durchlauf – einen mit der Fähigkeit, einen ohne. Dies ist wichtig: Starte nicht zuerst die Läufe mit Fähigkeit und komme später für die Baselines zurück. Starte alles gleichzeitig, damit alles ungefähr zur gleichen Zeit fertig wird.

Lauf mit Fähigkeit:

Führe diese Aufgabe aus:
- Fähigkeitspfad: <Pfad-zur-Fähigkeit>
- Aufgabe: <Eval-Prompt>
- Eingabedateien: <Eval-Dateien falls vorhanden, oder "keine">
- Speichere Ausgaben in: <Arbeitsbereich>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Zu speichernde Ausgaben: <woran dem Benutzer liegt – z.B. "die .docx-Datei", "die endgültige CSV">

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

Erstellen einer neuen Fähigkeit: gar keine Fähigkeit. Gleicher Prompt, kein Fähigkeitspfad, speichere in without_skill/outputs/.
Verbessern einer vorhandenen Fähigkeit: die alte Version. Erstelle vor der Bearbeitung eine Momentaufnahme der Fähigkeit durch Kopieren des Verzeichnisses mit shutil.copytree (z.B. <Arbeitsbereich>/skill-snapshot/ von <Fähigkeitspfad>), und weise dann den Baseline-Subagenten auf die Momentaufnahme hin. Speichere in old_skill/outputs/.

Schreibe eine eval_metadata.json für jeden Testfall (Behauptungen können vorerst leer sein). Gib jedem Eval einen beschreibenden Namen basierend auf dem, was getestet wird – nicht nur "eval-0". Verwende diesen Namen auch für das Verzeichnis. Wenn diese Iteration neue oder modifizierte Eval-Prompts verwendet, erstelle diese Dateien für jedes neue Eval-Verzeichnis – nimm nicht an, 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, Behauptungen skizzieren

Warte nicht einfach, bis die Läufe fertig sind – du kannst diese Zeit produktiv nutzen. Skizziere quantitative Behauptungen für jeden Testfall und erkläre sie dem Benutzer. Wenn Behauptungen bereits in evals/evals.json existieren, überprüfe sie und erkläre, was sie überprü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 überprüft. Subjektive Fähigkeiten (Schreibstil, Designqualität) werden besser qualitativ bewertet – erzwinge keine Behauptungen für Dinge, die menschliches Urteilsvermögen erfordern.

Aktualisiere die eval_metadata.json-Dateien und evals/evals.json mit den Behauptungen, sobald sie skizziert sind. 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, Zeitmessungsdaten erfassen

Wenn jede Subagentenaufgabe abgeschlossen ist, erhältst du eine Benachrichtigung, die jedoch weder Token-Zahlen noch verstrichene Zeit enthält. Nimm die Dauer selbst von der Wanduhr und lies die Token-Summen aus dem Datensatz der Kindersitzung unter ~/.dsh/storages/session_projcache/sessions/<childId>.json (tokenUsage.val.totals – uncachedInputTokens, outputTokens, cacheReadTokens, cacheWriteTokens). Speichere diese Daten sofort in timing.json im Ausführungsverzeichnis:

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

Falls dieser Sitzungsdatensatz fehlt oder keine Token-Nutzung aufweist, lasse die Token-Felder weg, anstatt Zahlen zu erfinden. Verarbeite 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 – starte einen Bewertungs-Subagenten (oder bewerte inline), der agents/grader.md liest und jede Behauptung anhand der Ausgaben bewertet. Speichere Ergebnisse in grading.json in jedem Ausführungsverzeichnis. 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 exakten Feldnamen angewiesen. Für Behauptungen, die programmatisch überprüft werden können, schreibe und führe ein Skript aus, anstatt sie manuell zu überprüfen – Skripte sind schneller, zuverlässiger und können über Iterationen hinweg wiederverwendet werden.
In Benchmark aggregieren – führe das Aggregationsskript aus dem dsh-skill-creator-Verzeichnis aus:
```
python -m scripts.aggregate_benchmark <Arbeitsbereich>/iteration-N --skill-name <Name>
```
Dies erzeugt benchmark.json und benchmark.md mit Bestehensquote, Zeit und Tokens für …

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

Anuii/skills

Was ist skills?

In Ihrer bevorzugten KI fragen

Dokumentation