Der vorherige Beitrag hat die Formel aufgestellt: Agent = Modell + Harness. Alles an einem KI-Agenten, was nicht das Modell ist (die Schleife, die Tools, der Speicher, die Verifikation), ist Harness. Diese Sichtweise hilft, kann aber abstrakt wirken, wenn Sie nicht gerade selbst Agenten-Infrastruktur von Grund auf bauen.
Ein Teil des Harness kommt ohne Infrastruktur-Code aus. Sie müssen dafür weder die Agenten-Schleife ändern noch Middleware implementieren oder Sandboxes deployen. Sie schreiben eine Markdown-Datei.
Dieser Teil sind die Skills.
Was ein Skill ist
Ein Skill ist ein gebündelter Satz von Anweisungen, der in den Kontext eines Agenten eingespeist wird, sobald er relevant ist. In der einfachsten Form ist das eine SKILL.md-Datei: YAML-Frontmatter, das beschreibt, wann der Skill zum Einsatz kommt, gefolgt von Markdown-Anweisungen, an die sich der Agent hält, wenn der Skill ausgelöst wird.
---
name: code-review
description: Reviews code for quality, maintainability, and common mistakes.
---
When reviewing code, always:
1. Check for logic that could be simplified
2. Identify missing error handling
3. Flag violations of the project's coding conventions
4. Run tests before presenting results
Das ist ein Skill. Er liegt in einem Verzeichnis, der Agent entdeckt ihn, und er taucht auf, wenn der Kontext passt. Dazu brauchen Sie keine API, kein Schema und kein Deployment, nur einen Ordner und eine Markdown-Datei.
Claude Code, DeepAgents, Codex und immer mehr Agenten-Harnesses unterstützen dasselbe Muster. Anthropic hat es als offenen Standard Agent Skills formalisiert, und das Format funktioniert in Claude Code, Cursor, Gemini CLI und anderen. Das Ökosystem umfasst inzwischen tausende Skills aus der Community, die alles abdecken, von Sicherheits-Audits über Architekturdiagramme bis zu Deployment-Checklisten.
Wo Skills im Harness sitzen
In Birgitta Böckelers Harness-Engineering-Framework sind Skills Guides: Feedforward-Kontrollen, die den Agenten steuern, bevor er handelt. Sie erhöhen die Wahrscheinlichkeit, dass der Agent es beim ersten Versuch richtig macht, statt Fehler erst im Nachhinein abzufangen.
Skills sind aber mehr als statisch eingefügter Text. Die interessante Designentscheidung ist, wann sie auftauchen.
Der naive Ansatz lädt beim Sitzungsstart jeden Skill in den System-Prompt. Das verschwendet Kontext. Wenn Sie dreißig Skills haben und der Agent für die aktuelle Aufgabe nur einen braucht, haben Sie Token für neunundzwanzig irrelevante Anweisungssätze verbrannt und zugleich das Risiko erhöht, dass der Agent Anweisungen durcheinanderbringt, die nichts miteinander zu tun haben.
Besser ist Progressive Disclosure. LangChains SkillsMiddleware setzt das explizit um: Beim Start landen nur die Metadaten der Skills (Name, Beschreibung) im Prompt. Erkennt der Agent eine Aufgabe, die zu einem Skill passt, liest er die vollständige SKILL.md und alle zugehörigen Dateien. Der Rest bleibt auf der Festplatte und verbraucht null Token.
Claude Code macht etwas Ähnliches. Skills lassen sich explizit über Slash-Commands aufrufen (/code-review) oder werden automatisch ausgelöst, wenn der Agent eine passende Aufgabe erkennt. Der Agent liest die SKILL.md im Moment der Verwendung aus dem Dateisystem und holt ihre Anweisungen bei Bedarf ins Kontextfenster.
Das ist kein kosmetischer Unterschied. Es ist eine Entscheidung im Context Engineering. Kontext ist die knappste Ressource in einem Agentensystem, und Skills, die ihren eigenen Kontext-Fußabdruck verwalten, sind grundsätzlich nützlicher als Skills, die dauerhaft Platz belegen.
Was einen guten Skill ausmacht
Aus der Community schält sich ein klares Muster heraus: Die besten Skills halten Domänenwissen fest, das das Modell nicht hat und nicht erschließen kann.
Ein Skill, der sagt „schreibe sauberen Code“, bringt nichts, denn das versucht das Modell ohnehin. Ein Skill, der sagt „in diesem Projekt müssen alle Datenbankmigrationen abwärtskompatibel sein, in die Phasen Add-Column und Make-Non-Nullable aufgeteilt und vor dem Merge gegen das Staging-Schema getestet werden“, hält institutionelles Wissen fest, das kein Modell hat. Genau die Lücke zwischen allgemeiner Fähigkeit und projektspezifischer Korrektheit füllen Skills.
Die stärksten Skill-Kategorien sind wiederkehrende Workflows (Deployment-Checklisten, Code-Review-Durchgänge, PR-Vorlagen), architektonische Vorgaben (Modulgrenzen, Abhängigkeitsregeln, API-Konventionen), werkzeugspezifisches Wissen (wie Ihr Team Datadog nutzt, wie Ihre CI-Pipeline funktioniert, was Ihre Monitoring-Alerts bedeuten) und Ausgabeformate (wie Diagramme aussehen sollen, wie Dokumentation aufgebaut sein soll, was in eine Commit-Nachricht gehört).
All das hat eines gemeinsam: Ein Senior Engineer weiß es aus Erfahrung, einem neuen Teammitglied müsste man es sagen. Skills sind der Mechanismus, mit dem man es dem Agenten sagt.
Skills als Einstieg ins Harness Engineering
Das ist der Punkt, auf den es für die meisten ankommt, die zum ersten Mal von Harnesses lesen.
Die Literatur zum Harness Engineering (Böckelers Guides-und-Sensoren-Framework, LangChains Middleware-Architektur, Anthropics Muster aus Initialisierer und Coding-Agent) beschreibt Arbeit auf Infrastrukturebene. System-Prompts, Middleware-Hooks, Compaction-Strategien, Verifikations-Pipelines. Alles wertvoll, alles mit Engineering-Aufwand verbunden.
Skills umgehen diese Hürde. Eine SKILL.md-Datei zu schreiben ist näher am Schreiben von Dokumentation als am Bau von Infrastruktur. Wenn Sie beschreiben können, wie eine Aufgabe zu erledigen ist, Schritt für Schritt und mit dem richtigen Grad an Genauigkeit, können Sie einen Skill bauen. Entdeckung, Einspeisung und Ausführung übernimmt der Harness.
Damit sind Skills die zugänglichste Form von Harness Engineering. Sie ändern nicht die Agenten-Schleife und schreiben keine Middleware. Sie halten Domänenwissen in einem Format fest, das der Agent verarbeiten kann, und die vorhandene Harness-Maschinerie erledigt den Rest.
Die Reihenfolge ergibt sich von selbst: Beginnen Sie mit Skills (festhalten, was der Agent wissen soll), ergänzen Sie dann rechnerische Sensoren (Linter, Tests, Strukturprüfungen, die die Ausgabe des Agenten verifizieren), und denken Sie danach über inferenzielle Kontrollen (Review-Agenten, LLM-as-Judge) und Anpassungen der Middleware nach. Jeder Schritt bringt mehr Fähigkeiten. Der erste Schritt, die Skills, verlangt nur eine Markdown-Datei und ein klares Verständnis davon, was der Agent wissen muss und noch nicht weiß.
Das tiefere Muster
Skills machen etwas explizit, das in der Softwareentwicklung immer schon galt: Am schwersten weiterzugeben ist nicht technisches, sondern institutionelles Wissen. Wie dieses Team arbeitet. Warum jene Architekturentscheidung gefallen ist. Was beim letzten Mal kaputtging, als jemand den naheliegenden Weg versucht hat.
Senior Engineers tragen dieses Wissen implizit mit sich. Sie wenden es an, ohne darüber nachzudenken, und können es oft gar nicht in Worte fassen. Junior Engineers erwerben es langsam, über Monate hinweg durch Code-Reviews, Produktionsvorfälle und Flurgespräche.
Skills sind der Mechanismus, der dieses Wissen explizit und maschinenlesbar macht. Nicht als Dokumentation, die Menschen lesen und manchmal befolgen, sondern als Anweisungen, die ein Agent liest und zuverlässig ausführt. Der Agent vergisst nichts, überspringt keine Schritte und beschließt nicht, dass die Checkliste diesmal nicht gilt.
Dieser Perspektivwechsel von „das sollte ich aufschreiben“ zu „das sollte ich als Skill schreiben“ ist die kleinstmögliche Verschiebung mit dem größtmöglichen Hebel auf die Qualität des Agenten. Das Modell ist für alle dasselbe. Die Skills gehören Ihnen.
Aus dem Englischen übersetzt: zum Originalbeitrag