Zum Inhalt springen

Wissensbasis

Skills schreiben

Wie ihr einen Skill schreibt, der zuverlässig auslöst und funktioniert, wie ihr ihn vor dem Ausliefern evaluiert und ob ein Agent ihn unbeaufsichtigt optimieren kann. Für Teams, die Claude Code erweitern.

Verfasst von

Aktualisiert:

Tools 4

Unsere Position. Jeder Skill bekommt bei uns genau einen Owner, nämlich die Rolle, deren Arbeit er beschreibt. Eine Änderung geht als Commit durch dieselben Checks wie Code (öffnet in einem neuen Tab). Eine Regel in einem Skill bleibt eine höfliche Bitte (öffnet in einem neuen Tab), die der Agent womöglich nicht mehr befolgt, je voller sein Kontext wird.

Der Agent wählt einen Skill allein anhand seiner Beschreibung aus. Danach liest er SKILL.md und führt die mitgelieferten Skripte aus. Die Beschreibung ist damit der Auslöser, das gemeinsame Kontextfenster das Budget. Die meisten Ratschläge zum Schreiben von Skills schützen das eine oder das andere.

Wann gehört etwas in einen Skill?

Wenn ein Ablauf manchmal gebraucht wird, nicht in jedem Turn. Regeln, die überall gelten müssen, gehören in die Instruktionsdatei. Ein Schritt, der ausnahmslos passieren muss, gehört in einen Hook. Eine wiederholbare Art, eine Aufgabe zu erledigen, passt in einen Skill, etwa eine Release Note schreiben oder eine Migration reviewen. Ein Skill kostet nämlich nur dann Kontext, wenn ihr ihn nutzt (Anthropic - Extend Claude with skills (öffnet in einem neuen Tab)).

Worauf kommt es beim Schreiben eines Skills am meisten an?

Ein guter Skill wird zuverlässig ausgewählt, schließt eine beobachtete Lücke und bleibt klein genug für die Pflege.

  • Schreibt die Beschreibung für die Auswahl. Die eigentlichen Instruktionen konzentrieren sich auf den Workflow, der das Verhalten ändert.
  • Findet zuerst die Lücken, indem ihr die Aufgabe ohne den Skill laufen lasst. Ergänzt dann nur die Anleitung, die diese Lücken schließt.
  • Haltet die aktive Skill-Sammlung so klein, dass ihr sie testen, ausdünnen und bei neuen Modellen pflegen könnt.

Wie schreibt ihr einen Skill, der auslöst und funktioniert?

Schreibt die Beschreibung für die Auswahl und beschränkt den Body auf den Workflow, der das Verhalten ändert.

Ein Skill hilft nur, wenn der Agent ihn auswählt und danach auch damit arbeiten kann. Anthropics Leitfaden zum Schreiben von Skills dreht sich vor allem darum, das gemeinsame Kontextfenster zu schützen. Beim Start laden nur Name und Beschreibung eines Skills vor. SKILL.md liest der Agent erst, wenn der Skill relevant wird. Mitgelieferte Referenzdateien und Skripte laden oder laufen nur bei Bedarf. Ein großer Skill kostet deshalb keinen Kontext, bis er auslöst (Anthropic - Skill authoring best practices (öffnet in einem neuen Tab)).

  • Haltet SKILL.md unter 500 Zeilen. Lagert den Überhang in Dateien aus, die SKILL.md eine Ebene tief verlinkt. Tief verschachtelte Dateien liest Claude nur teilweise an und übersieht dabei Inhalte.
  • Schreibt die Beschreibung in der dritten Person, mit beidem: was der Skill tut und wann er dran ist. Über genau dieses Feld wählt Claude unter mehr als 100 Skills aus.
  • Passt die Freiheitsgrade an die Aufgabe an. Wo viele Wege funktionieren, reichen Instruktionen in Prosa. Bei fragilen Operationen braucht es exakte Skripte ohne Parameter (Anthropic - Skill authoring best practices (öffnet in einem neuen Tab)).

