Skills als ausführbares Wissen

Organisationen besitzen viele Methoden: Prüflisten, Leitfäden, Entscheidungsbäume, Vorlagen und Erfahrungsregeln. Solange sie nur als Dokumente vorliegen, muss ein Mensch sie finden, interpretieren und auf den aktuellen Fall übertragen. Ein KI-Agent kann diese Arbeit unterstützen, aber ein langer Prompt macht aus einer Methode noch keinen verlässlichen Prozess. Er beschreibt Verhalten in natürlicher Sprache, ohne Eingaben zwingend zu validieren, Berechtigungen technisch zu begrenzen oder Ergebnisse reproduzierbar zu prüfen.

Ein Skill schließt diese Lücke. Er verpackt fachliche Absicht, Aktivierungsbedingungen, Eingabe- und Ausgabeverträge, Werkzeugzugriffe, Verfahrensschritte, Grenzen, Tests und Evidenz zu einer versionierten Einheit. Der Agent erhält damit nicht bloß „mehr Kontext", sondern einen kontrollierten Weg, eine bestimmte Fähigkeit auszuführen. So wird Wissen wiederverwendbar, prüfbar und in unterschiedlichen Projekten konsistent einsetzbar.

Ein Skill ist mehr als ein Prompt

Ein Prompt kann Rolle, Ziel und gewünschtes Format formulieren. Das ist wichtig, aber unvollständig. Er beantwortet häufig nicht, ob eine Datei existiert, welches Schema ihre Daten erfüllen müssen, welche Schnittstelle aufgerufen werden darf, wie ein Fehler behandelt wird oder welche Freigabe vor einer Änderung erforderlich ist.

Ein belastbarer Skill besitzt deshalb mindestens vier Schichten. Die semantische Schicht erklärt Zweck und Fachlogik. Die vertragliche Schicht definiert Eingaben, Ausgaben und Fehler. Die operative Schicht bindet Werkzeuge, Berechtigungen und Laufzeitgrenzen. Die prüfende Schicht enthält Testfälle, Qualitätskriterien und Nachweise. Natürliche Sprache bleibt Teil des Pakets, wird aber durch maschinenlesbare Regeln und ausführbare Kontrollen ergänzt.

Aus tacitem Wissen wird ein expliziter Ablauf

Erfahrene Fachleute überspringen gedanklich viele Schritte. Sie erkennen unvollständige Angaben, unterscheiden harmlose Abweichungen von kritischen Ausnahmen und wissen, wann sie stoppen müssen. Beim Schreiben eines Skills muss dieses tacite Wissen sichtbar werden. Dafür reicht es nicht, den idealen Ablauf zu beschreiben. Wichtig sind Grenzfälle, Ausschlusskriterien und Eskalationspunkte.

Eine gute Extraktion beginnt mit realen Fällen: drei erfolgreiche, zwei fehlerhafte und mindestens ein uneindeutiger Fall. Für jeden Fall werden Ausgangslage, Entscheidung, verwendete Evidenz, Handlung und erwartetes Ergebnis notiert. Aus wiederkehrenden Mustern entstehen Regeln; aus Ausnahmen entstehen Stop- oder Rückfragebedingungen. Der Skill bildet also nicht nur „Best Practice", sondern auch professionelles Nicht-Handeln ab.

Der Vertrag beginnt vor der Ausführung

Jeder Skill braucht einen klaren Eingang. Welche Felder sind erforderlich? Welche Datentypen, Wertebereiche, Dateiformate und Sprachen sind zulässig? Welche Annahmen dürfen nicht stillschweigend getroffen werden? JSON Schema kann strukturierte Eingaben beschreiben und validieren. Für Dateien kommen Größen-, Typ-, Prüfsummen- und Sensitivitätsprüfungen hinzu.

Auch die Ausgabe besitzt einen Vertrag. Ein Bericht kann Abschnitte, Quellen, Status und Unsicherheiten verlangen. Eine Datenänderung kann eine Patch-Datei statt direkter Mutation erzeugen. Ein Ergebnis ohne ausreichende Evidenz erhält needs_review statt eines erfundenen Erfolgsstatus. Fehler sind keine freien Entschuldigungen, sondern definierte Zustände wie invalid_input, permission_denied, tool_unavailable, quality_failed oder approval_required.

Verträge machen Fähigkeiten kombinierbar. Wenn Skill A garantiert ein validiertes Manifest erzeugt und Skill B genau dieses Manifest akzeptiert, kann ein Workflow beide verbinden, ohne dass Bedeutung zwischen losen Texten erraten werden muss.

Aktivierung ist eine fachliche Entscheidung

