Agent Skills: Arbeitsabläufe erfahrener Ingenieure als Regeln für KI-Coding-Agenten

Hintergrund und Problemstellung

KI-Coding-Agenten schreiben heute lauffähigen Code. Lauffähiger Code ist aber noch kein auslieferbarer Code. Dasselbe Modell schreibt heute zuerst Tests und überspringt sie morgen. In einer Sitzung prüft es eine Änderung, in der nächsten verzichtet es auf die Prüfung. Die Schwäche liegt nicht in der reinen Leistung, sondern in der Beständigkeit. Niemand hat die Gewohnheiten erfahrener Ingenieure in Regeln verwandelt, die ein Agent jedes Mal einhält.

Das Repository addyosmani/agent-skills zielt genau auf diese Lücke. Es beschreibt sich als produktionsreife Engineering-Skills für KI-Coding-Agenten. Es bündelt Arbeitsabläufe, Qualitätsschranken und bewährte Praktiken erfahrener Ingenieure, damit Agenten ihnen in jeder Entwicklungsphase folgen. Zum Zeitpunkt des Schreibens hat das Repository rund 101.276 Sterne. Zu den Themen zählen agent-skills, claude-code, codex, cursor und antigravity. Das zeigt, dass es auf viele Werkzeuge zielt und nicht auf einen einzelnen Anbieter.

Kernarchitektur und technische Prinzipien

Das Rückgrat ist ein Lebenszyklus mit sechs Stufen: Define, Plan, Build, Verify, Review und Ship. Jeder Stufe ist ein Slash-Befehl zugeordnet: /spec, /plan, /build, /test, /review und /ship. Das README listet insgesamt neun Befehle. Die übrigen drei sind /constraints zum Festlegen der Qualitätslatte, /webperf zur Prüfung der Web-Performance und /code-simplify zum Vereinfachen von Code. Jeder Befehl trägt ein kurzes Leitprinzip. Spezifikation vor Code. Kleine, atomare Aufgaben. Immer nur eine Scheibe. Tests sind Beweise. Die Qualitätslatte einmal festlegen und überall durchsetzen. Klarheit vor Cleverness. Schneller ist sicherer. Die Sätze klingen schlicht, doch jeder wirkt einem bekannten Agentenfehler entgegen: zu große Änderungen, übersprungene Tests, vorzeitige Optimierung.

Die zweite Schicht ist die automatische Aktivierung. Laut README werden Skills abhängig davon aktiv, was man gerade tut. Wer eine API entwirft, löst api-and-interface-design aus. Wer eine Oberfläche baut, löst frontend-ui-engineering aus. Die Befehle sind ausdrückliche Einstiegspunkte, die Skills sind Wissenspakete, die an die Situation gebunden sind. Das Repository enthält 25 Skills. Genannt werden unter anderem code-review-and-quality, eine Prüfung entlang von fünf Achsen vor dem Merge, interview-me, das Anforderungen Frage für Frage abfragt, und test-driven-development, das Rot, Grün, Refactoring erzwingt. Die dritte Schicht ist /build auto. Liegt bereits eine Spezifikation vor, erzeugt der Befehl den Plan und setzt alle Aufgaben in einem einzigen freigegebenen Durchlauf um. Der Mensch genehmigt den Plan einmal. Das README betont, dass dies den menschlichen Schritt zwischen den Aufgaben entfernt, nicht die Verifikation. Jede Aufgabe bleibt testgetrieben und wird einzeln committet, und bei Fehlern oder riskanten Schritten hält der Lauf an. Dieser Entwurf trennt den Grad der Automatisierung von der Stärke der Prüfung. Das ist der bemerkenswerteste Zielkonflikt des Projekts.

Praktische Bewertung und Anwendungen

Die Installation ist kurz. Der allgemeine Weg führt über die offene skills-CLI. Der Befehl npx skills add addyosmani/agent-skills installiert alle 25 Skills. Mit --list lässt sich vorher stöbern, und --skill mit einem Namen installiert nur einen Skill. Laut README erreicht die CLI mehr als 70 Agenten, darunter Claude Code, Cursor, Codex, Copilot und Cline. Nutzer von Claude Code können auch den Plugin-Marktplatz nutzen: erst /plugin marketplace add addyosmani/agent-skills, dann /plugin install agent-skills@addy-agent-skills.

Das README räumt eine echte Falle ein. Eine Installation pro Skill kopiert nur den Skill-Ordner, nicht das Verzeichnis references auf Repository-Ebene. Der Skill läuft weiter, aber Pfade zu gemeinsamen Checklisten gehen ins Leere. Als Umgehung werden eine Integration des ganzen Repositorys, ein Klon oder das Kopieren der benötigten Checkliste in ein references-Verzeichnis im installierten Skill genannt. Die Lücke wird in Issue 361 verfolgt. Einen einzelnen Skill zu installieren, ist also nicht kostenlos.

Eine Grenze muss klar benannt werden. Dieser Beitrag stützt sich auf die Zusammenfassung des README. Wir haben nicht alle 25 Skills vollständig gelesen und keinen kontrollierten Versuch durchgeführt. Wir können nicht beziffern, wie stark die Fehlerrate nach der Einführung sinkt. Der heute sichtbare Wert liegt in der Vollständigkeit des Prozessentwurfs und der leichten Verteilung. Die reale Wirkung hängt davon ab, ob Ihr Agent die Skills tatsächlich befolgt. Jedes Team sollte das in der eigenen Codebasis messen.

Branchenwirkung und Ausblick

Die Bedeutung des Projekts liegt weniger in einem Algorithmus als darin, Ingenieursdisziplin als verteilbares Artefakt zu verpacken. Teamregeln lagen früher in einem Wiki und beruhten auf gutem Willen. Hier liegen sie im Kontext des Agenten und werden durch Slash-Befehle und situative Auslöser durchgesetzt. Mehr als hunderttausend Sterne zeigen, wie stark der Bedarf an Agenten ist, die sich an Regeln halten.

Es zeigt auch einen Trend: Das Skill-Format wächst werkzeugübergreifend zusammen. Dieselben Skills können von Claude Code, Cursor, Codex und anderen gelesen werden, sodass ein Team seine Prozessgüter im Repository hält statt in der Konfiguration eines Anbieters. Drei Punkte verdienen Beobachtung. Wann die Verteilungslücke bei gemeinsamen Referenzen geschlossen wird. Ob die Haltelogik autonomer Modi wie /build auto in echten Projekten früh genug greift. Ob die automatische Auslösung treffsicher bleibt, wenn die Zahl der Skills wächst. Ein Team, das den Einsatz plant, sollte zuerst die ganze Kette von /spec bis /ship an einem kleinen Projekt erproben und dann über eine breitere Einführung entscheiden.