Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird

AI macht Routine-Coding-Aufgaben immer austauschbarer, und dieser Trend beschleunigt sich. Doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Process Engines wie Zeebe liefern reine Prompts noch immer inkonsistente, oft frustrierende Ergebnisse. Das liegt vor allem daran, dass es kaum Trainingsdaten gibt, die Domäne spezialisiert ist und die Varianz zwischen den Engines hoch ist.

Skills könnten die Antwort sein. Statt deine Domäne, deine Konventionen und deine Edge Cases jedes Mal aufs Neue zu erklären, hältst du dieses Wissen einmal fest—und das Modell greift automatisch darauf zu. Ich habe diesen Ansatz in echten Projekten getestet und bin überzeugt, dass er funktioniert.

Dieser Post teilt daher meine Learnings mit dir. Er erklärt, was Skills sind, wie du sie auf die BPMN-Prozessorchestrierung anwendest und welche Vorteile sie bieten. Außerdem geht es darum, welche Guardrails du einsetzen solltest, um die Qualität hoch zu halten und gleichzeitig schneller zu werden. Zum Schluss teile ich die Sammlung an Skills, die ich in echten Projekten gebaut und erprobt habe.

🚀 Wird Coding austauschbar?

In letzter Zeit habe ich viel darüber gelesen, welchen Einfluss AI auf die Software-Entwicklung hat. Und obwohl ich nicht zu denen gehöre, die glauben, dass Entwickler bald komplett ersetzt werden—manches, was gerade passiert, finde ich wirklich überraschend.

Erst vor wenigen Tagen soll Spotify gesagt haben, dass ihre besten Entwickler seit Dezember keine einzige Zeile Code mehr geschrieben haben—weil sie die Implementierung von AI-Agents erledigen lassen. Und in einer aktuellen Folge des Pragmatic-Engineer-Podcasts erwähnte der Schöpfer von Clawd, dass er Code ausliefert, den er nicht einmal mehr liest. Nur zwei Beispiele von vielen. Vielleicht Edge Cases, aber vielsagende. Ich behaupte nicht, dass das überall gilt. Aber sie deuten auf echtes Potenzial hin, besonders in gut repräsentierten Domänen.

Und dieses Potenzial gründet auf etwas Konkretem: Sprachen wie Java, Python und JavaScript. Konstrukte wie HTML und CSS. Komponenten wie REST-Endpoints und Datenbankabfragen. Die Art von Code, die seit Jahren—manchmal seit Jahrzehnten—öffentlich verfügbar ist. Eingebettet in Quelldateien auf unzähligen Websites, geteilt über Open-Source-Repositories, diskutiert in Foren wie Stack Overflow und dokumentiert in Publikationen und Tutorials. LLMs haben das alles in sich aufgenommen—praktisch das gesamte Wissen des Webs.

In diesen gut repräsentierten Domänen sind AI-Agents bemerkenswert leistungsfähig. Mit dem richtigen Prompt können sie Bausteine zu ganzen Services oder Produkten kombinieren—in einem Bruchteil der Zeit, die man früher gebraucht hätte. OpenClaw ist ein gutes Beispiel: ein echtes Produkt, im Wesentlichen von einem einzigen Entwickler gebaut, wobei AI den Großteil der Implementierung übernommen hat.

Ohne dieses konkrete Produkt zu bewerten—ich habe nie in seinen Code geschaut—ist das Ergebnis nicht immer das, was ein erfahrener Entwickler als sauber bezeichnen würde. Es ist selten perfekt konsistent mit den Konventionen einer bestehenden Codebase, und oft werden Edge Cases übersehen. Aber es funktioniert. Es ist ein echter Zeitgewinn und ein guter Startpunkt—entweder für die manuelle Weiterarbeit oder für den nächsten Prompt in einer iterativen Schleife. Und in kleinerem Umfang, mit ein paar Runden Review und Feedback, wird daraus tatsächlich sauberer, produktionsreifer Code.

Die Produktivitätsgewinne sind also real: weniger Zeit für Boilerplate, mehr Raum im Kopf für das, was wirklich zählt. Das ist echt wertvoll. Aber es gibt einen Haken, und der wird in dem Moment offensichtlich, in dem du eine Nischen-Domäne betrittst.

