Agent Skills

• Agent Skills sind ein offenes Format, um KI-Agenten neue Funktionen und Fachwissen hinzuzufügen
• Nach der Entwicklung durch Anthropic als offener Standard veröffentlicht und inzwischen von verschiedenen Agentenprodukten übernommen
• Skills sind als Ordner aufgebaut, die aus Anweisungen, Skripten und Ressourcen bestehen, die der Agent durchsucht, um Aufgaben präziser und effizienter auszuführen
• Unterstützt Domänenexpertise, Erweiterung um neue Funktionen, wiederholbare Workflows und Interoperabilität
• Unternehmen und Entwickler können damit Organisationswissen wiederverwenden und die Verteilung automatisieren

---

Überblick

• Agent Skills ist ein einfaches und offenes Format, um Agenten neue Fähigkeiten und Fachwissen zu verleihen
• Jeder Skill besteht aus einem Ordner mit Anweisungen, Skripten und Ressourcen, den der Agent laden kann, um die Genauigkeit und Effizienz bei Aufgaben zu erhöhen

Warum Agent Skills?

• Agenten werden immer leistungsfähiger, doch für eine stabile Ausführung realer Arbeitsaufgaben fehlt oft Kontextinformation
• Skills stellen prozedurales Wissen sowie Kontext auf Organisations-, Team- oder Benutzerebene bereit, der bei Bedarf geladen werden kann
• Agenten mit Skills können ihre Fähigkeiten je nach Aufgabe erweitern
• Skill-Autoren können einmal entwickelte Funktionen in mehrere Agentenprodukte ausrollen
• Kompatible Agenten ermöglichen es Nutzern, sofort neue Funktionen hinzuzufügen
• Teams und Unternehmen können Organisationswissen als versionsverwaltbare portable Pakete bewahren

Was mit Agent Skills möglich ist

• Domänenexpertise: Spezialisiertes Wissen wie Rechtsprüfung oder Datenanalyse als wiederverwendbare Anweisungen paketieren
• Neue Funktionen: Verschiedene Fähigkeiten wie Präsentationserstellung, Aufbau eines MCP-Servers oder Datensatzanalyse hinzufügen
• Wiederholbare Workflows: Mehrstufige Aufgaben in konsistente und auditierbare Prozesse verwandeln
• Interoperabilität: Dieselben Skills in mehreren kompatiblen Agentenprodukten wiederverwenden

Stand der Einführung

• Agent Skills werden von mehreren KI-Entwicklungstools unterstützt
• Beispiele sind Factory.ai, Gemini CLI, Mux, Ampcode, Letta, Autohand.ai, Spring AI, Goose, Piebald.ai, OpenAI Codex, Cursor, Databricks, Mistral Vibe, Roocode, VS Code, Agentman.ai, Trae.ai, Commandcode.ai, Firebender, Opencode.ai und Claude.ai

Offene Entwicklung

• Das Agent-Skills-Format wurde zunächst von Anthropic entwickelt und als offener Standard veröffentlicht
• Inzwischen wird es von verschiedenen Agentenprodukten übernommen und erlaubt Beiträge aus dem gesamten Ökosystem
• Über das GitHub-Repository lassen sich das Format und Beispiel-Skills einsehen

Erste Schritte

• Auf der Seite „What are skills?“ kann man die Struktur und Funktionsweise von Skills kennenlernen
• Unter „Specification“ findet sich die Formatspezifikation der Datei SKILL.md
• Mit „Integrate skills“ lässt sich Skill-Unterstützung zu Agenten oder Tools hinzufügen
• Auf GitHub lassen sich Beispiel-Skills und die Referenzbibliothek erkunden

[cgl00]

Es gibt doch ein offizielles Repository von Anthropic – warum wird so ein Projekt dann von Dritten entwickelt?

[skageektp]

Agent Skills ist ein offenes Format, das von Anthropic gepflegt wird und für Beiträge aus der Community offen ist.

Dann hat Anthropic also den Standard geschaffen.

[cgl00]

Das ist hier wohl auch offiziell … Ist das dann wohl etwas anderes als https://github.com/anthropics/skills?

[skageektp]

Ja, das, was Sie geschickt haben, ist die Implementierung.
Das, was im Haupttext geteilt wurde, ist die Spezifikation.

So ähnlich wie
der Standard von so etwas wie Docker = OCI
Docker, Podman = Container-Runtimes, die OCI implementieren

(Kann auch falsch sein)