Skripte laufen, statt in den Kontext gelesen zu werden. Ein geprüftes Hilfsskript im Skill ist deshalb zuverlässiger und billiger, als wenn der Agent den Code jedes Mal neu erzeugt. Das Muster stammt von Anthropic. Das Team sah Claude immer wieder dasselbe Python-Skript für das Styling von Folien schreiben. Also speicherte es das Skript im Skill, “as a tool for his future self”. Dieselben Engineers sehen Tools als die Ebene, in die zu wenig investiert wird. Detaillierte Prompts stehen dort neben spartanischen Tools, deren “parameters are named A and B”. Ihr Ziel ist ein Fortschritt, der sich mit der Zeit aufsummiert, und sie benennen es klar: Claude soll an Tag 30 der Zusammenarbeit viel besser sein als an Tag eins (Anthropic engineers on skills and tools (öffnet in einem neuen Tab), Mai 2026).

Erfahrungen aus der Praxis relativieren die Regel, Inhalte auf Dateien aufzuteilen. Supabase beobachtete, dass Agenten Referenzdateien nur ungern lesen. Lesen sie doch eine, lesen sie meist keine weitere. Alles Kritische wanderte deshalb inline in eine SKILL.md von rund 100 Zeilen. Ihr Leitprinzip: dem Agenten beibringen, wie er aktuelle Informationen findet, statt was darin steht. “Fetch the docs, don’t replicate them” (Supabase-Docs erscheinen als Markdown, wenn ihr an eine beliebige URL .md anhängt) (Supabase Agent Skills (öffnet in einem neuen Tab), April 2026).

Der Skill Wizard von Context7 schlägt für Bibliothekswissen den umgekehrten Weg ein. Er erzeugt aus aktueller Dokumentation eine eng zugeschnittene SKILL.md. Sein Argument: Wer von Hand schreibt, kann eine Bibliothek nicht vollständig kennen (“you don’t know what you don’t know”). Beim Zuschnitt sind sich beide Seiten einig: ein Skill pro Aufgabe, nicht pro Bibliothek. Sonst bindet ihr einfach die Docs ein (Context7 Skill Wizard walkthrough (öffnet in einem neuen Tab), März 2026).

Skills lassen sich auch auf Pfade beschränken. Dann lädt der Deployment-Skill eines Payments-Teams nie automatisch, wenn jemand anderswo im Monorepo arbeitet (Anthropic - How Claude Code works in large codebases (öffnet in einem neuen Tab), Mai 2026).

Anthropic empfiehlt, Evaluationen vor der Dokumentation zu bauen. Lasst die Aufgabe ohne den Skill laufen, um die echten Lücken zu finden. Schreibt drei Testszenarien und ergänzt dann nur so viel Instruktion, dass sie bestehen. So dokumentiert niemand eingebildete Probleme (Anthropic - Skill authoring best practices (öffnet in einem neuen Tab)). Der empfohlene Loop setzt Claude auf beiden Seiten ein. Eine Instanz entwirft und verfeinert den Skill, eine frische Instanz nutzt ihn an echten Aufgaben. Beobachtete Fehler fließen in den Entwurf zurück.

Die Community-Variante desselben Loops steckt in der Bibliothek Superpowers. Ihr Skill zum Schreiben von Skills spielt das Szenario erst ohne den Skill als Baseline durch, dann mit ihm. Danach überarbeitet er den Skill anhand der Unterschiede zwischen beiden Läufen. Ein Reviewer testete im Januar 2026 30 Skills aus Vercels damals neuem Verzeichnis. Er hält genau diese Gewohnheit, die Eval-Lücke zu messen, für das, was den meisten Skill-Autor:innen fehlt. Vercels eigener React-Performance-Skill fand bei ihm 18 Probleme, fünf davon kritisch, alle in unter 15 Minuten behoben (Testing 30 agent skills from Vercel’s directory (öffnet in einem neuen Tab), Januar 2026).

