Skills als ausführbares Wissen
Dokumentiertes Wissen erklärt, was zu tun ist. Ausführbares Wissen legt zusätzlich fest, wann, womit, innerhalb welcher Grenzen und mit welchem Qualitätsnachweis es getan werden darf.

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.
● Nur für Mitglieder
Lies den vollständigen Artikel und lade alle Dateien mit einer Mitgliedschaft herunter.
Vollständigen Artikel + Downloads freischalten → Abonnieren0 Kommentare
● Kommentare werden geladen…