17 Punkte von GN⁺ 2025-10-17 | 4 Kommentare | Auf WhatsApp teilen
  • Agent Skills von Anthropic ermöglichen es, die Fachkompetenz von KI passend zum Arbeitsablauf der Nutzer zu erweitern
  • Ein Skill ist eine ordnerbasierte Komponente mit Anweisungen, Skripten und Ressourcen, die Claude nur dann lädt, wenn sie für eine Aufgabe benötigt wird
  • Sie verleihen auf bestimmte Arbeitsbereiche spezialisierte Fähigkeiten, etwa zum Erstellen von Excel- und PowerPoint-Dateien oder zur Einhaltung von Markenrichtlinien
  • Nutzer und Entwickler können Skills selbst erstellen und in der Claude-App, Claude Code und über die API hinweg nutzen
  • Funktionen für unternehmensweite Bereitstellung und Verwaltung sind ebenfalls geplant und sollen die Grundlage für den Aufbau maßgeschneiderter KI-Workflows bilden

Überblick über Skills und ihre Funktionsweise

  • Mit der Funktion Agent Skills kann Claude mit angepassten Skills ausgestattet werden, damit es bestimmte Aufgaben besser ausführt
  • Skills werden in Form von Ordnern mit Anweisungen, Skripten und Ressourcen bereitgestellt, und Claude greift nur darauf zu, wenn eine passende Aufgabe ansteht
  • Dadurch lässt sich Claude für verschiedenste spezialisierte Tätigkeiten deutlich wirkungsvoller einsetzen, etwa für die Verwaltung von Excel-Dokumenten oder die Einhaltung organisatorischer Brand-Guidelines
  • Nutzer können benutzerdefinierte Skills erstellen und sie durchgängig in der Claude-App, in Claude Code und über die API verwenden

So funktionieren Skills

  • Claude verfügt über einen Algorithmus, der während der Aufgabenausführung alle verfügbaren Skills durchsucht und den relevantesten findet
  • Wenn ein passender Skill vorhanden ist, werden nur die minimal nötigen Informationen und Dateien geladen, um Geschwindigkeit zu erhalten und zugleich spezialisierte Aufgaben ausführen zu können
  • Eigenschaften von Skills
    • Kombinierbarkeit: Mehrere Skills können wie ein Stack zusammen verwendet werden, und Claude stimmt die benötigten Skills automatisch aufeinander ab
    • Portabilität: Sie sind im gleichen Format verfasst und können in der gesamten Claude-Produktfamilie verwendet werden
    • Effizienz: Es werden nur die Funktionen geladen, die zum jeweiligen Zeitpunkt benötigt werden
    • Leistungsfähigkeit: Auch ausführbarer Code (z. B. Python, Shell) kann enthalten sein, sodass sich die Effizienz klassischer Programmierung nutzen lässt
  • Skills sind als maßgeschneidertes Onboarding-Material zu verstehen, das das Fachwissen einer Organisation für Claude paketiert und so aufbereitet, dass Claude in einem bestimmten Bereich die Rolle eines Experten übernehmen kann

Integration mit Claude-Produkten

Claude Apps

  • Pro-, Max-, Team- und Enterprise-Nutzer können die Skills-Funktion verwenden
  • Standardmäßig werden verschiedene Beispiel-Skills für allgemeine Aufgaben wie das Verfassen von Dokumenten bereitgestellt; sie lassen sich auch direkt anpassen
  • Nutzer geben ihre Aufgabe ein, und Claude lädt automatisch den passenden Skill; das Verhalten der Skills ist auch in der Chain of Thought nachvollziehbar
  • Mit dem Skill skill-creator wird die einfache Erstellung von Skills per interaktiver Anleitung unterstützt, einschließlich Workflow-Abfragen, Erzeugung der Ordnerstruktur, automatischer Formatierung von SKILL.md und Bündelung von Ressourcen
  • Bei Team/Enterprise muss ein Administrator die Funktion auf Organisationsebene aktivieren
  • Verfügbar auf der Einstellungsseite