Dieselbe Review nennt Vokabular als unterschätzten Inhalt eines Skills. Ein UI-Skill dokumentiert 67 Interface-Stile und 96 Paletten. Er wirkt, weil er dem Agenten das Lexikon gibt (neobrutalism, liquid glass), das aus einer vagen Anfrage einen One-Shot macht. Skills sind ausführbare Fähigkeiten und damit auch eine Angriffsfläche. Ein bösartiger Skill kann Schwachstellen einschleusen oder den Agenten anweisen, Daten abfließen zu lassen. Anthropic rät, Skills nur aus vertrauenswürdigen Quellen zu installieren. Bei einem nicht vertrauenswürdigen Skill prüft ihr vor dem Einsatz seine Dateien und Abhängigkeiten. Dazu kommen alle Instruktionen, die auf nicht vertrauenswürdige Netzwerkquellen zugreifen (Anthropic - Equipping agents for the real world with Agent Skills (öffnet in einem neuen Tab), 16. Oktober 2025).

Die Community rund um Continuous Delivery behandelt den Zuschnitt eines Skills als Designregel. Ein Skill tut eine Sache, ein fehlgeschlagener Lauf zeigt dann auf einen Schritt. Warnzeichen dafür, dass ein Skill zu viel tut, sind ein “and” im Namen, je nach Input völlig unterschiedliche Ausführungspfade und Aufrufer, die nur die Hälfte nutzen. Eine Instruktion unter fünf oder sechs Zeilen bleibt inline in der Agent-Definition. Ein wiederverwendeter oder eigenständig gepflegter Ablauf wandert in einen Skill. Skills, die einen Modellwechsel überstehen sollen, nutzen nummerierte Schritte im Imperativ. Sie nennen ihr Ausgabeformat ausdrücklich und meiden Trennzeichen-Syntax, auf die nur eine Modellfamilie reagiert (MinimumCD.org and DojoConsortium.org - Agentic Architecture Patterns (öffnet in einem neuen Tab), Stand März 2026).

Kann ein Agent einen Skill unbeaufsichtigt optimieren?

Ein Optimierer kann einen Skill über Nacht tunen, sobald eine gemessene Baseline über jede Änderung entscheidet.

Skill Forge verpackt den Eval-first-Loop als wiederholbaren Optimierer. Im Skill Mode verändert er eine SKILL.md gegen Evals mit Assertions. Der Generic Mode wendet denselben Loop auf beliebige Dateien an, gemessen per Shell-Befehl. Im Auto mode läuft er ohne Eingriff. Im Guided mode zeigt er Checkpoints für Evals, Hypothesen, Diffs, Scores und das Weitermachen (GodModeAI2025 - Skill Forge (öffnet in einem neuen Tab)).

Der Setup-Wizard macht die Baseline zur Pflicht statt zur Empfehlung. Im Skill Mode verlangt die Konfiguration vor der ersten Mutation mindestens drei Evals und einen Train-Test-Split von 60/40. Dazu kommen ein gültiger Dry Run und ein zusammengesetzter Score. So kann niemand gegen eine ungemessene oder kaputte Aufgabe optimieren (GodModeAI2025 - Skill Forge (öffnet in einem neuen Tab)).

Jedes Experiment macht eine gezielte Änderung und hält Hypothese und Kategorie fest. Dann vergleicht es das Ergebnis mit der aktuellen Baseline. Die Standardregel behält klare Gewinne über 0,02 und macht Rückschritte unter -0,05 rückgängig. Knappe Fehlschläge zeichnet sie getrennt auf. Eine Coverage-Matrix verteilt frühe Experimente auf noch unberührte Kategorien. Spätere Runden nutzen dann die stärksten davon aus (GodModeAI2025 - Skill Forge (öffnet in einem neuen Tab)).