[cgl00]

Ah, also sind das Spezifikation und Implementierung … danke.

[GN⁺]

Hacker-News-Kommentare

• Diese Diskussion beginnt mit der Frage nach der Notwendigkeit von Standardisierung
  Ich denke, der Kern guter Dokumentation ist nach wie vor, dass sie „für Menschen leicht lesbar geschrieben“ ist. Ich frage mich, ob es wirklich einen Grund gibt, ein neues Format zu erzwingen. Wenn der Produktivitätsgewinn real ist, sollte sich das durch Vergleichsstudien belegen lassen

  • Zusätzlich zu dem, was andere gesagt haben, eröffnet Standardisierung aus meiner Sicht auch Möglichkeiten für Training und RL
  • Tatsächlich gab es einen Vergleichstest. Ein Hugging-Face-Mitarbeiter soll das Modell Qwen3-0.6B mit codex + skills feinabgestimmt haben, worauf sich der humaneval-Score um +6 verbessert habe. Der Link dazu ist hier, und das Projekt liegt unter huggingface/upskill
  • Das System ist nicht bloß einfache Dokumentation, sondern erstellt einen Index aller skills und übergibt ihn dem LLM bei jeder Unterhaltung. So liest das LLM einen skill nur dann, wenn es ihn braucht. Das ist ein ähnliches Konzept wie die Auffindbarkeit von Funktionen in einer GUI. Ich persönlich halte eine README-zentrierte Struktur für intuitiver
  • Ich automatisiere meine Arbeit mit Claude Code und habe jede Aufgabe über Slash-Befehle verknüpft. Am Ende fühlen sich skills für mich auch nur wie eine andere Form von Dokumentation an. Langfristig glaube ich, dass das skills-Paradigma mit größeren Context Windows und intelligenteren Modellen verschwinden wird
  • Wenn man jedoch von den aktuellen Modellen ausgeht, liest Claude oft nur bis zur skill-Beschreibung und hält dann an, weshalb der Token-Spar-Effekt groß ist. In großen Repositories ist dieser Unterschied deutlich spürbar. Es lohnt sich, dieses Muster bekannter zu machen

• Unser Team war erfolgreich damit, skills wie wiederverwendbare quasi-deterministische Funktionen zu behandeln
  Zum Beispiel enthält der Skill /create-new-endpoint sämtliches Boilerplate wie OpenAPI-Updates, das Hinzufügen von Integrationstests usw. Wenn man in der CLI eine JIRA-Ticketnummer eingibt, erledigt das LLM die Aufgabe mit konsistenter Qualität

  • Jemand fragte: „Wie testet ihr die Konsistenz über längere Zeit hinweg?“

• Es gab einen Vorschlag, die Ordnerstruktur zu standardisieren

  .claude/skills
  .codex/skills
  .opencode/skills
  .github/skills
  

  • Zwar ist das noch kein Standard, aber die meisten CLI-Tools scannen .md-Dateien und führen sie aus. Trotzdem wäre eine integrierte Standardisierung einschließlich Plugins wünschenswert
  • Angeblich hat Codex damit angefangen, und OpenCode zog direkt nach. Zugehöriger Tweet
  • Diese Diskussion läuft auch unter agentskills/agentskills#15
  • Jemand meinte, „es sei noch zu früh, und Standardisierung könnte die Kreativität einschränken“
  • Eine andere Person argumentierte, es sei besser, der XDG Base Spec zu folgen und Pfade wie ~/.config/claude zu verwenden. Das aktuelle ~/.claude-Schema sei unpraktisch

• Es gab den Tipp, in jedem Unterordner eine README.md anzulegen und auf passende skills zu verlinken. Das sei auch für Menschen nützlich. Der zugehörige Artikel ist Claude Skills Considered Harmful

  • Es kam die Meinung auf, dass „skills letztlich nur READMEs zu einem bestimmten Thema sind“. Inhalte, die man immer wieder erklären muss, könne man als skill organisieren. Man müsse dabei nicht einmal einem Standardordner folgen, sondern könne sie bei Bedarf direkt dem Context hinzufügen
  • Eine weitere Person sagte, ein Command Runner wie just helfe sowohl Menschen als auch Agenten