Ein Skill sollte nicht allein deshalb starten, weil sein Name semantisch ähnlich klingt. Er braucht positive Aktivierungsbedingungen und negative Ausschlüsse. Ein „Vertragsprüfung"-Skill kann etwa nur für vollständig vorliegende Dokumente einer bestimmten Art gelten und ausdrücklich keine Rechtsentscheidung treffen. Ein „Datenexport"-Skill darf nur auf freigegebene Datensätze und genehmigte Ziele angewendet werden.

Eine Aktivierungsentscheidung protokolliert Anfrage, erkannte Voraussetzungen, gewählte Skill-Version und Gründe. Bei hoher Auswirkung kann ein Mensch die Auswahl bestätigen. Das verhindert, dass ein Agent einen technisch verfügbaren, aber fachlich ungeeigneten Skill verwendet.

Werkzeuge werden als Fähigkeiten mit Grenzen gebunden

Ein Skill darf nur die Werkzeuge erhalten, die sein Zweck benötigt. Lesen, Schreiben, Löschen, Ausführen und externe Übermittlung sind unterschiedliche Rechte. Ein Berichtsskill braucht möglicherweise lesenden Dateizugriff, aber keine Löschberechtigung. Ein Importskill kann in einen Staging-Bereich schreiben, jedoch nicht direkt in den freigegebenen Bestand.

Schnittstellenbeschreibungen wie OpenAPI helfen, Operationen, Parameter und Antworten maschinenlesbar zu definieren. Sie ersetzen keine Autorisierung. Der Skill legt zusätzlich Zielsysteme, erlaubte Ressourcen, Zeitlimits, Mengenlimits und Folgen bei Fehlern fest. Credentials werden zur Laufzeit aus einem sicheren Store bezogen und nicht in Anweisungen eingebettet.

Entscheidungen brauchen Evidenz, nicht nur Begründung

Ein Agent kann nachträglich plausible Gründe formulieren. Das ist kein Nachweis für den tatsächlichen Ablauf. Deshalb sammelt der Skill strukturierte Evidenz: Input-Revision, aufgerufene Werkzeuge, Parameter, Rückgabestatus, erzeugte Artefakte, Prüfresultate und Freigaben. W3C PROV bietet dafür die nützliche Unterscheidung zwischen Entitäten, Aktivitäten und verantwortlichen Akteuren.

Die Protokollierung muss datensparsam bleiben. Nicht jeder Eingabewert gehört dauerhaft in ein Log. Sensible Inhalte können durch Referenzen, Hashes oder redigierte Auszüge vertreten werden. Ziel ist nachvollziehbare Ausführung, nicht eine zweite unkontrollierte Datenbank.

Tests prüfen Verhalten, Grenzen und Fehlermodi

Ein Skill ohne Tests ist eine Behauptung. Die kleinste Testsuite enthält einen Normalfall, Grenzwerte, fehlende Pflichtangaben, widersprüchliche Daten, nicht verfügbares Werkzeug, verweigerte Berechtigung und einen Prompt-Injection-Versuch aus einem gelesenen Dokument. Zusätzlich braucht es fachliche Goldfälle mit erwarteten Entscheidungen und verbotenen Handlungen.

Tests unterscheiden deterministische und probabilistische Teile. Ein Schema muss stets gleich validieren. Eine Zusammenfassung kann variieren, muss aber Quellenabdeckung, verbotene Aussagen und Formatkriterien erfüllen. Wiederholte Läufe messen Streuung. Änderungen am Modell, an Werkzeugen oder Abhängigkeiten lösen Regressionstests aus.

Evaluation prüft nicht nur, ob der Skill „irgendwie fertig" wurde. Sie misst Richtigkeit, Vollständigkeit, Quellenbindung, Kosten, Laufzeit, Rückfragen, Abbruchquote und falsche Freigaben. Kritische Fehler erhalten stärkere Gewichtung als stilistische Abweichungen.

Prompt Injection macht Grenzen unverzichtbar

Ein Agent verarbeitet Daten, die selbst Anweisungen enthalten können: Webseiten, E-Mails, PDFs oder Tickets. Solche Inhalte dürfen den Skillvertrag nicht überschreiben. Die Architektur trennt vertrauenswürdige Steuerung von untrusted content, minimiert Werkzeuge, prüft Ausgaben vor Folgeaktionen und verlangt Freigaben für irreversible Schritte.

Kein einzelner Systemhinweis garantiert Schutz. OWASP beschreibt direkte und indirekte Prompt Injection als fortbestehendes Risiko. Deshalb setzt ein Skill mehrere Barrieren: Content-Markierung, Berechtigungsgrenzen, Ziel-Allowlist, Datenflussregeln, Simulation gefährlicher Aktionen und menschliche Bestätigung. Sicherheit entsteht aus Systemdesign, nicht aus einer besonders strengen Formulierung.

