Skills für KI-Agenten in domänenspezifischen Geschäftsprozessen entwickeln

Ein universell einsetzbarer KI-Coding-Agent bewältigt überraschend viele Aufgaben kompetent. Er liest Dokumentation, schreibt Code, analysiert Fehler und löst mit ausreichend Kontext auch unbekannte Probleme. Doch die meisten Teams, die solche Agenten im laufenden Betrieb einsetzen, stoßen auf dieselbe Schwierigkeit: Diesen Kontext bereitzustellen ist selbst eine Aufgabe, deren Aufwand mit der Komplexität des Fachgebiets wächst.

Ein Datenanalyst, der Lieferzeiten aus einem Ordner mit Bestellungen in unterschiedlichen Formaten extrahieren lassen möchte, will nicht jedes Mal erklären, was eine Bestellung ist, wie die Namenskonventionen seines Unternehmens funktionieren und welches Ausgabeformat nachgelagerte Systeme erwarten. Ebenso möchte ein Entwickler, der das Infrastruktur-Monitoring betreut, nicht in jedes Gespräch dieselben Alarmschwellen und Definitionen der Schweregrade kopieren. Das Problem ist die Wiederholung.

Skills – wiederverwendbare Konfigurationen, die Fachwissen und Verhaltensanweisungen zu einer aufrufbaren Einheit bündeln – lösen dieses Problem direkt. Dieser Beitrag beschreibt, wie sie aufgebaut werden, wie sie in wiederkehrenden Workflows eingesetzt werden und wo sie zuverlässig Nutzen bringen.

Was ein Skill eigentlich ist

Ein Skill ist weder eine Modellfunktion noch eine API-Fähigkeit. Er ist eine Datei – genauer gesagt eine Markdown-Datei in einem Verzeichnis, das der Agent beim Sitzungsstart durchsucht (in Claude Code beispielsweise eine SKILL.md-Datei in einem Ordner unter ~/.claude/skills/ oder im Projekt unter .claude/skills/; andere Agentenlaufzeitumgebungen verwenden eigene Speicherorte). Trifft der Agent auf eine Anfrage, die zur Beschreibung des Skills passt, lädt er dessen Anweisungen und folgt ihnen, statt sich das Vorgehen für die Aufgabe von Grund auf zu überlegen.

Die Datei enthält vier Elemente: einen Beschreibungsblock, der dem Agenten sagt, wann der Skill zu aktivieren ist; Anweisungen zum Umgang mit der jeweiligen Aufgabenklasse; optionale Angaben zum Werkzeugzugriff, die je nach Laufzeitumgebung Werkzeuge für die Ausführung vorab genehmigen oder deren Nutzung einschränken (in Claude Code genehmigt allowed-tools Werkzeuge vorab, ohne die übrigen einzuschränken); und optionale Beispiele, die korrektes Verhalten anhand realistischer Eingaben zeigen.

Die Datei enthält keine fest hinterlegten Geschäftsdaten. Ein Skill beschreibt das Vorgehen für eine Aufgabenklasse – das Fachvokabular, das Denkmuster und das Ausgabeformat –, nicht die Aufgaben selbst. Diese Unterscheidung zwischen dem Hinterlegen einer Vorgehensweise und dem Hinterlegen von Daten ist die zentrale Gestaltungsfrage bei Skills, die dauerhaft nützlich bleiben sollen.

Wann Fachwissen in einen Skill gehört – und wann nicht

Die meisten gescheiterten Skill-Implementierungen scheitern daran, dass sie zu viel festschreiben. Begeisterte Teams nehmen konkrete Anbieternamen, aktuelle Preisstufen, das bevorzugte Berichtsformat eines Kunden und die heute verwendeten API-Endpunkte in einen Skill auf. Sechs Monate später ist die Hälfte dieser Informationen falsch, der Skill entspricht nicht mehr der Realität und niemand weiß, welchen Teilen noch zu vertrauen ist.

