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.

Werkzeuge und Berechtigungen bleiben Laufzeitkontrollen

Ein Skill kann festlegen, welche Tools er benötigt. Er darf sich die Berechtigung aber nicht selbst erteilen. Der Host entscheidet, welche Funktionen verfügbar sind, auf welche Daten sie zugreifen und wann eine menschliche Bestätigung erforderlich ist.

Die MCP-Spezifikation trennt Ressourcen, Prompts und Tools. Für Tools nennt sie unter anderem Eingabevalidierung, Zugriffskontrolle, Rate Limits, Ausgabeprüfung, Timeouts und Auditprotokolle. Sensible Operationen sollen für Nutzer sichtbar und bestätigbar sein. Diese Kontrollen gehören in die Laufzeit, nicht nur als freundlicher Satz in die Skill-Anweisung.

Das Prinzip lautet minimale Befugnis. Ein Recherche-Skill braucht Leserechte, aber kein Recht zum Löschen. Ein Dokument-Skill benötigt einen abgegrenzten Ausgabeordner, nicht das gesamte Dateisystem. Ein Deployment-Skill darf zunächst eine Vorschau erzeugen und erst nach Freigabe veröffentlichen. So wird der mögliche Schaden begrenzt, selbst wenn Modell, Prompt oder Quelle manipuliert werden.

Ein Skill ist Teil der Software-Lieferkette

Fremde Skills können Anweisungen, Skripte und Abhängigkeiten mitbringen. Eine harmlos klingende Beschreibung kann vom tatsächlichen Verhalten abweichen. Referenzen können indirekte Prompt-Injection enthalten; Skripte können Daten senden oder Dateien verändern. Installation ist daher eine Vertrauensentscheidung.

Vor Übernahme werden Herkunft, Lizenz, Dateiinhalte, Netzwerkzugriffe, Abhängigkeiten, Toolanforderungen und Änderungsverlauf geprüft. Versionen werden fixiert, Hashes oder signierte Releases können Integrität unterstützen. Aktualisierungen laufen nicht ungeprüft in Produktion. Kritische Skills erhalten einen Owner, Reviewpflicht und einen Rücknahmeweg.

OWASP beschreibt Excessive Agency als Risiko, wenn LLM-Systeme zu viele Funktionen, Berechtigungen oder Autonomie erhalten. Ein sauber geschriebener Skill reduziert dieses Risiko nur, wenn seine tatsächliche Laufzeit begrenzt ist. Gute Worte ersetzen keine Sandbox.

Qualität entsteht durch Evaluation, nicht durch Länge

Ein Skill wird an Aufgaben gemessen. Ein Testset enthält normale Fälle, Grenzfälle, fehlende Eingaben, widersprüchliche Quellen, ungültige Formate, Toolfehler und Angriffsversuche. Bewertet werden Aktivierung, Ergebnisqualität, Regelbefolgung, Werkzeugwahl, Kosten, Laufzeit und sicheres Abbrechen.

Die Prüfung trennt mehrere Ebenen. Routing-Evaluation fragt, ob der richtige Skill aktiviert wurde. Prozess-Evaluation prüft Reihenfolge und Werkzeugnutzung. Artefakt-Evaluation bewertet das Ergebnis. Sicherheits-Evaluation testet Berechtigungsgrenzen und manipulierte Eingaben. Regressionstests stellen sicher, dass eine Verbesserung nicht frühere Fähigkeiten zerstört.

Ein langer Skill kann schlechter sein als ein kurzer, wenn er unklare Prioritäten erzeugt. Ein kurzer Skill kann unzureichend sein, wenn er Fehlerfälle verschweigt. Entscheidend ist nicht die Zahl der Zeilen, sondern wie zuverlässig der Skill unter realen Bedingungen den vertraglich zugesagten Zustand erreicht.

Versionierung macht Lernen kontrollierbar

Skills verändern sich mit Werkzeugen, Daten und Anforderungen. Jede veröffentlichte Version braucht Changelog, kompatible Laufzeit, bekannte Grenzen und zugehörige Evaluationsergebnisse. Größere Änderungen werden zunächst gegen gespeicherte Fälle ausgeführt. Alte Versionen bleiben reproduzierbar, solange Aufbewahrung und Sicherheit es erlauben.

Fehlerberichte werden nicht einfach als zusätzliche Warnsätze unten angehängt. Zuerst wird der Fehler lokalisiert: falscher Trigger, fehlende Referenz, unklare Regel, defektes Tool, schwacher Test oder falsche Berechtigung. Danach wird die kleinste geeignete Schicht geändert. So verhindert man, dass die Kernanweisung zu einem Friedhof historischer Ausnahmen wird.

Ein Skill ist dann reif, wenn ein anderer Agent oder ein anderes Team ihn verstehen, ausführen, prüfen und sicher zurückweisen kann. Er speichert nicht bloß einen erfolgreichen Prompt. Er macht eine Arbeitsweise portabel.

Übungsblatt: Baue einen Skill-Vertrag

Wähle eine wiederkehrende Aufgabe und entwirf den Skill in acht Schritten.

1. Scope festlegen. Formuliere Zweck, positive Trigger, Grenzfälle und Nicht-Ziele.

2. Inputs definieren. Beschreibe Pflichtdaten, Formate, Rechte und Validierung.

3. Prozess zerlegen. Trenne Modellurteil, deterministische Skripte und menschliche Freigabe.

4. Ressourcen ordnen. Lagere volatile Fakten, Referenzen und Assets aus der Kernanweisung aus.

5. Toolrechte begrenzen. Gib jedem Schritt nur die minimal notwendige Funktion und Reichweite.

6. Output-Vertrag schreiben. Definiere Artefakte, Schema, Qualitätskriterien und Abschlusszustand.

7. Fehlerpfade bauen. Lege Retry, Abbruch, Rollback, Abstention und Eskalation fest.

8. Evaluation erstellen. Sammle Positiv-, Negativ-, Grenz-, Fehler- und Angriffstests.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Der Begriff „Skill" wird von Plattformen unterschiedlich umgesetzt. Dieser Artikel nutzt das offene Agent-Skills-Dateimodell als konkrete Referenz, behandelt aber allgemein die Architektur wiederverwendbarer prozeduraler Arbeitsmodule. Ein Skill garantiert weder Modellqualität noch sichere Ausführung; Laufzeit, Berechtigungssystem und Host bleiben eigenständige Kontrollschichten.