Unbeaufsichtigtes Optimieren braucht einen Zustand, aus dem es sich erholen kann. Skill Forge speichert nach jedem Experiment einen Checkpoint und kompaktiert nach fünf Experimenten die ältere Historie. Infrastrukturfehler versucht es einmal erneut, nach drei Abstürzen in Folge pausiert es. Aus einem Lauf über Nacht wird so ein fortsetzbares Protokoll von Experimenten statt einer einzigen undurchsichtigen Agent-Session (GodModeAI2025 - Skill Forge (öffnet in einem neuen Tab)).

Der Vortrag zum Schreiben von Skills behandelt Auslösen, Struktur, Steuerung und Ausdünnen. Er benennt einen Zielkonflikt, den die Dokumentation auslässt. Jeder vom Modell aufgerufene Skill erhöht die Kontextlast, denn seine Beschreibung kostet bei jedem Request. Skills, die Nutzer:innen selbst aufrufen, verlagern die Kosten auf ihre kognitive Last. Superpowers setzt eher auf Aufruf durch das Modell, die Bibliothek des Speakers eher auf Aufruf durch die Nutzer:innen. Der Grund: Ein Modell “may just choose not to follow” einen Kontext-Pointer (The Missing Manual: How to Write Great Skills (öffnet in einem neuen Tab), Juni 2026).

Zum Steuern nutzt der Talk Leitwörter. Das sind dichte Begriffe wie “vertical slice”, die der Agent in seinen Reasoning-Traces wiederholt. Sie wirken besser als negative Formulierungen wie “don’t code layer by layer”. Wer einen Workflow auf getrennte Skills aufteilt, erzwingt Fleißarbeit, die das Modell überspringt, wenn es das Ziel schon sieht. Deshalb gibt es den Skill grill-with-docs: Die Rückfragen des Plan Mode recherchieren von sich aus nie genug. Beim Pruning benennt der Talk drei Fehlerbilder. Das erste ist Duplikation. Das zweite ist Sediment, also geteilte Docs, die irrelevantes Material ansammeln, das niemand löscht. Das dritte sind No-ops: Instruktionen, die scheinbar etwas tun, das Verhalten aber nicht ändern. Sie fallen bei Löschtests auf (The Missing Manual: How to Write Great Skills (öffnet in einem neuen Tab), Juni 2026).

Ein späterer Post desselben Autors gibt dem No-op-Test konkrete Ziele. Zeilen wie “be thorough” oder “make the commit message very detailed” wiederholen, was ein Agent ohnehin standardmäßig tut. Entfernt jede einzelne und vergleicht die Ausgabe. Ändert sich ohne die Zeile nichts, war sie ein No-op. Laut Post enthalten von Agenten geschriebene Skills ganze Absätze davon. No-ops machen einen Skill schwerer zu evaluieren und zu pflegen und kosten dabei Token (Post on skill no-ops (öffnet in einem neuen Tab), Juni 2026).

Der Erfinder von Claude Code pflegt etwa sieben dokumentierte Skills. Er beschreibt die Grenze als Skill Debt: “the more you build, the more you owe in maintenance”. Tragfähig seien 5 bis 10 aktiv gepflegte Skills statt 50, denn Skills driften, während die Modelle besser werden (Skills, loops, and skill debt interview (öffnet in einem neuen Tab), April 2026).

Eine veröffentlichte Bibliothek wettet auf das Gegenteil. Den Einwand der Pflege beantwortet sie mit Struktur statt mit Zurückhaltung. pstack ist ein Plugin unter MIT-Lizenz, geschrieben von einem Cursor-Engineer und ausgeliefert in Cursors offiziellem Plugin-Repository. Es enthält einen “mode”-Skill als Einstiegspunkt und rund zwei Dutzend situative Skills. Dazu kommen einundzwanzig Prinzip-Skills mit je einer einzigen Regel. Beispiele sind: erst löschen, dann hinzufügen; illegale Zustände unrepräsentierbar machen; Verhalten am laufenden Artefakt beweisen statt an einem Self-Report.

