Ein Skill ist kein langer Prompt

Ein Prompt beschreibt einen Auftrag. Ein Skill beschreibt, wie eine Klasse von Aufträgen unter definierten Bedingungen wiederholbar, überprüfbar und sicher bearbeitet wird.

Wenn ein Sprachmodell eine Aufgabe einmal gut löst, liegt der nächste Gedanke nahe: Man speichert den erfolgreichen Prompt und verwendet ihn erneut. Mit jeder Ausnahme wächst der Text. Es kommen Formatregeln, Quellen, Beispiele, Werkzeughinweise, Fehlerbehandlung und neue Sonderfälle hinzu. Am Ende steht ein riesiger Universalprompt, der alles wissen und jede Situation abdecken soll.

Das wirkt gründlich, ist aber architektonisch schwach. Lange Anweisungen konkurrieren mit den eigentlichen Nutzerdaten um Kontext. Wichtige Regeln gehen zwischen Details unter. Veraltete Fakten bleiben unbemerkt erhalten. Ein globaler Projekttext beeinflusst auch Aufgaben, für die seine Einschränkungen gar nicht gedacht waren. Aus einem hilfreichen Leitfaden wird unsichtbare technische Schuld.

Ein Skill löst dieses Problem nicht durch mehr Text, sondern durch bessere Trennung.

Prompt, Projektregel, Ressource, Tool und Skill sind nicht dasselbe

Ein Prompt formuliert die aktuelle Absicht: Was soll jetzt geschehen? Eine Projektregel definiert übergreifende Konventionen, etwa Ordnerstruktur, Qualitätsniveau oder verbotene Aktionen. Eine Ressource liefert Wissen oder Daten. Ein Tool führt eine Funktion aus. Ein Skill verbindet diese Elemente zu einem wiederverwendbaren Arbeitsverfahren.

Diese Unterscheidung verhindert Überladung. Eine Preisliste gehört nicht dauerhaft in die Kernanweisung, sondern in eine aktualisierbare Datenquelle. Ein Parser gehört nicht als Pseudocode in einen Prompt, sondern als getestetes Skript. Eine Markenfarbe gehört in ein Asset oder Style-Referenzdokument. Die Nutzerfrage bleibt klein, weil die benötigten Bausteine gezielt hinzugeladen werden.

Der offene Agent-Skills-Standard macht diese Idee konkret: Ein Skill ist ein Ordner mit einer SKILL.md; optional kommen scripts/, references/ und assets/ hinzu. Das Dateiformat ist nur die Hülle. Die eigentliche Qualität entsteht durch den Vertrag, den diese Teile gemeinsam bilden.

Die Beschreibung ist ein Router

Bevor ein Agent einen Skill ausführt, muss er erkennen, dass dieser Skill überhaupt passt. Name und Beschreibung sind daher keine Werbetexte. Sie bilden die Routingoberfläche. Eine gute Beschreibung sagt, welche Aufgaben der Skill löst, wann er aktiviert werden soll und wann nicht.

Zu breite Beschreibungen führen zu Fehlaktivierung. „Hilft bei Dokumenten“ konkurriert mit jedem anderen Dokument-Skill. Zu enge Formulierungen übersehen Varianten. Besser ist eine beobachtbare Grenze: „Erstellt und überarbeitet mehrsprachige Arbeitsblätter als DOCX, rendert sie seitenweise und prüft Layout sowie Barrierefreiheit; nicht für Tabellenkalkulationen oder Präsentationen.“

Routing muss getestet werden. Ein Skill erhält positive Beispiele, schwierige Grenzfälle und klare Negativbeispiele. Wenn zwei Skills dieselbe Anfrage beanspruchen, braucht es Prioritätsregeln, Komposition oder eine Rückfrage. Stille Zufallsauswahl ist keine robuste Architektur.

Progressive Offenlegung schützt den Kontext

Ein Agent muss nicht bei jedem Start sämtliche Anweisungen, Referenzen und Skripte aller verfügbaren Skills laden. Die Agent-Skills-Spezifikation empfiehlt drei Stufen: zunächst nur Metadaten zur Entdeckung, danach die Kernanweisung bei Aktivierung und schließlich zusätzliche Dateien nur bei Bedarf.