Versionen ändern Verträge

Skills entwickeln sich. Semantic Versioning liefert ein verständliches Muster: Ein Major-Wechsel kennzeichnet inkompatible Verträge, Minor ergänzt kompatible Funktionen, Patch korrigiert kompatibel. Entscheidend ist nicht die Nummer allein, sondern ein Changelog mit Auswirkung, Migration und erneuter Freigabe.

Jede Ausführung bindet eine konkrete Version und die Version ihrer Abhängigkeiten. „Immer neueste" macht Ergebnisse schwer reproduzierbar. Neue Versionen durchlaufen Tests, Sicherheitsprüfung und gestufte Einführung. Ein Rollback muss nicht nur Dateien zurücksetzen, sondern auch entstandene Datenänderungen berücksichtigen.

Skills sind Produkte mit Eigentümerschaft

Ein Skill braucht fachlichen Owner, technischen Maintainer und Risikoverantwortung. Der fachliche Owner entscheidet, ob Methode und Grenzfälle stimmen. Der Maintainer hält Schema, Tools und Tests lauffähig. Die Risikoverantwortung genehmigt Berechtigungen und Freigabepunkte. Eine Person kann mehrere Rollen tragen, aber die Entscheidungen bleiben sichtbar.

Ein Registry-Eintrag enthält Zweck, Version, Status, Owner, erlaubte Umgebungen, Datenklassen, Werkzeuge, Abhängigkeiten, Tests, letzte Prüfung und Stilllegungsdatum. Veraltete Skills werden nicht nur vergessen, sondern deaktiviert und mit einem Nachfolger verknüpft.

Wiederverwendung braucht Parameter statt Kopien

Kopierte Skills driften auseinander. Besser ist ein stabiler Kern mit klaren Parametern und projektspezifischen Policies. Eine universelle Policy-Schicht ist jedoch ebenfalls gefährlich: Recht, Sprache, Risiko und Datenzugriff können sich je Projekt unterscheiden. Der Skill definiert deshalb, welche Werte parametrierbar sind und welche Schutzgrenzen nicht überschrieben werden dürfen.

Komposition erfolgt über Verträge, nicht über Textverkettung. Ein Orchestrator prüft Vor- und Nachbedingungen, reicht nur notwendige Daten weiter und stoppt, wenn ein Ergebnis den nächsten Vertrag nicht erfüllt. So bleibt sichtbar, welcher Skill welche Entscheidung vorbereitet hat.

Methode: EXTRACT → CONTRACT → BOUND → TEST → VERSION → OBSERVE → IMPROVE

EXTRACT macht fachliche Entscheidungen und Ausnahmen explizit. CONTRACT definiert Input, Output und Fehler. BOUND begrenzt Werkzeuge, Daten und Auswirkungen. TEST prüft Normalfälle, Grenzfälle und Angriffe. VERSION hält Verträge reproduzierbar. OBSERVE sammelt datensparsame Evidenz. IMPROVE nutzt Fehler und Reviews für kontrollierte Weiterentwicklung.

Ein Skill ist dann ausführbares Wissen, wenn eine andere Person seine fachliche Absicht verstehen, ein System seine Verträge prüfen und eine Organisation jede relevante Wirkung begrenzen und nachvollziehen kann.

Übungsblatt: Entwirf einen Skill Contract

1. Wähle eine wiederkehrende Methode mit klarem Ergebnis und benenne ihren Owner.

2. Dokumentiere drei Erfolgsfälle, zwei Fehlerfälle und einen uneindeutigen Fall.

3. Definiere Aktivierungsbedingungen, Ausschlüsse, Input-, Output- und Fehlerstatus.

4. Ordne jedem Werkzeug minimale Rechte, erlaubte Ziele und Laufzeitlimits zu.

5. Schreibe sieben Tests einschließlich Berechtigungsfehler und Prompt Injection.

6. Lege Evidenz, Qualitätsmetriken, Freigabepunkte und Abbruchbedingungen fest.

7. Vergib Version, Changelog, Reviewdatum und Stilllegungsregel.

Reflexion: Welche Expertenentscheidung steckt heute noch unsichtbar zwischen zwei Prozessschritten? Welche Berechtigung könnte aus dem geplanten Skill entfernt werden, ohne seinen Zweck zu gefährden?

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

Einordnung: „Skill" bezeichnet hier ein produktunabhängiges, ausführbares Wissenspaket. Formate und Laufzeiten unterscheiden sich zwischen Plattformen. Ein Skill ist weder automatisch sicher noch fachlich richtig; Berechtigungen, Tests, Freigaben und Laufzeitkontrollen bleiben erforderlich. Redaktionell und technisch geprüft am 17. Juli 2026.