• Für mich war es effektiv, skills als explizite Workflows zu behandeln
  Wenn man sie als abgeschlossene Verfahren definiert, etwa „mache X, dann Y und validiere Z“, erkennt der Agent das als einen zusammenhängenden Modus. Dagegen werden vage Richtlinien leicht ignoriert

  • Jemand sagte, er habe in Claude ein Hook-System angewendet, das in bestimmten Situationen einen skill automatisch aktiviert. Wenn etwa mit Python-Dateien gearbeitet wird, wird der passende skill automatisch geladen
  • Eine andere Person wies darauf hin, dass der Unterschied zwischen skill und command unklar sei. Wenn letztlich beides wie Befehle verwendet werde, stelle sich die Frage, ob diese Trennung überhaupt nötig sei
  • Jemand meinte, diese Struktur erinnere an Obsidian-Notizen oder eine Sammlung von CLI-Befehlen
  • Eine andere Person betonte, man müsse die Aktivierungsbedingungen eines skill sehr klar beschreiben. In Claude Code sei ein expliziter Aufruf wie /foo möglich, weshalb diese Methode bevorzugt werde

• Jemand sah in skills eine Möglichkeit, implizites Domänenwissen zu dokumentieren. Regeln, die bisher nur in den Köpfen der Entwickler existierten, könnten festgehalten und später für LLM-Training wiederverwendet werden

• Es kam die Frage auf: „Verwendet der Agent skills nicht, wenn man ihn nicht ausdrücklich dazu auffordert?“

  • Viele andere haben offenbar dasselbe Problem. Aktuelle Modelle seien nicht per RLVR auf skills-basiertes Verhalten trainiert und würden deshalb durcheinandergeraten. Von der nächsten Modellgeneration (z. B. Opus) werde erwartet, dass sie skills deutlich stabiler nutzt
  • Auch in den Evaluierungen von Vercel wurde berichtet, dass in 56 % der Fälle kein skill aufgerufen wurde. Stattdessen habe sich der AGENTS.md-Ansatz in einem breiteren Bereich als wirksamer erwiesen. Zugehöriger Blogpost
  • Jemand, der Codex verwendet, sagte, es funktioniere ziemlich gut, wenn man in AGENTS.md das skill-Verzeichnis explizit angebe. Wenn jedoch die Zahl der skills steige, nehme auch die Wahrscheinlichkeit von Konflikten zu, daher solle man es einfach halten
  • Eine andere Person sagte, sie habe skills fast gar nicht sinnvoll einsetzen können; es sei genauer gewesen, den Inhalt der skills direkt in AGENTS.md einzutragen

• Bei skills.sh sei der drittbeliebteste skill bloß ein Download-Link für einen Befehl gewesen. Solche Dateien wie SKILLS.md/AGENTS.md/COMMANDS.md seien letztlich nur Sammlungen von Prompts und könnten gefährlich sein, wenn man sie falsch nutze

  • Darauf erwiderte jemand, am Ende komme es bei Werkzeugen auf die verantwortungsvolle Nutzung an

• Jemand, der eine neue Programmiersprache entwickelt, sagte, er nutze AGENTS.md und SKILLS, damit LLMs eine Sprache verstehen, auf die sie nicht trainiert wurden. Dank Standardisierung sei die Tool-Integration einfacher geworden

• Der eigentliche Wert liegt nicht im Format, sondern in der schrittweisen Offenlegung (progressive disclosure)
  Wenn man alle Anweisungen in ein einziges Dokument packt, verschwendet man unnötig Tokens. Das skills-Muster sorgt dafür, dass Details nur dann geladen werden, wenn sie wirklich benötigt werden. Standardisierung dient vor allem der Verteilung und Wiederverwendung

  • Dazu erklärte der Entwickler des MOOLLM-Projekts, er habe das Konzept in Form einer „Semantic Image Pyramid“ erweitert.
    GLANCE.yml → CARD.yml → SKILL.md → README.md beschreibt eine schrittweise Verfeinerung.
    GLANCE umfasst 5–70 Zeilen und entscheidet nur „Ist das relevant?“, CARD definiert die Schnittstelle, SKILL enthält das eigentliche Verfahren, README die Erklärung für Menschen.
    INDEX.md erreiche gegenüber INDEX.yml eine um mehr als 80 % höhere Kompressionsrate und liefere zugleich eine narrative Struktur.
    Zugehörige Links: INDEX.yml, INDEX.md
    Außerdem ermögliche die sniffable-python-Struktur, die API zu erfassen, indem man nur die ersten 50 Zeilen des Codes liest.
    Weiterführende Materialien: Erklärung zur Semantic Image Pyramid, sister-script, sniffable-python README, sniffable-python SKILL