Zum Hauptinhalt springen

Bessere Agent Skills mit Test-Measure-Refine

· 4 Minuten Lesezeit
Claude Dev
Claude Dev
Claude Dev

Die meisten Agent Skills scheitern aus einem banalen Grund: Wir ändern Prompts, testen einmal und nennen es „besser“.

Anthropic’s aktuelles Skill-Creator-Update setzt auf einen stärker engineering-orientierten Zyklus: zuerst testen, Verhalten messen, dann verfeinern. Wenn ihr interne Agent-Workflows baut, ist genau das die relevante Veränderung.

Dieser Beitrag übersetzt die offizielle Ankündigung in einen Entwickler-Workflow, den ihr wöchentlich ausführen könnt.

Kernidee: Nicht mehr blind prompten​

Das offizielle Update ist nicht nur „bessere Prompt-Generierung“. Es ist ein Qualitätskreislauf:

  1. Messbares Verhalten vorab definieren
  2. Daraus eine Test-Suite erzeugen
  3. Alte/neue Versionen evaluieren
  4. Evaluator-Feedback nutzen, um Konflikte und tote Instruktionen zu entfernen
  5. Evidenzbasiert iterieren statt nach Bauchgefühl

Wenn das wie CI für Prompts klingt, ist das genau der Punkt.

Was sich im Skill Creator geändert hat (Developer-Sicht)​

Aus dem offiziellen Post sind diese Änderungen praktisch relevant:

  • Golden Prompts vor der Implementierung
    Ihr schreibt (oder erstellt gemeinsam) konkrete Prompts, die reale Aufgaben abbilden. Das sind eure Baseline-Cases.

  • test-creator für automatische Skill-Tests
    Skill Creator kann aus Anforderungen Tests generieren, statt dass ihr jeden Fall manuell schreibt.

  • Integrierter Skill Evaluator
    Evaluator-Feedback zeigt Konflikte, Überschneidungen und Schwachstellen in Instruktionen, damit ihr die Skill-Spezifikation schärfen könnt.

  • Verfeinerung anhand von Qualitätssignalen
    Erwartet wird ein Loop über mehrere Versionen, mit Messung gegen Test-Outputs statt „fühlt sich besser an“.

Das passt besser zu Engineering-Teams, weil Skills wie versionierte Artefakte behandelt werden, nicht wie One-Shot-Prompts.

Praktischer Workflow, den ihr direkt nutzen könnt​

Schritt 1) Akzeptanzkriterien wie API-Verhalten schreiben​

Bevor ihr Skill-Text ändert, definiert erwartetes Verhalten streng:

  • Input-Form
  • Output-Schema
  • Must-do-Regeln
  • Must-not-do-Regeln
  • Failure-Verhalten (was tun bei fehlendem Kontext)

Unscharfe Kriterien erzeugen unscharfe Tests.

Schritt 2) Golden-Prompt-Set aus realen Fällen bauen​

Nutzt echte Logs, Tickets oder Team-Anfragen. Enthalten sein sollten:

  • Normalfall
  • Rausch-/Mehrdeutigkeitsfall
  • Missing-Context-Fall
  • Out-of-Scope-Fall

Das ist eure Regressionssuite. Klein, aber signalstark.

Schritt 3) Tests generieren und ausführen​

Mit Skill Creator + test-creator strukturierte Skill-Tests erzeugen. Dann beide ausführen:

  • Aktueller Produktions-Skill
  • Aktualisierter Kandidat

Output-Qualität auf derselben Testmenge vergleichen.

Schritt 4) Evaluator-Feedback durchgehen und Instruktionen entschlacken​

Achtet auf wiederkehrende Muster:

  • Widersprüchliche Instruktionen
  • Zu breite Instruktionen
  • Versteckte Annahmen
  • Instabiles Output-Format

Pro Iteration nur ein bis zwei Variablen ändern, damit Verbesserungen zuordenbar bleiben.

Schritt 5) Nur bei besseren Metriken promoten​

Nicht shippen, weil ein Beispiel gut aussah. Nur promoten, wenn:

  • Die Pass-Rate über die ganze Suite steigt
  • Failure-Modes reduziert statt nur verschoben werden
  • Das Ausgabeformat in Edge-Cases stabil bleibt

Wo Teams typischerweise hängenbleiben​

Häufige Failure-Modes in Entwicklerteams:

  • Zu viele Regeln in einem Skill
    Ein Mega-Skill für Summarization, Planning, Classification und Policy-Interpretation degradiert meist schnell.

  • Keine versionierten Testdaten
    Ohne versionierte Golden Prompts sind Trendlinien nicht belastbar.

  • Kein Refusal-Verhalten
    Skills sollten klar definieren, was bei unzureichenden Daten oder Out-of-Scope passiert.

  • Refinement ohne Hypothese
    „Wir ändern mal das Wording“ ohne messbare Hypothese kostet nur Zyklen.

Besseres Mental Model​

Behandelt einen Skill so:

  • Prompt-Text = Implementierung
  • Golden Prompts = Unit-Tests
  • Evaluator + Testläufe = Regressionschecks
  • Release Note = Changelog

Wenn Teams dieses Modell übernehmen, wird Skill-Qualität vorhersagbar.

Minimal-Template für den nächsten Skill-PR​

Nutzt diese Struktur in eurer internen PR-Beschreibung:

## Goal
What user job this skill solves.

## Behavior Contract
- Inputs
- Outputs
- Guardrails
- Refusal policy

## Test Set
- Golden prompts: N
- Edge cases included: yes/no

## Results
- Baseline pass rate: X%
- Candidate pass rate: Y%
- Known regressions: ...

## Decision
Promote / Hold / Roll back

So lassen sich Skill-Änderungen mit denselben Standards wie Code-Änderungen reviewen.

Fazit​

Der stärkste Teil von Anthropic’s Skill-Creator-Update ist nicht „smartere Generierung“.

Entscheidend ist: Skills passen jetzt in einen entwicklernahen Lebenszyklus:

design -> test -> evaluate -> refine -> release

Wenn euer Team ernsthafte Agent-Workflows baut, stoppt ihr so Prompt Drift und liefert zuverlässige Skills aus.

Quelle​