🔩 Warum Prozessorchestrierung mit BPMN eine andere Geschichte ist

Mit BPMN-Engines wie Zeebe zu arbeiten, um Prozesse zu automatisieren, ist keine Mainstream-Programmierdomäne. Es ist ein ziemlich spezialisierter Bereich der Orchestrierung, mit vergleichsweise wenigen öffentlichen Trainingsdaten. Und das wird ziemlich schnell sichtbar, wenn du versuchst, AI einzusetzen.

Wenn du ein LLM zum Beispiel bittest, einen Job Worker zu generieren oder einen Service Task in einer BPMN-Datei zu konfigurieren, bekommst du oft etwas, das richtig aussieht, aber nicht funktioniert. Und der Grund dafür ist einfach: Die Domäne ist voll von Konzepten, die es anderswo nicht gibt: Job Worker, Message Correlation, Variable Scoping, Incident Handling, BPMN-Datei-Schemas. Und was es noch kniffliger macht: Diese können auch zwischen den Engines variieren—obwohl BPMN selbst ein gemeinsamer Standard der OMG ist.

Beim Arbeiten mit AI musst du also iterieren. Du fügst Beispielcode hinzu. Du kopierst Dokumentation in den Context. Und nach ein paar Runden, oder manuellem Nachbessern, bekommst du etwas, das funktioniert. Fairerweise: Dieser iterative Ansatz ist bereits wertvoll—aber es gibt klares Verbesserungspotenzial.

🔄 Erste Schritte in die richtige Richtung

Mehrere Tools und Patterns sind bereits entstanden, um diese Lücke zu verkleinern.

Agent Files sind ein Ansatz. Sie geben dem Modell persistenten Context über dein Projekt—etwa Engine-spezifische Konventionen. Ihre Wirkung lässt jedoch nach, wenn die Datei lang und unscharf wird. Dann wirkt die Vermischung in beide Richtungen: Einerseits geht Zeebe-spezifischer Context im Rauschen der ganzen anderen Projektthemen unter. Und andererseits funkt das Engine-Wissen in Aufgaben hinein, die mit der Engine gar nichts zu tun haben.

Ein weiterer Ansatz ist das Model Context Protocol—kurz MCP. Es verbindet AI-Agents mit externen Tools und Datenquellen. Tools wie Context7 sind aus diesem Protokoll entstanden. Über Tool Calls ziehen sie aktuelle Library-Dokumentation direkt in den Context des Modells—etwa die neuesten Camunda-SDK-Docs. Diese Docs verfügbar zu haben, reduziert die Wahrscheinlichkeit deutlich, dass das Modell fehlerhafte oder veraltete API Calls generiert.

Ich habe beides ausprobiert. Beides hat geholfen. Aber keines fühlte sich ausreichend an. Der Context war immer in Gefahr, in der nächsten Konversation wieder verloren zu gehen, und es gab keinen konsistenten Weg, Engine-spezifisches Wissen so zu kodieren, dass das Modell sessionübergreifend zuverlässig darauf zugreifen konnte.

Bis jetzt—denn genau diese Lücke sollen „Skills“ füllen.

🧠 Skills: Wiederverwendbares Wissen

Ein Skill ist ein Ordner mit Anweisungen—einmal verpackt, jedes Mal wiederverwendet. Er bringt einem AI-Agent bei, wie er eine bestimmte Aufgabe oder einen Workflow handhabt, indem er Domänenwissen, Konventionen und Edge Cases explizit kodiert. So lädt das Modell ihn, wenn er relevant ist, statt darauf angewiesen zu sein, dass du in jeder Session neu promptest.

Skills basieren auf einem offenen Standard. Dieser Standard wurde ursprünglich von Anthropic entwickelt und offen veröffentlicht—ähnlich wie MCP. Das bedeutet, das Konzept ist nicht an ein einzelnes Tool oder einen einzelnen Anbieter gebunden: Es ist ein gemeinsames Fundament, das im gesamten Ökosystem wächst.

👩🏽‍💻 Wie man Skills baut