Die praktische Regel lautet: Hinterlegen Sie, was sich langsam ändert, und überlassen Sie dem Agenten, was sich häufig ändert.

Fachvokabular ändert sich langsam. Ein Skill zur Verarbeitung von Importdokumenten sollte wissen, was ein Ursprungszeugnis ist, was die deduktive Methode bei der Zollwertermittlung bedeutet und wie der regulatorische Rahmen im Zielmarkt aussieht. Dieses Wissen ändert sich deutlich langsamer als operative Details, auch wenn regulatorische Rahmenbedingungen angepasst werden und weiterhin regelmäßig überprüft werden müssen. Es gehört in den Skill.

Konkrete Einreichungsformate, Namen von Geschäftspartnern, aktuelle regulatorische Schwellenwerte und genaue Fristen ändern sich ständig. Sie gehören in die Daten, die der Agent zur Laufzeit erhält, nicht in die Skill-Definition. Der Skill vermittelt, wie eine bestimmte Dokumentklasse zu lesen ist. Das konkrete Dokument wird als Kontext bereitgestellt.

Ein hilfreicher Test: Müssten Sie den Skill bei jeder Änderung im Geschäftsumfeld aktualisieren, enthält er die falschen Informationen. Gut gestaltete Skills überstehen organisatorische Veränderungen. Schlecht gestaltete sind fast sofort veraltet.

Die SKILL.md-Struktur

Die übliche Struktur einer Skill-Datei ist einfach. Ein Frontmatter-Block benennt den Skill und legt fest, wann er aktiviert wird; der Hauptteil beschreibt seine Verwendung.

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Background on the domain: what this class of documents is, why it
exists, what the agent needs to know to interpret one intelligently.

## Approach
Step-by-step instructions for handling the task: what to look for,
how to handle ambiguous cases, what to escalate to human review.

## Output Format
Exactly what the output should contain, in what structure.

## Edge Cases
Known failure modes and how to handle them.

Der Beschreibungsblock ist im Betrieb der wichtigste Teil. Er entscheidet, ob der Agent den Skill überhaupt aktiviert. Eine vage Beschreibung wie „für Dokumente verwenden“ führt zu unberechenbarer Aktivierung. Eine präzise Beschreibung, die Dokumenttypen, Geschäftskontexte und relevante Märkte benennt, sorgt für zuverlässiges Verhalten.

Die Beschreibung sollte allerdings nicht zu eng gefasst sein. Sonst übersieht der Agent passende Anfragen. Ziel ist eine Beschreibung, in der ein aufmerksamer Praktiker seine Situation wiedererkennt – nicht mehr und nicht weniger. Das erfordert eine Kalibrierung in der Praxis. Bei der Einführung lohnt es sich, Grenzfälle zu testen, um zu prüfen, ob die Aktivierungsgrenzen den Erwartungen entsprechen.

Das /loop-Muster für wiederkehrende Aufgaben

Manche Geschäftsabläufe folgen einem Zeitplan: tägliche Datenextraktion aus einem API-Endpunkt, wöchentliche Zusammenführung von Lieferantenberichten oder monatliche Erstellung von Zusammenfassungen für Kunden. Das sind keine einmaligen Interaktionen, sondern fortlaufende operative Prozesse, die unabhängig von einer manuellen Auslösung laufen.

In Claude Code macht der Befehl /loop aus einer durch einen Skill gesteuerten Interaktion einen wiederkehrenden Vorgang:

/loop 24h /process-supplier-reports

Dabei wird der benannte Skill im angegebenen Intervall innerhalb der aktuellen Sitzung erneut ausgeführt, die bei jedem Aufruf den Kontext bereitstellt. Der Skill erledigt die Arbeit; die Schleife übernimmt die Zeitplanung. Stand Oktober 2026 ist /loop laut der Dokumentation von Claude Code an die Sitzung gebunden: Aufgaben werden nur ausgeführt, solange die Sitzung läuft, und wiederkehrende Aufgaben laufen nach sieben Tagen ab. Dauerhafte Zeitpläne für den Produktivbetrieb gehören daher in einen Cronjob, eine CI-Pipeline oder eine geplante Cloud-Aufgabe, die denselben Skill aufruft.