Der Einstiegspunkt hält die Sammlung navigierbar. Aufgerufen, öffnet er eine Todo-Liste, deren erster Punkt das Lesen eines Inline-Index dieser Prinzipien ist. Dann ordnet er die Anfrage einem von zweiundzwanzig Playbooks zu. Dazu gehören Bugfix, Performance, Refactoring, visuelle Parität, autonomer Lauf und sicheres Pausieren. Die Schritte dieses Playbooks kopiert er wörtlich in die Liste. Sobald die Schritte greifen, leitet er zu den anderen Skills weiter. Er ist ein Sticky Mode und bleibt über Turns hinweg aktiv, bis Nutzer:innen ihn abschalten (cursor - pstack (öffnet in einem neuen Tab), Stand August 2026).

Drei Entscheidungen beim Schreiben tragen diese Struktur:

  • Jedes Prinzip ist eine eigenständige Datei, damit andere Skills es per Namen aufrufen, statt die Regel neu zu formulieren. So hat auch eine große Bibliothek einen Owner pro Regel.
  • Das passende Playbook landet als Kopie in der Todo-Liste statt als Link. Darin steckt dasselbe Misstrauen gegenüber Kontext-Pointern, das der Vortrag zum Schreiben von Skills oben benennt.
  • Die Bibliothek liefert einen Skill mit, der die eigenen Transkripte der Nutzer:innen auswertet. Daraus entwirft er einen persönlichen Routing-Skill auf derselben Basis. Ein Team kann so die Prinzipien behalten und das Routing ersetzen (cursor - pstack (öffnet in einem neuen Tab), Stand August 2026).

Dasselbe Repository liefert einen Skill, der auf das Register der Prosa des Agenten zielt statt auf sein Verhalten bei der Aufgabe. Er benennt die Merkmale, an denen man generierten Text erkennt. Das Modell prüft einen Entwurf gegen diese Merkmale und schreibt ihn um. Danach wendet es den Skill in jedem folgenden Turn erneut an. So hält die Korrektur über die ganze Session, statt nur einmal zu greifen. Grundlage ist der subjektive Vorher-nachher-Eindruck eines einzelnen Reviewers ohne Messung. Detektor-Scores misstraut dieser Reviewer als Beleg (So I tried Matt’s skills… (öffnet in einem neuen Tab), August 2026, Praktiker).

Die Merkmale, nach denen ein solcher Skill sucht, lassen sich in echten Texten messen. Barron’s zählte die Konstruktion “it’s not X, it’s Y” in Dokumenten großer US-Unternehmen. Es waren 49 im Jahr 2023, 100 im Jahr 2024 und 208 im Jahr 2025. Ein Unternehmen für KI-Erkennung mahnte zur Vorsicht. Die Phrase beweise keinen KI-Einsatz, sie sei schon ein Klischee gewesen, bevor Sprachmodelle sie übernahmen (Fortune - The “it’s not X, it’s Y” phrase giving CEOs away (öffnet in einem neuen Tab), April 2026).

Skills dienen auch als Gedächtnis eines Teams, über die reine Fähigkeit hinaus. Sionic AI fährt mehr als 1.000 ML-Experimente am Tag und schließt den Kreis mit zwei Befehlen. /retrospective lässt Claude die beendete Session lesen und die Erkenntnisse als Skill-Datei aufschreiben. Dann legt Claude einen Branch an, committet und öffnet einen Pull Request gegen eine Team-Registry. /advise holt vor neuer Arbeit Wissen aus dieser Registry und zeigt, was die Experimente von Kolleg:innen schon belegt haben. Jede Skill-Vorlage enthält eine Tabelle Failed Attempts. Laut Sionic wird sie häufiger gelesen als jeder andere Abschnitt. GitHub Actions prüfen die Plugin-Struktur und erzeugen marketplace.json neu, so pflegt sich die Registry selbst. Ein Nebeneffekt im Verhalten: Weil die Leute wissen, dass später die Retrospektive läuft, erklären sie ihre Überlegungen in den Sessions klarer (How We Use Claude Code Skills to Run 1,000+ ML Experiments a Day (öffnet in einem neuen Tab), Dezember 2025).