Ein Skill besteht aus bis zu drei Teilen. Die SKILL.md-Datei ist die einzige erforderliche Komponente. Sie enthält einen Frontmatter-Abschnitt mit Metadaten—wie den name, die description und allowed-tools (Tools, die der Agent während der Ausführung ohne Nachfrage nutzen darf) des Skills. Weitere Felder stehen ebenfalls zur Verfügung—etwa argument-hint, model und context—aber diese drei werden am häufigsten benötigt.

Neben diesen Metadaten im Frontmatter enthält das Markdown auch einen Body. Er hält die eigentlichen Anweisungen: wie der Output zu strukturieren ist, welche Patterns zu befolgen sind, welche Edge Cases zu behandeln sind und—entscheidend—wann eine Rückfrage zu stellen ist, bevor weitergemacht wird.

Insgesamt könnte ein solcher Skill also genau beschreiben, wie Zeebe Job Worker implementiert werden sollen. In einem vereinfachten Beispiel könnte das in etwa so aussehen:

---
name: create-worker
argument-hint: "[<path-to-ProcessApi-or-BPMN-file>] [task-type-constant]"
allowed-tools: Read, Write, Glob
description: Create a new @JobWorker class for a BPMN service task. Accepts a
	ProcessApi file, a BPMN model, or a plain description.
---

## Key Rules
- Use @JobWorker annotations from "io.camunda.client"
- Use @Variable annotation to define input variables of the job
- Inject the use-case interface as the only constructor parameter
- ...

## Pattern

```
package ...

import io.camunda.client.annotation.JobWorker
import io.camunda.client.annotation.Variable

@Component
class AbortRegistrationWorker(
	private val useCase: AbortSubscriptionUseCase
) {

	private val log = KotlinLogging.logger {}

	@JobWorker(type = TaskTypes.NEWSLETTER_ABORT_REGISTRATION)
	fun handle(@Variable subscriptionId: UUID) {
		log.debug { "Received job to abort registration for subscriptionId: $subscriptionId" }
		useCase.abort(SubscriptionId(subscriptionId))
	}
}
```

## Instructions

1. Find the required serviceTask in the Process-API or the bpmn-file itself
2. If you can’t resolve the process or task, ask the user to provide one
3. Derive package name and class name for the worker and search for existing files
4. If a file exists, report this to the user and ask what to do
5. Otherwise create a new worker using the camunda-spring-boot-starter patterns and key rules listed above
6. If you are missing any information (which annotations to use or use cases to inject), ask the user for feedback
7. Report the result and remind the developer to run `test-worker`

Darüber hinaus gibt es zwei optionale Ordner—nicht für jeden Skill erforderlich.

references/ enthält unterstützende Docs, die bei Bedarf geladen werden, um den Context des Modells schlank zu halten: Für einen Worker-Skill könnten das zusätzliche Codebeispiele kompletter Worker-Implementierungen oder Zeebe-spezifische Patterns zum Variable Handling sein.

scripts/ enthält ausführbare Helfer für deterministische Checks. Für einen Worker-Skill könnte das ein Script sein, das ein BPMN-Modell parst, die relevanten Service-Task-Typen herausfiltert und die Prozessvariablen für eine gegebene Task extrahiert—und so jede Mehrdeutigkeit beseitigt, bevor das Modell mit dem Generieren von Code beginnt. Insgesamt sieht ein Skill also in etwa so aus:

my-skill/        # The parent folder
├── SKILL.md     # Required: The skill description with frontmatter & body
├── references/  # Optional: supporting docs loaded on demand
└── scripts/     # Optional: executable helpers for deterministic checks

Wenn du mehr darüber wissen möchtest, wie man effektive Skills schreibt, ist Anthropics Complete Guide to Building Skills for Claude eine solide Referenz.

🕵🏽 Wie ein Skill erkannt wird

Wenn ein Skill entsprechend definiert ist, können Agents ihn automatisch erkennen und nutzen. Beim Start werden nur name und description vorab in den Context geladen. Wenn du eine Anfrage stellst, gleicht das Modell sie mit diesen Beschreibungen ab, um zu entscheiden, welcher Skill zu laden ist. Der vollständige Inhalt der SKILL.md wird erst gezogen, sobald sie aufgerufen wird—so bleibt der Context standardmäßig schlank.