Wiederkehrende Skills erfordern besondere Gestaltungsentscheidungen, die bei interaktiven Skills nicht nötig sind. Sie müssen idempotent sein: Die zweimalige Ausführung mit derselben Eingabe darf keine doppelten Datensätze oder Benachrichtigungen erzeugen und den Zustand nachgelagerter Systeme nicht beschädigen. Sie brauchen ein ausdrücklich definiertes Fehlerverhalten: Was passiert bei fehlerhaften Eingaben, einer nicht verfügbaren API oder fehlenden erwarteten Daten? Verarbeiten nachgelagerte Systeme die Ausgabe, muss sie zudem maschinenlesbar sein und darf nicht nur für Menschen verständlich sein.

Skills, die in einer Schleife zuverlässig funktionieren, sind fast immer enger gefasst als interaktive Skills. Ein interaktiver Skill kann fünf verschiedene Dokumenttypen verarbeiten und bei unbekannten Typen noch brauchbare Teilergebnisse liefern. Die Schleifenvariante verarbeitet einen Dokumenttyp präzise und meldet bei unerwarteten Eingaben ausdrücklich einen Fehler. Zuverlässigkeit im Betrieb verlangt Präzision statt Flexibilität.

Eine praktische Faustregel: Wenn Sie das gesamte erwartete Verhalten des Skills einschließlich der Fehlerfälle nicht in weniger als zehn Minuten beschreiben können, ist er wahrscheinlich zu breit angelegt, um zuverlässig nach Zeitplan zu laufen.

Praktische Beispiele aus dem Produktivbetrieb

Drei Muster, die wir im laufenden Betrieb eingesetzt haben:

Datenextraktion aus der Lieferantenkommunikation. Lieferanten senden Auftragsbestätigungen, Versandmitteilungen und Rechnungsaktualisierungen in uneinheitlichen Formaten – manchmal strukturiert, oft nicht. Ein auf den Kommunikationsstil des jeweiligen Lieferanten abgestimmter Skill extrahiert strukturierte Daten aus unstrukturiertem Text. Er weiß, dass ein bestimmter Lieferant die Bestellreferenz im zweiten Absatz seiner Bestätigungs-E-Mail nennt, das Datumsformat DD.MM.YYYY verwendet und seine Produktcodes einem bestimmten Muster folgen. Der tatsächliche E-Mail-Inhalt ändert sich wöchentlich; die Art der Auswertung bleibt gleich. Die extrahierten Daten fließen direkt in Bestandssysteme, ohne manuellen Eingriff zwischen Nachrichteneingang und Datenerfassung.

Berichterstellung aus operativen Daten. Für eine wöchentliche Zusammenfassung der operativen Abläufe muss bekannt sein, welche Kennzahlen relevant sind, welche Schwellenwerte zählen, welche Vergleiche über Zeiträume hinweg sinnvoll sind und wie Ergebnisse für eine bestimmte Zielgruppe dargestellt werden sollen. All das ändert sich nicht von Woche zu Woche. Ein Skill hält es einmal fest. Zur Laufzeit erhält der Agent die aktuellen Daten und wendet das hinterlegte Analysemodell an. Ausgabeformat, Sprachregister und stets erforderliche Abschnitte sind im Skill definiert und müssen nicht jedes Mal neu vorgegeben werden. So entsteht eine Konsistenz, die manuelles Prompting bei größerem Umfang selten erreicht.