Zwei Mechanismen bestimmen, wie sich ein geladener Skill verhält. Der Inhalt eines aufgerufenen Skills landet als einzelne Nachricht in der Konversation und bleibt dort für den Rest der Session. Jede Zeile kostet also immer wieder Token. Die Auto-Compaction hängt pro Skill nur den jüngsten Aufruf wieder an und behält davon die ersten 5.000 Token. Das geschieht innerhalb eines gemeinsamen Budgets von 25.000 Token, das sich vom jüngsten Skill her füllt. Ältere Skills können also ganz wegfallen (Anthropic - Extend Claude with skills (öffnet in einem neuen Tab)).

Auch die Auswahl hat ein Budget. Namen und Beschreibungen laden vor, damit Claude weiß, was es gibt. Das Budget dieser Liste wächst aber nur mit 1 % des Kontextfensters des Modells. Jeden Eintrag schneidet es bei 1.536 Zeichen ab, und zuerst fallen die Beschreibungen der am wenigsten genutzten Skills weg. Deshalb muss der wichtigste Anwendungsfall am Anfang der Beschreibung stehen (Anthropic - Extend Claude with skills (öffnet in einem neuen Tab)).

Zwei Frontmatter-Schalter legen fest, wer einen Skill auslöst. disable-model-invocation: true reserviert ihn für User, gedacht für Befehle mit Seiteneffekten wie Deploy. user-invocable: false reserviert ihn für Claude, gedacht für Hintergrundwissen, das als Befehl keinen Sinn ergibt. Ein Skill kann auch Live-Ausgaben der Shell einbetten, bevor Claude sie sieht. Das Preprocessing mit !`command` verankert Instruktionen im aktuellen Diff, Pull Request oder Environment. context: fork führt den ganzen Skill als Subagent aus (Anthropic - Extend Claude with skills (öffnet in einem neuen Tab)). Skills nehmen auch Argumente. $ARGUMENTS und Session-Variablen werden beim Aufruf in den Body eingesetzt, argument-hint dokumentiert den erwarteten Input. Die Frontmatter kennt außerdem die Felder allowed-tools, compatibility, license und metadata (What the docs don’t tell you about Claude Code skills (öffnet in einem neuen Tab), Mai 2026).

Das Auslösen folgt Wahrscheinlichkeiten, und Praktiker:innen stoßen an seine Grenzen. Ein Skill für Task-Management feuerte auf sein Trigger-Wort nur manchmal. Das eingebaute Verhalten des Plan Mode überstimmte ihn, und sobald andere Skills luden, verstummte er. Zustand in Dateien erwies sich deshalb als verlässlicher als ein Skill, dem man zutraut, Prosa über Sessions hinweg zu befolgen. Gemeint sind eine tasks.md, eine requirements.md und eine session.md, gesteuert von einer expliziten State Machine (Minimalist Claude Code task management workflow (öffnet in einem neuen Tab)). Konferenzpublikum berichtet von derselben Lücke: Skills, die man manuell aufrufen muss. Der Speaker sieht darin ein Problem im Training des Modells auf die Skill-Auswahl (How Claude Code works (öffnet in einem neuen Tab), 26. Dezember 2025). Die Lehre: Wissen, das der Agent immer anwenden muss, gehört in den stets geladenen Kontext. In einem Skill, der vielleicht auslöst oder auch nicht, ist es falsch aufgehoben.

Ein billiger Trick taucht in mehreren Quellen auf: Begründet die Instruktion mit ihrer Folge. “your response will be read aloud by a text-to-speech engine, so never use ellipses” wirkt besser als die nackte Regel. Ein Skill zum Klonen von Websites stellt die Absicht überall voran, wo das Modell Lücken füllen muss. Er nennt die Technik motivational direction (15 hidden Claude Code rules (öffnet in einem neuen Tab), 10. Dezember 2025; Building a UI-cloning skill (öffnet in einem neuen Tab), März 2026).