Deshalb ist das description-Feld entscheidend: Es muss klar benennen, sowohl was der Skill tut als auch wann er einzusetzen ist. Die Mechanik dahinter ist ausführlich in der offiziellen Skills-Dokumentation beschrieben, die Discovery, Lade-Verhalten und Empfehlungen zum Schreiben effektiver Skill-Beschreibungen abdeckt.

🗂️ Wo Skills greifen

Der Anwendungsbereich von Skills ist breiter, als du vielleicht erwartest. Es gibt vor allem zwei Muster, bei denen sie durchgängig Mehrwert schaffen.

Das erste sind Domänen mit dünner Trainingsdatenlage. Bereiche, die entweder neu oder so speziell sind, dass es kaum öffentliche Beispiele gibt: Dazu gehören BPMN und Prozessorchestrierung, aber auch das zuvor genannte Model Context Protocol. In diesen Fällen liefern Skills direkt das, was das Modell aus dem Training nicht ableiten kann.

Das zweite ist hochgradig individueller Output. Jedes LLM kann einen REST Controller erstellen. Aber einen zu erstellen, der durchgängig der spezifischen Struktur, den Naming Conventions und den Error-Handling-Patterns deines Teams folgt? Das erfordert eine Anpassungsfähigkeit, die weder Training noch Prompting allein zuverlässig liefern können. Dasselbe gilt für die Analyse von Prozessen gegen einen eigenen Style Guide—oder jedes andere Artefakt, das jedes Mal einer bestimmten Form entsprechen muss.

All das liegt daran, dass LLM-Output von Natur aus ein Best Guess und nicht-deterministisch ist. Derselbe Prompt kann über mehrere Durchläufe unterschiedliche Ergebnisse liefern. Skills kodieren die Regeln explizit und geben dem Modell die bestmögliche Chance, konsistenten, strukturell vorhersehbaren Output zu produzieren.

📦 Wie sich Skills kategorisieren lassen

Bisher lag der Fokus darauf, wann Skills helfen. Aber es ist genauso nützlich, darüber nachzudenken, was sie eigentlich tun—denn das prägt, wie du sie gestaltest. Basierend auf Anthropics Beobachtungen lassen sich Use Cases für Skills tendenziell in drei Kategorien clustern:

• Output-Generierung—das Erzeugen von Artefakten mit konsistenter Form: Code, Dokumentation, Diagramme. Das create-worker-Beispiel oben ist ein direkter Fall: dieselbe Klassenstruktur, dieselbe Verwendung von Annotations und dieselben Naming Conventions bei jedem Durchlauf, unabhängig davon, wer ihn aufruft.
• Workflow-Automatisierung—das Kodieren wiederholbarer, mehrstufiger Abläufe. Ein review-process-Skill könnte zum Beispiel ein BPMN-Modell systematisch durchgehen: die Compliance gegen einen Style Guide prüfen, verifizieren, dass jeder Service Task einen zugehörigen Worker hat, bestätigen, dass jede Message einen Adapter hat, der sie mit der Engine verdrahtet, und prüfen, dass für jeden relevanten Pfad Prozesstests existieren—und dann einen strukturierten Report erzeugen, was vorhanden ist und was fehlt.
• MCP-Erweiterung—Skills, die externen Tool-Zugriff als Teil ihres Workflows einbinden. Statt die Zeebe-API-Details fest in den create-worker-Skill zu schreiben, könntest du ihn erweitern: Der Skill identifiziert zuerst, was gebaut werden muss, nutzt dann ein MCP, um die aktuellen Camunda-SDK-Docs in den Context zu laden, und generiert erst dann den Code—immer auf Basis der neuesten API, ohne manuelles Copy-Pasten von Dokumentation.

Diese Kategorien sind nützlich, um Skills einzuordnen, sollten aber nicht als strikte Grenzen behandelt werden. In der Praxis vermischen viele Skills mehrere Kategorien—und während sich das Ökosystem weiterentwickelt, werden wahrscheinlich neue Patterns entstehen, die in keine davon sauber passen.

🌐 Das Skill-Ökosystem

Das Ökosystem rund um Skills ist sehr aktiv und wächst schnell. Bis Februar 2026 wird der Agent-Skills-Standard bereits von vielen Agents unterstützt, etwa Claude Code, Gemini CLI, Cursor, GitHub und mehr.

