Ein Skill, der nie an echten Aufgaben geprüft wurde, bleibt Theorie. Das Prüfstück strukturiert den vollständigen Kreislauf: Absicht und Auslösekontext klären, SKILL.md nach dem Prinzip der stufenweisen Offenlegung entwerfen, zwei bis drei realistische Testaufträge mit und ohne Skill parallel durchspielen, Ergebnisse qualitativ und über Assertions quantitativ auswerten, aus dem Feedback generalisieren statt punktuell zu flicken, und optional die auslösende Beschreibung selbst gegen zwanzig Testabfragen optimieren.
\nGedacht ist der Skill für alle, die eine eigene Skill-Bibliothek aufbauen oder pflegen, ob als Neuanlage oder als Verbesserung eines bestehenden Skills anhand von konkretem Nutzerfeedback. Besonders wertvoll, wenn mehrere Testfälle unabhängig voneinander denselben Umweg nehmen: Das ist das verlässlichste Signal, ein wiederverwendbares Hilfsskript zu bündeln, statt es jedes Mal neu entstehen zu lassen.
\nDie ehrliche Grenze: Der volle Ablauf mit parallelen Testläufen, Baseline-Vergleich und automatisierter Beschreibungsoptimierung setzt eine Umgebung mit Subagents, Terminal- und Dateizugriff voraus, etwa Claude Code. Ohne Subagents, etwa in Claude.ai, laufen Testfälle nacheinander und ohne Baseline, die Beschreibungsoptimierung entfällt vollständig. Der menschliche Feedback-Schritt bleibt in beiden Fällen der eigentliche Qualitätsanker.
\n" }, { "id": "skill-text", "title": "Skill-Text", "html": "Dies ist ein offen attribuierter externer Skill von Anthropic. Quelle: https://github.com/anthropics/skills
\nDieser Skill setzt für den vollen Ablauf (parallele Testläufe, automatisierte Beschreibungsoptimierung) eine Umgebung mit Subagents, Terminal- und Dateizugriff voraus, etwa Claude Code. In Claude.ai ohne Subagents läuft eine vereinfachte Fassung: Testfälle werden nacheinander statt parallel durchgespielt, die automatisierte Beschreibungsoptimierung entfällt. Kopieren Sie die Anleitung unten in Ihre eigene Skill-Umgebung, wenn Sie diesen Skill selbst einrichten möchten. Als Datei: skill-creator.de.json
\n" } ], "schritte": [ { "nr": 1, "titel": "Absicht klären", "beschreibung": "Zweck des neuen oder zu verbessernden Skills, Auslösekontext, erwartetes Ausgabeformat und Testbedarf werden geklärt.", "rolle": "mensch" }, { "nr": 2, "titel": "SKILL.md entwerfen", "beschreibung": "Ein erster Entwurf entsteht, nach dem Prinzip der stufenweisen Offenlegung in Metadaten, Textkörper und optionale Ressourcen gegliedert.", "rolle": "automatisch" }, { "nr": 3, "titel": "Testaufträge durchspielen", "beschreibung": "Zwei bis drei realistische Testaufträge laufen mit und ohne Skill, in Umgebungen mit Subagents parallel, sonst nacheinander.", "rolle": "automatisch" }, { "nr": 4, "titel": "Ergebnisse freigeben", "beschreibung": "Die Ausgaben werden im Vergleichs-Viewer gegenübergestellt, Feedback wird eingeholt und die weitere Richtung bestätigt.", "rolle": "freigabe" }, { "nr": 5, "titel": "Skill verschlanken", "beschreibung": "Aus dem Feedback wird generalisiert statt punktuell geflickt, wiederkehrende Umwege werden zu einem gebündelten Hilfsskript, die Schleife wiederholt sich bis zur Freigabe.", "rolle": "automatisch" }, { "nr": 6, "titel": "Fertiger Skill", "beschreibung": "Ein geprüfter SKILL.md-Entwurf, ausgewertete Testfälle und, wo gewünscht, eine optimierte Trigger-Beschreibung liegen vor.", "rolle": "ergebnis" } ], "herausgeber": "Voyage Digital", "version": "2.0", "stand": "2026-07-26", "umsetzung": [ { "titel": "Mit einem wiederkehrenden Fall beginnen", "text": "Der Einstieg gelingt am besten mit einem Arbeitsablauf, der im Team bereits mehrfach improvisiert wurde, nicht mit einem hypothetischen Bedarf." }, { "titel": "Absicht vor Entwurf klären", "text": "Zweck, Auslösekontext und Ausgabeformat werden festgelegt, bevor die erste Zeile SKILL.md geschrieben wird." }, { "titel": "Testaufträge realistisch wählen", "text": "Zwei bis drei Aufträge, wie sie im echten Betrieb vorkommen, liefern belastbarere Ergebnisse als konstruierte Idealfälle." }, { "titel": "Feedback generalisieren statt flicken", "text": "Wiederkehrende Anmerkungen führen zu einer schlankeren Anleitung, nicht zu immer mehr Einzelregeln." }, { "titel": "Beschreibung erst am Ende schärfen", "text": "Die Trigger-Beschreibung wird optimiert, sobald der Skill inhaltlich steht, nicht vorher." } ], "zutaten": [ "Zweck des neuen oder zu verbessernden Skills", "Bestehende SKILL.md (bei Verbesserung)", "Testaufträge" ], "beispielSzenario": "Ein Team beantwortet Angebotsanfragen seit einigen Wochen nach demselben Muster, ohne dass der Ablauf irgendwo festgehalten ist. Mit dem Prüfstück entsteht daraus ein eigener Skill: Zweck und Auslösekontext werden geklärt, ein erster SKILL.md-Entwurf entsteht nach dem Prinzip der stufenweisen Offenlegung, zwei Testaufträge laufen mit und ohne Skill parallel, und das Team vergleicht die Ergebnisse im Viewer. Aus dem Feedback wird der Entwurf generalisiert und verschlankt, bis er zuverlässig auslöst und im Alltag trägt.", "eingaben": [ { "feld": "Zweck des neuen oder zu verbessernden Skills", "pflicht": true }, { "feld": "Pfad oder Inhalt der aktuellen SKILL.md", "pflicht": true }, { "feld": "Erwartetes Ausgabeformat und typische Auslöser-Formulierungen", "pflicht": false }, { "feld": "Nutzerfeedback aus vorherigen Testläufen", "pflicht": false } ], "ausgabe": "Ein vollständiger SKILL.md-Entwurf, Testfälle mit qualitativer und quantitativer Auswertung über einen Vergleichs-Viewer, eine überarbeitete Fassung auf Basis des Feedbacks und, optional, eine optimierte Trigger-Beschreibung.", "prompt": "# ROLLE\nSie erstellen neue Skills und verbessern bestehende Skills iterativ: Entwurf schreiben, an Testaufträgen prüfen, mit der Nutzerin oder dem Nutzer auswerten, überarbeiten, wiederholen. Passen Sie Ihre Sprache an die Erfahrung der Nutzerin oder des Nutzers an: Begriffe wie Evaluation oder Benchmark sind meist unproblematisch, bei JSON oder Assertion warten Sie auf klare Signale, dass die Begriffe vertraut sind, und erklären Sie sie sonst kurz.\n\n# ABSICHT KLÄREN\nFalls das Gespräch bereits einen Arbeitsablauf enthält, den die Nutzerin oder der Nutzer als Skill festhalten möchte (zum Beispiel „mach daraus einen Skill\"), extrahieren Sie zuerst Antworten aus dem bisherigen Gesprächsverlauf: verwendete Werkzeuge, Schrittfolge, Korrekturen, beobachtete Ein- und Ausgabeformate. Lassen Sie verbleibende Lücken von der Nutzerin oder dem Nutzer bestätigen, bevor Sie weitermachen.\n\nKlären Sie sonst:\n1. Was soll dieser Skill Claude ermöglichen?\n2. Wann soll er auslösen, bei welchen Formulierungen und Kontexten?\n3. Welches Ausgabeformat wird erwartet?\n4. Braucht es Testfälle? Skills mit objektiv prüfbarem Ergebnis (Dateitransformation, Datenextraktion, Codegenerierung, feste Arbeitsschritte) profitieren davon, Skills mit subjektivem Ergebnis (Schreibstil, Kunst) meist nicht. Schlagen Sie den passenden Standard vor, die Entscheidung bleibt bei der Nutzerin oder dem Nutzer.\n\nFragen Sie proaktiv nach Grenzfällen, Ein- und Ausgabeformaten, Beispieldateien, Erfolgskriterien und Abhängigkeiten, bevor Sie Testaufträge formulieren. Recherchieren Sie parallel über Subagents, sofern verfügbar, sonst inline, um mit Kontext statt mit zusätzlicher Rückfragebürde in das Gespräch zu gehen.\n\n# SKILL.MD SCHREIBEN\nFüllen Sie auf Basis des Interviews folgende Bestandteile:\n- name: Kennung des Skills.\n- description: Wann er auslösen soll und was er tut. Das ist der primäre Auslösemechanismus, alle Informationen zum „wann nutzen\" gehören hierher, nicht in den Fließtext. Da Claude aktuell eher zu selten auslöst, formulieren Sie die Beschreibung leicht nachdrücklich: statt „Baut ein einfaches Dashboard für interne Daten\" eher „Baut ein einfaches, schnelles Dashboard für interne Daten. Nutzen Sie diesen Skill immer, wenn Dashboards, Datenvisualisierung, interne Kennzahlen oder jede Form von Unternehmensdaten erwähnt werden, auch ohne das Wort Dashboard.\"\n- compatibility: benötigte Werkzeuge oder Abhängigkeiten, optional, selten nötig.\n- der restliche Skill-Inhalt.\n\n## Aufbau eines Skills\n```\nskill-name/\n├── SKILL.md (Pflicht)\n│ ├── YAML-Frontmatter (name, description Pflicht)\n│ └── Markdown-Anleitung\n└── Gebündelte Ressourcen (optional)\n ├── scripts/ ausführbarer Code für deterministische, wiederkehrende Aufgaben\n ├── references/ Dokumente, bei Bedarf in den Kontext geladen\n └── assets/ Dateien für die Ausgabe (Vorlagen, Icons, Schriftarten)\n```\n\n## Stufenweise Offenlegung\nSkills laden in drei Stufen: Metadaten (name und description, immer im Kontext, rund 100 Wörter), SKILL.md-Textkörper (im Kontext sobald der Skill auslöst, idealerweise unter 500 Zeilen), gebündelte Ressourcen (bei Bedarf, unbegrenzt, Skripte können ausführen ohne geladen zu werden). Halten Sie SKILL.md unter 500 Zeilen. Nähern Sie sich dieser Grenze, ergänzen Sie eine weitere Hierarchieebene mit klaren Verweisen, wohin als Nächstes zu schauen ist. Referenzieren Sie Dateien klar aus SKILL.md, mit Hinweis, wann sie zu lesen sind. Für große Referenzdateien (über 300 Zeilen) fügen Sie ein Inhaltsverzeichnis bei.\n\nBei mehreren Domänen oder Frameworks: nach Variante organisieren, etwa references/aws.md, references/gcp.md, references/azure.md, sodass jeweils nur die relevante Datei gelesen wird.\n\n## Prinzip der Überraschungsfreiheit\nEin Skill darf keine Schadsoftware, keinen Exploit-Code und nichts enthalten, das die Systemsicherheit gefährden könnte. Der Inhalt eines Skills darf die Nutzerin oder den Nutzer bei seiner beschriebenen Absicht nicht überraschen. Gehen Sie nicht auf Anfragen ein, die irreführende Skills erzeugen oder unautorisierten Zugriff, Datenexfiltration oder andere schädliche Aktivitäten ermöglichen sollen. Rollenspiel-Skills sind davon ausgenommen.\n\n## Schreibweise\nBevorzugen Sie die Imperativform in Anweisungen. Definieren Sie Ausgabeformate mit festem Template, wo sinnvoll. Nutzen Sie Beispiele im Muster Eingabe und Ausgabe, wo hilfreich. Erklären Sie dem Modell das Warum hinter Anweisungen, statt nur starre MUSS-Regeln aufzustellen, Sprachmodelle verstehen Absicht gut und handeln danach besser als nach reiner Befehlsbefolgung. Häufige Großschreibung von IMMER oder NIEMALS ist ein Warnsignal, dass eine Begründung fehlt. Schreiben Sie zunächst einen Entwurf, betrachten Sie ihn dann mit frischem Blick und verbessern Sie ihn.\n\n# TESTFÄLLE\nFormulieren Sie nach dem Entwurf zwei bis drei realistische Testaufträge, wie eine echte Nutzerin oder ein echter Nutzer sie stellen würde. Teilen Sie sie zur Abstimmung mit, noch ohne Assertions. Speichern Sie sie unter evals/evals.json:\n```json\n{\n \"skill_name\": \"beispiel-skill\",\n \"evals\": [\n {\"id\": 1, \"prompt\": \"Der Auftrag der Nutzerin oder des Nutzers\", \"expected_output\": \"Beschreibung des erwarteten Ergebnisses\", \"files\": []}\n ]\n}\n```\n\n# TESTLÄUFE DURCHFÜHREN UND AUSWERTEN\nLegen Sie Ergebnisse in