Wie evaluiert ihr einen Skill, bevor ihr ihn ausliefert?

Ein Lager lehnt es ab, einen Skill ohne Evals auszuliefern, weil der Durchschnittsgewinn Aufgaben verdeckt, die der Skill verschlechtert.

Ein Staff Engineer bei Google DeepMind vertritt, dass ein Skill ohne Evals nicht ausgeliefert werden sollte. Er zieht eine Unterscheidung, die über die Lebensdauer eines Skills entscheidet. Capability-Skills bringen eine fehlende oder instabile Fähigkeit bei. Sie sollten in Rente gehen, sobald die Modelle diese Fähigkeit aufnehmen. Preference-Skills kodieren organisationsspezifisches Verhalten. Sie bleiben wertvoll, solange die Präferenz gilt (Don’t ship skills without evals (öffnet in einem neuen Tab), Juli 2026).

Die Größe des Effekts ist gemessen. Die Studie SkillsBench (v4, überarbeitet am 14. Juni 2026) umfasst 87 Aufgaben aus 8 Domänen und 18 Konfigurationen aus Modell und Harness. Sie stützt sich auf 9.396 ausgewählte öffentliche Ergebnisdateien. Kuratierte Skills heben die durchschnittliche Pass Rate von 33,9 % ohne Skills auf 50,5 % mit Skills. Das sind 16,6 Prozentpunkte. Der Gewinn ist ungleich verteilt: 16 von 84 vergleichbaren Aufgaben zeigten negative Deltas. Selbst erzeugte Skills lagen in allen drei getesteten Konfigurationen mit dediziertem Harness unter der Baseline ohne Skills (arXiv - SkillsBench (öffnet in einem neuen Tab)). Der Durchschnitt verdeckt also echte Nachteile. Jenes Lager verlässt sich auf ein Eval pro Skill, um zu zeigen, auf welcher Seite ein Skill landet.

Das Rezept für die Evaluation ist konkret.

  • Beginnt mit 10 bis 20 Fällen: positive Trigger, negative Nicht-Trigger und echte Traces aus der Produktion.
  • Gebt jedem Fall ein explizites Erfolgskriterium. Bewertet das Ergebnis, nicht ob der Agent den erwarteten Weg nahm oder im ersten Turn auslöste.
  • Isoliert jeden Lauf und wiederholt ihn 2 bis 6 Mal, um Varianz auszugleichen.
  • Testet über die tatsächlichen Kombinationen aus Modell und Harness, mit denen ihr ausliefert.
  • Bevorzugt deterministische Checks, wo immer es geht, also Assertions per Regex, SDK, Modell oder Methode. Einen LLM-Judge spart ihr für semantische oder Trajektorien-Aussagen auf, die sich keiner deterministischen Assertion fügen (Don’t ship skills without evals (öffnet in einem neuen Tab)).

Laut Talk hält DeepMind neben jedem internen Skill Evals bereit. CI blockiert eine Änderung, außer sie verbessert die Fälle oder erweitert die Abdeckung. Als ausgearbeitetes Beispiel dient der Skill des Teams für die Gemini Interactions API. Er nutzte 117 Fälle und erreichte in einem internen Lauf mit Gemini 3.1 Pro etwa 95 %. Das öffentliche Repository meldet 87 % auf Gemini 3 Flash und 96 % auf Gemini 3.1 Pro (google-gemini - gemini-skills (öffnet in einem neuen Tab)).

Über den Lebenszyklus zahlt sich eine Ablation aus, die ihr behaltet. Lasst die Suite mit und ohne den Skill laufen. Hält die Baseline ohne ihn, nehmt einen Capability-Skill außer Dienst, behaltet aber seine Evals. So zeigt eine spätere Regression in Modell oder Harness den Moment an, in dem die Anleitung zurückkommen muss (Don’t ship skills without evals (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Skill-Evaluation und -Optimierung

Skill-Bibliotheken

Leitfäden zum Schreiben