Unternehmen veröffentlichen ihre eigenen Skill-Sammlungen—Anthropics Skills-Repo ist ein gutes Beispiel. Community-kuratierte Listen wachsen daneben. Und auch eigene Marketplaces und Verzeichnisse beginnen zu entstehen. LobeHub und findskill.ai sind frühe, die man kennen sollte.

Im Bereich der Prozessautomatisierung allerdings? Vergleichsweise wenige Skills existieren bisher. Das ist mit ein Grund, warum ich diesen Post geschrieben habe—um die Lücke zu füllen und erste Beispiele aus meiner Arbeit zu teilen.

🔬 Wie das in der Praxis aussieht

Während ich Skills in einem echten Zeebe-Projekt gebaut und verfeinert habe, habe ich die nützlichsten gesammelt und nach easy-zeebe verschoben—ein Repository, das anfangs einfach nur ein Lösungs-Template zum Automatisieren eines Prozesses mit Zeebe war.

Da ich Claude Code nutze, liegen die Skills im Ordner .claude/skills/. Aber weil Agent-Skills ein offener Standard ist, ist das keine Einschränkung. Du kannst sie unverändert mit jedem anderen Agent nutzen. Die aktuelle Sammlung sieht so aus:

.claude/skills/
├── automate-process/
├── create-process-adapter/
├── create-worker/
├── review-process/
├── test-process-adapter/
├── test-process/
├── test-worker/
└── ...

Sie enthält eine Mischung aus Generierungs-Skills—etwa zum Implementieren von Workern, Adaptern und Controllern. Aber auch einige Quality-Assurance-Skills wie das Reviewen von Prozessen. Kopier dir gern die, die du brauchst, fork das ganze Repo, pass sie an dein Setup an, lern von ihnen—und nutze die Vorteile, die sie dir bieten können.

Und wenn du auf Lücken stößt oder Patterns entdeckst, die besser funktionieren, teile sie gern—egal ob du mit Zeebe oder einer komplett anderen Engine arbeitest. Mein Ziel ist es, eine Sammlung zu schaffen, die allen in diesem Bereich hilft, schneller voranzukommen und mit mehr Selbstvertrauen zu bauen.

📋 Meine persönliche Erfahrung

Ich experimentiere jetzt seit ein paar Wochen mit Skills, und ich bin ehrlich überzeugt. Es begann mit Zeebe und BPMN. Aber schnell ertappte ich mich dabei, auch Skills für andere Domänen zu schreiben: das Erstellen und Testen von GraphQL- oder REST-Controllern, jeweils zugeschnitten auf die spezifische Struktur und die Konventionen des Teams.

Der Output wurde konsistenter, die Qualität besser, und ich verbrachte weniger Zeit damit, Dinge zu korrigieren, die das Modell subtil falsch gemacht hatte. Wichtiger noch: Ich begann, dem Output zu vertrauen—nicht blind, aber genug, um zu reviewen statt neu zu schreiben. Das ist ein echter Wandel in der Arbeitsweise.

Aber die interessantere Veränderung war das, was diese frei gewordene Zeit möglich machte. Ich begann plötzlich, Dinge zu tun, für die ich vorher schlicht keine Zeit gehabt hatte: den Stand unserer ADRs zu prüfen, zu kontrollieren, ob sie tatsächlich befolgt wurden, und die Lücken zu schließen. Ich habe sogar dafür einen Skill geschrieben—und es schneller erledigt, als es sonst gedauert hätte.

Ich denke, dieser Effekt kann in Projekten noch wirkungsvoller sein, in denen Teams hauptsächlich damit beschäftigt sind, das Produkt am Laufen zu halten—erdrückt von Tech Debt, mit wenig Raum für anderes. Die gewonnene Zeit könnte genau das sein, was den Raum schafft, um endlich vor die Lage zu kommen, statt nur hinterherzulaufen.

Was mir persönlich auch immer wieder auffällt: Skills machen es viel schneller, zu experimentieren und zu iterieren. Weniger Reibung zwischen Idee und funktionierender Implementierung bedeutet, dass du mehr validieren, früher auf Basis von Feedback nachjustieren und mehr deiner Zeit auf Dinge verwenden kannst, die echten Mehrwert für Nutzer schaffen—statt nur Tech Debt hinterherzujagen oder den Laden am Laufen zu halten.