Claude Developer Platform (API)

  • Über Requests an die Messages API und den neuen Endpoint /v1/skills sind Versionsverwaltung und Betriebssteuerung benutzerdefinierter Skills möglich
  • Für die Nutzung von Skills ist die Beta-Funktion Code Execution Tool erforderlich, die eine sichere Umgebung für die Codeausführung bereitstellt
  • Mit von Anthropic bereitgestellten Skills lassen sich Dokumente in Excel, PowerPoint, Word und PDF auf Expertenniveau erstellen und bearbeiten
  • Entwickler können benutzerdefinierte Skills für bestimmte Workflows erstellen und den Einsatz von Claude frei erweitern
  • Die Claude Console unterstützt die einfache Erstellung, Anzeige und Aktualisierung von Skill-Versionen
  • Weiterführende Informationen finden sich in der Dokumentation und bei Anthropic Academy

Praxisbeispiele von Partnern

  • Box: Wandelt gespeicherte Inhalte automatisch um und erstellt daraus PowerPoint-, Excel- und Word-Dokumente; unterstützt automatisierte Dokumentation gemäß Organisationsstandards
  • Notion: Wandelt komplexe Fragen sofort in ausführbare Aufgaben um und reduziert den Aufwand für Prompt-Anpassungen
  • Canva: Nutzt Skills zur Anpassung von Agenten für Design-Automatisierung und hochwertige Content-Produktion im Team
  • Rakuten: Nutzt Skills für Automatisierung in Finanzen und Buchhaltung, verarbeitet mehrere Tabellen gemeinsam und verkürzt die Zeit zur Berichtserstellung von 1 Tag auf 1 Stunde

Integration mit Claude Code

  • Claude Code unterstützt die Installation von Skills, um Team-Expertise und Workflows zu erweitern
    • Möglich über das Marketplace-Plugin-Modell anthropics/skills oder durch direktes Hinzufügen eines Ordners unter ~/.claude/skills
  • Funktionen zum Teilen und zur Zusammenarbeit an Skills zwischen Teams werden durch die Integration mit Versionsverwaltungssystemen bereitgestellt
  • Auch die Entwicklung benutzerdefinierter Agenten wird über das Claude Agent SDK unterstützt

Erste Schritte


Ausblick und Hinweise

  • Künftig sollen der Erstellungsprozess für Skills vereinfacht und Funktionen für die organisationsweite Bereitstellung ausgebaut werden
  • Da Skills Claude die Ausführung von Code erlauben, sollten nur Skills aus vertrauenswürdigen Quellen verwendet werden
  • Auf Datenschutz und Sicherheit ist zu achten; weitere Details finden sich in diesem Hinweisdokument

4 Kommentare

 
ahwjdekf 2025-10-21

Eine Kartoffel kann man backen, kochen, anbraten, schmoren, pürieren ...

 
ahwjdekf 2025-10-21