System-Monitoring und Alarmierung. Infrastruktur erzeugt kontinuierlich Protokolle. Monitoring-Skills definieren, welche Muster ein beachtenswertes Ereignis darstellen, wie dessen Schweregrad einzuordnen ist und welche Informationen ein Mensch braucht, um auf eine Meldung wirksam zu reagieren. In Verbindung mit dem Schleifenmuster prüfen diese Skills in kurzen Intervallen definierte Bedingungen und erzeugen strukturierte Meldungen, sobald diese erfüllt sind.

Die entscheidende Gestaltungsfrage ist hier der Umgang mit Fehlalarmen. Ein Skill, der bei jeder Anomalie warnt, gewöhnt die Verantwortlichen daran, Meldungen zu ignorieren. Die eigentliche Arbeit ist die Kalibrierung: genau festzulegen, unter welchen Bedingungen eine Meldung menschliche Aufmerksamkeit verdient. Das ist kein technisches Problem, sondern eine Frage des Fachwissens. Dafür braucht es detaillierte Beiträge der Menschen, die heute manuell auf Probleme reagieren. Sie haben bereits verinnerlicht, wo relevante Signale vom Hintergrundrauschen zu unterscheiden sind. Der Skill formalisiert dieses Wissen.

Was Skills nicht lösen

Skills hinterlegen Kompetenz in bestimmten Fachgebieten. Sie schaffen keine allgemeine Leistungsfähigkeit.

Ein gut konfigurierter Skill verarbeitet bekannte Muster zuverlässig. Mit völlig neuen Situationen kommt er schlecht zurecht, weil die Anweisungen, die ihn in vertrauten Kontexten zuverlässig machen, ihn in unbekannten aktiv einschränken. Deshalb funktionieren Skills am besten bei hinreichend abgegrenzten Aufgaben: Importdokumentation aus bestimmten Märkten, Berichterstellung für einen definierten Kennzahlensatz oder Protokollanalyse anhand bekannter Alarmmuster. „Bei operativen Geschäftsabläufen helfen“ ist keine abgegrenzte Aufgabe. Skills können einen Agenten nicht in Bereichen kompetent machen, in denen niemand definiert hat, wie Kompetenz aussieht.

Die andere Grenze ist die Pflege. Skills, die Fachwissen enthalten, müssen aktualisiert werden, wenn sich dieses Wissen ändert. Nicht bei jeder Änderung, denn gut gestaltete Skills vermeiden volatile Informationen, doch manche Änderungen sind unvermeidbar. Skills aktuell zu halten erfordert dieselbe Disziplin wie die Pflege von Dokumentation. Unternehmen, die nicht darin investieren, stellen nach und nach fest, dass ihre Skills nicht mehr der Realität entsprechen. Der Fehler bleibt zunächst unauffällig: Der Skill läuft weiter, liefert weiter Ergebnisse, und diese sind auf subtile Weise falsch, die erst nach einiger Zeit auffällt.

Die Unternehmen, die aus Skills den größten Nutzen ziehen, investieren sowohl in die Erstkonfiguration als auch in die laufende Kalibrierung. Der anfängliche Aufwand ist geringer, als die meisten erwarten. Der laufende Pflegeaufwand ist größer, als die meisten einplanen. Eine ehrliche Planung dieses Aufwands entscheidet darüber, ob Skills dauerhaft nützlich bleiben oder zu einer Quelle unbemerkter Fehler werden.

Weiterführende Beiträge

• Claude Skills: Anthropics Antwort auf das Problem der KI-Anpassung – Wie Anthropics Skill-System aufgebaut ist und welches organisatorische Problem es löst
• Einen lokalen KI-Assistenten mit Websuche aufbauen: MCP + Ollama einrichten – Praktische Werkzeuge für KI-Agenten in einer selbst betriebenen Umgebung einrichten
• PunchOut-Integration mit WooCommerce: B2B-Beschaffung durch intelligente Automatisierung vereinfachen – Domänenspezifische Automatisierung für einen strukturierten B2B-Workflow