Ein gutes Beispiel dafür kommt von einem Kollegen von mir: Er wollte kürzlich MCP als neue Interaktionsebene für ein Produkt testen, das in der Baubranche zur Planung eingehender Aufträge genutzt wird. Die bestehenden Workflows darin—zum Beispiel um einen Kunden zu kontaktieren—waren mühsam: Kundenliste öffnen, suchen, zur Detailseite navigieren, die E-Mail-Adresse kopieren, zum Mail-Client wechseln, die Nachricht schreiben. Mit einem MCP Server, der mit dem Produkt verdrahtet ist, konnte ein AI-Agent das alles übernehmen. Man bittet ihn einfach, die E-Mail des Kunden zu finden und die Nachricht zu entwerfen. Er hat es aus einer bestehenden REST-API-Spezifikation in einer einzigen Session gebaut. Mit einem einfachen Prompt und dem mcp-builder Skill. Von der Idee zum funktionierenden Prototyp in einem Durchgang.

Aber lass uns ehrlich über die Grenzen sprechen.

👨‍💻 Human in the Loop—nach wie vor nicht verhandelbar

Skills sind keine magische Lösung. Die Output-Qualität hängt weiterhin vom Modell ab und davon, wie gut sowohl der Skill als auch dein Prompt geschrieben sind. Vage oder unvollständige Anweisungen führen weiterhin zu Annahmen, und nicht immer zu denen, die du dir wünschst. Und entscheidend: Sie ändern nichts an der Tatsache, dass LLMs von Natur aus nicht-deterministisch sind.

Du solltest daher immer ein paar Praktiken berücksichtigen, auf die es wirklich ankommt:

• Vor dem Weitermachen nachfragen—Ermutige das Modell, bei Unsicherheit Rückfragen zu stellen, bevor es weitermacht. Ohne dieses Signal neigen LLMs dazu, Lücken mit Annahmen zu füllen. Und die sehen oft plausibel aus, bis du den Output reviewst. Eine Rückfrage dauert Sekunden; falsche Implementierungen zu entwirren dauert deutlich länger.
• In Iterationen denken, nicht in Befehlen—Strukturiere komplexe Skills inspiriert von Features wie dem Planning Mode von Claude Code: Das Modell schlägt vor, du reviewst und verfeinerst, dann führt es aus. Dieses Hin und Her deckt Missverständnisse früh auf, bevor sie zu einem Bug oder zu Tech Debt werden.
• Skills als lebende Artefakte behandeln—Wenn ein Skill schlechten Output produziert, fixe den Skill. Jede Korrektur zahlt sich langfristig aus.
• Den Output immer reviewen—Skills verkleinern die Lücke zwischen dem, worum du gebeten hast, und dem, was du bekommst, aber sie schließen sie nicht vollständig. Das Ziel ist, vom Neuschreiben zum Reviewen zu wechseln, nicht vom Reviewen zum blinden Vertrauen.

🪴 Exkurs: Qualitätssicherung jenseits von Skills

Aber Skills allein reichen nicht—besonders im großen Maßstab. Die harte Wahrheit ist, dass man weder der AI noch den Menschen, die sie nutzen (oder selbst Code schreiben—wie langweilig), voll vertrauen kann, dass sie in der Spur bleiben. Und in einer Welt, in der Code schneller denn je generiert werden kann, kann sich Tech Debt genauso schnell anhäufen. Je produktiver dein Team also wird, desto kritischer ist es, die Dinge wartbar zu halten. Einige Guardrails, die helfen, sind daher:

• Quality Gates (z. B. SonarQube)—Wenn Code schneller denn je generiert werden kann, müssen die Qualitätsansprüche mithalten. Erzwinge Schwellenwerte für Testabdeckung und Code-Qualitätsregeln automatisch, bevor irgendetwas auf deinem Main Branch landet.
• Linting und Formatting (z. B. ktlint, Prettier)—Konsistenter Stil ist nicht nur Ästhetik—er hält die Codebase überschaubar und das Onboarding handhabbar, besonders wenn mehrere Leute mit Tempo Code generieren.
• Architektur-Tests (z. B. ArchUnit, Konsist)—Gute Software lebt innerhalb einer Struktur: klare Layer und explizite Abhängigkeiten. Konsistente Patterns, die es leicht machen, sie zu verstehen, zu erweitern und sich darin zurechtzufinden. Diese Entscheidungen sind es wert, dokumentiert zu werden—ADRs sind ein natürlicher Ort dafür. Aber Dokumentation erzwingt sich nicht selbst. Ein Entwickler nimmt eine Abkürzung, eine AI generiert Code, ohne deine Regeln zu kennen—und Layer-Grenzen weichen unbemerkt auf. Automatisierte Architektur-Tests fangen diese Verstöße ab, bevor sie landen—und verhindern kostspielige Refactorings.