Jedes Mal werden alle möglichen schicken Namen draufgeklebt. Am Ende schmeckt doch alles nach Kartoffeln.

 
GN⁺ 2025-10-17
Hacker-News-Kommentare
  • Es wird wohl ähnlich wie früher in der Frontend-Entwicklung ziemlich viel begriffliche Verwirrung rund um ChatGPT, Claude und Co. geben. Jetzt werden wir von Begriffen wie Tools, Funktionen, Skills, Agents, Sub-Agents, Befehlen, Apps usw. überschwemmt, und auf diesem Chaos wachsen immer mehr allerlei „Vibe“-Frameworks.

    • Die MCP-bezogenen Funktionen darf man auch nicht vergessen. Ja, es ist tatsächlich chaotisch, aber darunter gibt es grundlegende Konzepte, die leicht zu lernen sind. Selbst wenn neue Funktionen hinzukommen, lassen sie sich leicht in das mentale Modell einordnen — oder man ignoriert sie einfach komplett und baut seine Tools direkt selbst. Dieses grundlegende mentale Modell besteht darin, ein LLM in einer Schleife aufzurufen, dabei die Historie dessen, was in der Session passiert ist (= Kontext), fortlaufend zu speichern und Tool-Aufrufe wie Dateilesen, Schreiben oder Bash-Aufrufe zu ermöglichen. Das wird auch „Agent Loop“ genannt und lässt sich sogar mit 100 Zeilen Python umsetzen. Wenn man als Entwickler an LLMs interessiert ist, sollte man das unbedingt einmal selbst bauen. Das ist wirklich ein erhellendes Erlebnis. Wenn man einmal selbst einen einfachen Agenten gebaut hat, kann man bei neuen Tools leicht aus Implementierungssicht erklären, wie sie funktionieren. Claude Skills bestehen zum Beispiel aus 1) mehreren Dateien mit Anweisungen für das LLM, 2) beim Start werden nur die verfügbaren Skills überflogen und nur kurze Beschreibungen in den Kontext des LLM aufgenommen, 3) dem LLM wird erklärt, wie es die Skills nutzen soll, und bei Claude wird dafür das bash-Tool verwendet, 4) wenn ein Skill tatsächlich genutzt wird, wird per „call bash“ die Datei eingelesen und die Aufgabe ausgeführt. Wichtige Details wie Berechtigungsverwaltung lasse ich hier natürlich aus, aber die Kernstruktur ist so.
    • Das Ökosystem ist inzwischen so komplex geworden, dass es fast an seinem eigenen Gewicht zusammenbrechen könnte. Jedes System oder jede Plattform hat so etwas wie ein Gesamtbudget an Komplexität, das Menschen im Alltag überhaupt behalten können, und entscheidend ist, wofür man dieses Budget ausgibt. Wenn ein Plattformanbieter neue Komplexität hinzufügt, geht das von dem Wert ab, den man auf der Plattform aufbauen kann. In letzter Zeit fügen Anbieter zur Differenzierung wahllos Komplexität hinzu, erhöhen damit aber letztlich nur die Hürde für die eigentliche Zielgruppe und schmälern den echten Mehrwert, der auf der Plattform entstehen könnte. Schon jetzt scheinen viele sich überschneidende ähnliche Konzepte dieses neue Komplexitätsbudget aufzufressen, ohne viel echte Zusatzfunktionalität zu bringen. Intern kann man sich leicht einreden: „Wenn wir diese Funktion hinzufügen, wird es leichter zu lernen“, aber in Wirklichkeit gewinnt man damit vielleicht genauso viele Leute, wie man wieder verliert.
    • Weil das eine komplett neue Technologie ist, gibt es noch sehr viele unbekannte Bereiche. Ähnliche Probleme gab es auch bei der Auswahl von Cloud-Tools oder Python-Bibliotheken. Deshalb ist eben auch nicht jeder ein Early Adopter. Allein das alles zu verfolgen, kostet mental ziemlich viel.
    • Die Kernschleife ist einfach, aber ein minimales Framework, das freies Experimentieren mit solchen imperativen Konzepten erlaubt, ist wirklich wertvoll. Ich mochte, dass ich Beads direkt an mein Framework anhängen konnte und es einfach weiterbenutze, wenn es taugt, oder wieder entferne, wenn nicht. Auch so etwas wie toolkami ist einen Blick wert.
    • „Metastasizing“ beschreibt dieses Phänomen wirklich gut: Es lagert sich endlos auf bestehende Konzepte auf.
  • Ich habe gerade selbst etwas über Skills geschrieben: „Claude Skills sind wirklich cool — vielleicht sogar eine größere Veränderung als MCP“ Link zum Artikel

    • Findet ihr auch, dass sich Skills und AGENTS.md teilweise überschneiden? VSCode hat kürzlich ebenfalls experimentelle Unterstützung für verschachtelte AGENTS.md-Dateien eingeführt; weniger formal, aber konzeptionell könnte es sich überschneiden. VSCode-Update-Link
    • Skills wirken weniger wie etwas, das unbedingt in eine harte Spezifikation gehört, sondern eher wie ein Design-Pattern oder ein Prompt-Engineering-Trick. Eigentlich ließ sich das auch schon innerhalb von MCP umsetzen. Ich habe es bisher in der Form genutzt: „Bevor du irgendetwas beginnst, suche im Skills-MCP und lies den relevanten Guide.“
    • Ich frage mich, ab wann man etwas als Skill behandeln sollte und ab wann es eher ein eigenes Projekt werden muss.
  • Ich glaube, dass die Fähigkeit solcher Systeme, Probleme gut zu lösen, vor allem von den zusammenfassenden Texten in den Skills abhängt. Menschen lernen mit wachsender Erfahrung, wann welcher Skill einzusetzen ist, aber Claude liest jedes Mal nur oberflächlich die Erklärung und fängt dann wieder von vorne an.

    • Anders als Menschen, die durch Erfahrung zu geübten Skill-Nutzern werden, kann ein LLM nur imitieren. Deshalb glaubt Richard Sutton, dass LLMs sich nicht zu AGI weiterentwickeln werden. Laut Sutton wird AGI aus Reinforcement Learning kommen, während LLMs (neuronale Netze) nur nachahmen können. Ein LLM besitzt nicht die kognitive Grundlage aus Zielen und den Folgen von Handlungen; deshalb ist ein „Skill“ bei LLMs eher ein Referenzhandbuch als ein echter Skill, der sich wiederholt auf Aufgaben, Werkzeuge oder Lösungsentwicklung anwenden lässt. Sutton-Video
    • Letztlich ist das ein Problem des Kontextfensters. Menschen behalten einen enorm breiten Kontext, wenn auch ungenau, im Gedächtnis; wenn sie aber über 10.000 Stunden in einem bestimmten Bereich investieren und ihn meistern, erinnern sie sich an diese „Technik“ gut und vergessen den Rest. Ein LLM kann programmatisch Kontext konsistent speichern und perfekt wieder aufrufen, aber den gesamten Kontext immer erneut durchzugehen, ist zu teuer und zu langsam. Deshalb sind Skills — genauer gesagt Context Insertion — eine manuelle Steuerung der Ausgabeprioritäten. Auch der Denkmodus eines LLMs ist letztlich eine Neujustierung des Kontexts. Es muss also nicht unbedingt „jedes Mal von vorne“ sein. Mit dieser Sichtweise wird der Umgang mit Tools viel einfacher.
    • Ich frage mich, ob dieses ständige Neustarten bei LLMs an einer Multi-Tenant-Infrastruktur liegt. Es ist nachvollziehbar, dass OpenAI oder Anthropic Server und Speicher über viele Nutzer hinweg wiederverwenden wollen. Vielleicht wäre ein „persönliches“ Single-Tenant-Setup möglich, bei dem das LLM sich an alle vergangenen Unterhaltungen erinnert.
    • Der Schlüssel dazu, Wissen und Tools in einem LLM reichhaltig aufzubauen, besteht darin, das LLM erkennen zu lassen, was wann benutzt werden soll — und genau das ist im Moment fast unmöglich.
    • Der Großteil der Erfahrung besteht aus allgemeinem Wissen und nicht aus projekt- oder gesprächsbezogenen Informationen. Ein LLM sollte mit diesem Wissen starten und danach separat nur projektspezifische Informationen speichern und abrufen können. Menschen rufen Informationen extrem schnell ab, aber auch ein LLM könnte sie, selbst wenn etwas langsamer, fast in Echtzeit referenzieren.
  • Es ist ziemlich ironisch, dass Claudes „Skills“ nur dann wirklich funktionieren, wenn Entwickler ordentliche Dokumentation schreiben und pflegen. Viele Entwickler schaffen nicht einmal eine gepflegte Code-Dokumentation, daher dürfte Dokumentation für LLMs noch schwieriger sein. Für eine kleine Gruppe von Entwicklern mit extrem aufgeräumtem Dateisystem und hoher Risikobereitschaft mag das sinnvoll sein, aber wenn jemand ohnehin so gut organisiert ist, wäre es vielleicht besser, solche Nebenaufgaben einem Junior als Lernaufgabe zu geben, statt sie dem LLM zu überlassen. Schließlich muss man die Ergebnisse am Ende sowieso vollständig prüfen. Wegen der begrenzten Kontextfenster ist es außerdem schwer, wirklich das Gefühl umzusetzen, dass ein „Skill“ wie bei Menschen verinnerlicht wird. Wenn man dafür spezielle LLM-Trainings macht, ist man am Ende lebenslang an genau dieses LLM gebunden. Insgesamt wirkt diese ganze Annahme von „im Idealfall stehen intern alle Sterne perfekt“ irgendwie amüsant.

    • Dass LLMs gute Entwicklerdokumentation und die in diesem Artikel beschriebenen verschiedenen Infrastrukturbausteine für professionelle Entwickler brauchen, ist tatsächlich eine nützliche Motivation. Das hilft sogar dabei, das Management zu überzeugen.
    • LLMs belohnen Entwickler, die gut schreiben können, stärker — vielleicht ist das auch ein Grund, warum manche Entwickler LLMs ablehnen.
    • Ich bin auch wegen der Kommentare gekommen, aber anscheinend bist du der Einzige, der diesen Punkt anspricht. „Skills“ sind letztlich einfach detaillierte Dokumentation, und in der Praxis habe ich so etwas für einzelne Projekte fast nie geschrieben. Es wäre schön, wenn LLM-Skills alle Entwickler dazu bringen würden, wirklich ausführliche Dokumentation zu schreiben, aber ich glaube nicht, dass das wahrscheinlich ist.
  • Ich frage mich, wie Sub-Agents, MCP, Skills usw. miteinander interagieren werden. Es fühlt sich so an, als gäbe es ziemlich viele Überschneidungen. Es ist grundsätzlich okay, Claude durch Spezifikations-Upgrades zusätzliche Fähigkeiten zu geben, aber in der Praxis lässt sich Agent-Funktionalität ohnehin auf ähnliche Weise umsetzen. In MCP brauchte man bisher JSON, bei Claude reicht jetzt Markdown in Dateien oder Ordnern, und auch multimodale Eingaben sind möglich — die UX scheint also deutlich besser geworden zu sein.

    • Claude Skills sehen für mich einfach exakt wie MCP-Prompts aus. MCP-Prompt-Spezifikation Ich verstehe nicht, warum man dafür überhaupt ein neues Konzept geschaffen hat. Im Chat-UI ist das marketingtechnisch noch nachvollziehbar, aber bei Claude Code? Es gibt doch schon CLAUDE.md.
    • Ich finde, die drei ergänzen sich eigentlich ganz gut. MCP kapselt APIs so, dass ein LLM-Agent sie nutzen kann. Skills geben dem Agenten nur bei Bedarf zusätzliche Anweisungen auf kontexteffiziente Weise, und einige Anweisungen können auch die Nutzung von MCP erklären. Sub-Agents sind wieder ein anderes Muster der Kontextverwaltung: Ein übergeordneter Agent schickt einem untergeordneten Agenten eine Mission, und falls nötig, lassen sich dabei Skills und MCP gemeinsam nutzen, um Tokens zu sparen.
  • Dass solche Funktionen hinzukommen, ist ziemlich erfrischend. In meinem Projekt habe ich einen eigenen Unterordner bin/claude erstellt, in den Claude erzeugte Skripte und Ähnliches ablegt, und in claude.md ist dieser Pfad sauber dokumentiert, sodass er für die Tool-Suche genutzt werden kann. In der Praxis hat das ziemlich gut funktioniert. Was man eigentlich braucht, sind Helfer für Kontextverwaltung — etwa „Starte Claude mit diesem MCP-Set und wechsle dann zu jenem MCP-Set“ — aber derzeit verwalte ich dafür pro Projekt separate Unterverzeichnisse (Profile) und starte dort jeweils einmal claude. In dieser Struktur erfüllt bin/claude eine wichtige Rolle: Claude versteht dadurch sofort Dinge wie die Analyse bestimmter BigQuery-Datasets oder den Speicherort von Authentifizierungsdateien. Ich hätte nie gedacht, dass ich das Dateisystem einmal für Profilverwaltung nutzen würde, aber genau so verwende ich es jetzt.

    • Wenn du von „Helfern für Kontextverwaltung“ sprichst, klingt das für mich eigentlich genau nach Sub-Agents.
  • Ich verstehe nicht, warum man in solchen Demos so simple Beispiele wie das Drehen oder Zuschneiden von Hundefotos genommen hat. Es gäbe doch viel überzeugendere Beispiele für den Einsatz von Skills.

    • Auf der Entwicklerseite gibt es ein deutlich besseres Beispiel zur PDF-Verarbeitung. PDF-Skill-Dokumentation Tatsächlich hatte ich in Claude Code bisher schon Markdown-Dateien mit Benutzungsanweisungen per @-Tag eingebunden; jetzt ist das automatisiert und damit noch besser.
    • Der Wikipedia-Artikel "The purpose of a system is what it does" ist in diesem Zusammenhang einen Gedanken wert.
    • Die Dokumentation enthält auch Lösungen für zwei Probleme, auf die ich heute Morgen in Claude beim Erzeugen von .xlsx-Dateien gestoßen bin. Beispiel für einen Excel-Skill
    • Das Beispiel mit dem Hundefoto ist letztlich nur als leicht verständliche Referenz für Endverbraucher gedacht.
  • Es fühlt sich so an, als würde sich Claude-Skills extrem schnell verbreiten. Mich hatte am Dienstag schon der Artikel über „Superpowers“ Einführungsartikel gepackt, und ich habe die Tools, die ich bislang gebaut hatte, sauber aufbereitet und als Skills verpackt, die ich dem Agenten übergeben kann. Feedback zu deli-gator Open Source ist willkommen.

    • Die Delegationsfunktion an Agents ist wirklich attraktiv. Beim Linear-Issue-Kontext kommt oft viel zu viel hinein; eigentlich möchte ich zum Beispiel nur die Issue-Beschreibung und den letzten Kommentar, aber Linear MCP holt alle Kommentare und verschmutzt dadurch den Kontext.
  • Letzten Freitag hatte ich versehentlich schon die Existenz von Claude Skills verraten, daher bin ich froh, dass es jetzt offiziell ist. Zugehöriger Blogpost

    • Wenn man „eine neue Claude-Instanz startet und sie per Prompt bittet, den gesamten Ordner /mnt/skills als ZIP-Datei zu erzeugen“, dann funktioniert das tatsächlich. Es ist zugleich faszinierend und beängstigend, dass so ein Hack real geworden ist. Hoffentlich gibt es keinen Zugriff auf das komplette Dateisystem oder auf Binärdateien — und wenn sogar SSH ginge ...
    • Jesses Blog ist in letzter Zeit wirklich extrem aktiv geworden, dafür bin ich dankbar.
  • Es gibt inzwischen so viele Dinge wie Skills, Plugins, Marktplätze, Connectoren, Add-ons usw., dass man kaum noch hinterherkommt.

    • Meiner Meinung nach muss man das gar nicht alles verfolgen. Ähnlich wie „Best Practices“ im Prompt Engineering sind das oft nur Übergangslösungen, um vorübergehende Beschränkungen zu umgehen. Man muss dafür nicht unbedingt Zeit investieren, bis die wirklich nötige Leistung standardmäßig in den Basismodellen enthalten ist. In ein paar Monaten wird vieles davon ohnehin verschwunden sein, deshalb lohnt sich Aufmerksamkeit nur dann, wenn die Leistung akut gebraucht wird.
    • Man sollte schon verstehen, warum das passiert. Aus Sicht der Unternehmen müssen sie eben irgendetwas hervorbringen, während das Hauptprodukt sein Versprechen vom „Zeitalter der Massenarbeitslosigkeit“ noch nicht eingelöst hat. Das ist weniger ein Signal an Nutzer als an Investoren: „Wir zahlen nicht nur Forschergehälter und tun sonst nichts, sondern bauen auch verschiedene Produkte und fahren Daten durch die Systeme.“ Mit der riesigen A/B-Test-Basis sowieso.
    • Aus Nutzersicht ist es eher nachteilig, je mehr anbieterspezifische Funktionen hinzukommen: Man muss mehr lernen, mehr konfigurieren, und der Vendor Lock-in wird stärker. Aber für die Modellanbieter ist genau das eine Möglichkeit, Produktdifferenzierung aufrechtzuerhalten. Ohne solche Funktionen würden ihre Produkte schnell zur Commodity.
    • Neue Funktionen wird es wohl weiter geben, bis die Stimmung in den Teams wieder steigt.
    • Eigentlich finde ich das gar nicht so kompliziert. Zu Plugins gehören Befehle, MCPs, Sub-Agents und jetzt eben auch Skills. Ein Marktplatz ist einfach der Ort, an dem solche Plugins gesammelt werden.