Diese progressive Offenlegung ist mehr als Tokenökonomie. Sie reduziert Interferenz. Ein juristischer Prüfprozess beeinflusst keine Bildbearbeitung, solange er nicht relevant ist. Eine selten benötigte API-Referenz verdrängt nicht die aktuelle Nutzereingabe. Gleichzeitig bleibt Detailwissen verfügbar, wenn der konkrete Arbeitsschritt es verlangt.

Die Kernanweisung sollte deshalb navigieren, nicht das gesamte Handbuch duplizieren. Sie beschreibt Ablauf, Auswahlregeln, Qualitätsgates und Verweise. Lange Tabellen, Fachreferenzen, Formatvorlagen und Beispielkorpora liegen getrennt. Jede Referenz bleibt fokussiert und wird über einen eindeutigen Pfad erreicht.

Ein Skill braucht einen Arbeitsvertrag

Ein produktiver Skill beantwortet mindestens neun Fragen:

1 · Trigger: Welche Absicht und welche Eingaben aktivieren ihn?

2 · Voraussetzungen: Welche Dateien, Rechte, Programme oder Daten müssen vorhanden sein?

3 · Ablauf: Welche Schritte werden in welcher Reihenfolge ausgeführt?

4 · Entscheidungen: Wo darf das Modell urteilen, wo gelten deterministische Regeln?

5 · Werkzeuge: Welche Funktionen sind erlaubt und mit welchem Umfang?

6 · Output: Welche Dateien, Felder, Formate und Qualitätsmerkmale werden erwartet?

7 · Verifikation: Welche Tests müssen vor Abschluss bestehen?

8 · Fehlerverhalten: Wann wird korrigiert, zurückgerollt, eskaliert oder abgebrochen?

9 · Grenzen: Was darf der Skill ausdrücklich nicht tun?

Dieser Vertrag macht implizites Erfahrungswissen prüfbar. „Erstelle ein gutes Dokument“ wird zu konkreten Kriterien: Dateityp, Sprache, Umfang, Quellenregeln, Layoutprüfung, erlaubte Werkzeuge und Abnahmetest. Flexibilität bleibt dort erhalten, wo mehrere Lösungen sinnvoll sind; Sicherheitsgrenzen und Output-Schema bleiben stabil.

Prozedurales und faktisches Wissen werden getrennt

Skills enthalten vor allem prozedurales Wissen: wie eine Aufgabe bearbeitet wird. Aktuelle Modelllisten, Preise, Rechtsstände, Benchmarks oder Produktfunktionen verändern sich dagegen laufend. Werden sie fest in die Kernanweisung geschrieben, altert der Skill ohne sichtbares Signal.

Veränderliche Fakten gehören in datierte Referenzen, Datenbanken oder verifizierbare Abfragen. Jeder Datensatz braucht Quelle, Stand, Geltungsbereich und Aktualisierungsverantwortung. Der Skill beschreibt, wie diese Daten ausgewählt und geprüft werden. Er behauptet nicht, dass sein gespeichertes Wissen dauerhaft aktuell bleibt.

Das gilt besonders für Modellrouting. „Nutze Modell X für Analyse und Modell Y für Extraktion“ kann morgen überholt sein. Robuster ist eine Fähigkeitsmatrix mit Anforderungen wie Kontextgröße, Werkzeugunterstützung, Latenz, Datenschutz, Kosten und gemessener Ergebnisqualität. Ein Router wählt anhand aktueller, geprüfter Daten – und fällt bei Unsicherheit auf eine sichere Standardstrategie zurück.

Skripte übernehmen Determinismus

Nicht jeder Schritt sollte in natürlicher Sprache bleiben. Dateinamen validieren, Schemas prüfen, Hashes bilden, Tabellenbreiten berechnen oder Tests ausführen sind deterministische Aufgaben. Ein Skript kann sie reproduzierbar erledigen und klare Fehlercodes liefern.

Das Modell entscheidet, wann der Schritt benötigt wird und wie Ergebnisse eingeordnet werden. Das Skript garantiert die mechanische Operation. Diese Arbeitsteilung reduziert Halluzinationen und macht Wiederholungen vergleichbar.

Skripte brauchen dennoch Engineering: dokumentierte Abhängigkeiten, begrenzte Eingaben, verständliche Fehlermeldungen, idempotentes Verhalten, Tests und sichere Standardwerte. Ein Skill ist kein Freibrief, beliebigen Code auszuführen. Ausführbare Dateien erhöhen die Angriffsfläche und müssen wie Software geprüft werden.