Das easy-zeebe-Repo enthält auch funktionierende Beispiele für diese Guardrails—konkret ein Architektur-Test-Setup auf Basis von Konsist—falls du einen konkreten Startpunkt möchtest.

✨ Was möglich wird

Zusammengefasst also: Skills gut zu nutzen ist nicht reibungsfrei. Aber meiner Erfahrung nach ist keine der oben genannten Herausforderungen ein Blocker. Sie sind mit den richtigen Praktiken gut handhabbar. Und sobald sie es sind, wird vieles möglich. Zu den Vorteilen gehören aus meiner Sicht unter anderem:

• AI wird auch dort nutzbar, wo es kaum Trainingsdaten gibt—Skills warten nicht auf bessere Trainingsdaten. Sie liefern direkt, was fehlt—Engine-spezifische Patterns, Constraints und funktionierende Beispiele. Das macht AI-Unterstützung in Nischen-Domänen heute machbar, nicht an irgendeinem undefinierten Punkt in der Zukunft.
• Konsistenterer Output—Dieselbe Aufgabe liefert ähnliche Ergebnisse, weil der Skill Context, Beispiele und Constraints jedes Mal fest verankert. Füge ein Code-Snippet deines Service-Task-Workers hinzu, und nahezu jeder Worker sieht identisch aus. Gleiche Struktur, gleiche Naming Conventions, gleiche Layer-Grenzen.
• Feedback-basiertes Arbeiten statt Raten—Rückfragen bringen Unsicherheit früh an die Oberfläche. Du hast die AI angewiesen, ein Signal an einen Prozess zu senden, und sie weiß nicht, welche API sie nutzen soll? Sie fragt nach—und du klärst es—bevor eine einzige Zeile geschrieben wird. Das Ergebnis: keine halluzinierten API Calls, nur eine schnelle Klärung, die vielleicht ein Rewrite verhindert.
• Mehr Tempo = mehr Fokus auf das Wesentliche—Skills reduzieren die Zeit für repetitive Arbeit erheblich. Worker, Adapter, Tests. All das wird schneller implementiert und fügt sich sauber in deine Architektur ein. Was früher ein paar Stunden dauerte, braucht jetzt vielleicht nur Minuten. Und die zurückgewonnene Zeit fließt in die Arbeit, die tatsächlich menschliches Urteilsvermögen erfordert: Prozessdesign, Domain Modeling und Architekturentscheidungen—Dinge, die nicht wegautomatisiert werden sollten.
• Schnelleres Prototyping—Willst du testen, ob eine neue Fähigkeit—etwa ein MCP Server—echten Mehrwert für deine Nutzer brächte? Ein Skill kann aus deiner bestehenden REST-Spec in einer einzigen Session einen funktionierenden Prototyp generieren. Weniger Reibung zwischen Idee und funktionierendem Prototyp bedeutet, dass du mehr Ideen validieren kannst, und das früher.
• Teilbares Team-Wissen—Skills sind nicht nur für Einzelne—sie sind versionierbare Artefakte, die du in dein Repository committest. Eine Person definiert, wie ein Worker strukturiert sein soll, und das ganze Team erbt es automatisch. Der Hauptvorteil: Der Output bleibt im Team konsistent. Kein Drift pro Person, keine wiederholten Erklärungen. Alle folgen denselben Konventionen, im Einklang mit dem, was ihr gemeinsam vereinbart habt.
• Kumulative Verbesserung—Jede Korrektur, die du vornimmst, kann den Skill verbessern. Ein Skill mit 80 % Genauigkeit heute könnte nächste Woche 85 % erreichen. Und wenn deine Skills geteilt sind, ist diese Verbesserung nicht nur deine—sie gehört dem ganzen Team. Alle profitieren.

🎬 Zum Abschluss

Kurz gesagt: Skills machen deine AI nicht zum perfekten Entwickler. Aber sie können sie zu einem wirklich nützlichen Mitarbeiter machen. Einem, der deine Domäne versteht, deinen Konventionen folgt und Zugriff auf jeden Context hat, den du ihm gibst: Projektdateien, Dokumentation, Live-Daten via MCP und mehr. Er ist dein Kollege und Pair-Programming-Buddy. Sogar in Domänen, in denen das Modell sonst nicht ausreichen würde.

Das Prinzip ist einfach: kodiere, was das Modell nicht weiß, halte einen Menschen im Loop, und lass Guardrails abfangen, was durchrutscht. Wenn du das konsequent machst, summieren sich die Vorteile—konsistenterer Output, schnellere Iteration und ein Team, das mit jedem Durchlauf ein bisschen besser wird.

Für Zeebe und BPMN habe ich eine Reihe von Skills zu easy-zeebe hinzugefügt. Kopier dir gern einzelne Skills oder fork das ganze Repository und pass sie an deine Bedürfnisse an. Wenn du auf Probleme stößt oder Verbesserungsvorschläge hast, öffne ein Issue im Repository. Das hilft, die Sammlung für alle besser zu machen.

Zwei Dinge sind erwähnenswert: Skills sind nicht agent-spezifisch. Da sie ein offener Standard sind, kann jeder Agent, der sie unterstützt, sie nutzen—nicht nur Claude Code. Sie sind auch nicht engine-spezifisch. Tausche die Codebeispiele und Konventionen aus, und derselbe Ansatz funktioniert mit jeder Process Engine. Das Konzept zählt mehr als die konkrete Implementierung.

Über easy-zeebe hinaus würde ich empfehlen, die wachsende Zahl an Skill-Repositories und Marketplaces zu durchstöbern. Die Chance ist gut, dass jemand bereits etwas Nützliches für deine Domäne gebaut hat. Und wenn du Skills kombinierst—deine und ihre—summiert sich der Effekt: Jeder einzelne fügt Context hinzu, auf den sich das Modell stützen kann, was den Output schärfer und zuverlässiger macht.

Und zum Schluss: Hör nicht bei Skills auf—erkunde, was dein Agent sonst noch kann. In Claude Code sind zum Beispiel Sub-Agents ein natürlicher nächster Schritt: isolierte Contexts, in denen das Modell in einer spezialisierten Rolle agiert, angetrieben von einem Skill. Denk an einen Reviewer, der BPMN-Konsistenz prüft, oder einen Architecture Guard, der hexagonale Grenzen verifiziert. Auch damit habe ich experimentiert, und in Kombination mit Skills haben sie noch mehr Produktivität freigesetzt—aber das ist ein Thema für einen anderen Post.

🔭 Was als Nächstes kommt—und worauf ich neugierig bin

Zusammen mit ein paar Kollegen bei Miragon baue ich Skills für Zeebe weiter aus und erkunde denselben Ansatz für andere Process Engines. Die Vision: eine geteilte Skill-Library für die Prozessautomatisierung—versionierbar, iterativ verbessert und teamübergreifend nutzbar. Eine, die allen hilft, schneller voranzukommen, ohne Konsistenz oder Qualität zu opfern.

Und wenn du diesen Ansatz in dein eigenes Team bringen möchtest: Wir bieten dazu auch ein praxisnahes Training an—AI in der Prozessautomatisierung. Entlang des BPM-Lifecycles zeigt es, wie du AI-Agents aufsetzt, Skills für deine Domäne baust und die Guardrails etablierst, die die Qualität hoch halten.

Ich bin neugierig auf deine Erfahrung. Hast du schon versucht, AI-Unterstützung im Kontext der Prozessautomatisierung einzusetzen? Falls ja: Was funktioniert für dich—und was nicht? Gibt es bestimmte Aufgaben, bei denen der Output durchgängig zu kurz greift? Oder bei denen du einen Ansatz gefunden hast, der gut funktioniert?

👉 Schreib gern einen Kommentar oder melde dich!