Aufbau einer guten Claude-Agent-Fähigkeit: Lektionen aus einem Projekt mit Laufcoaches
Entwicklung einer Claude Agent Skill, die langlebig ist: präzise Beschreibungen, Bewertungen vor dem Verfassen von Texten, SKILL.md als Leitfaden, Skripte statt Texte sowie eine Berechtigungsabgrenzung in CI.
Quellen: I Missed My Running Goal Three Years Running. So I Built an Agent Skill.
Stellen Sie sich einen Läufer vor, der drei Jahre in Folge das Ziel von 1.000 km setzte und es jedes Mal verfehlte, wodurch er nach drei Jahren insgesamt etwa 2.500 km zurücklegte. Das Problem lag nicht am Einsatzwillen. Es traten Verletzungen, Neustarts sowie beschäftigte Wochen auf. Was fehlte, war ein Plan – schließlich funktioniert die Motivation nur, bis sie plötzlich nicht mehr funktioniert.
Eine Lösung besteht darin, nicht mehr auf den Willen zu setzen, sondern ein System zu entwickeln. So entstand running-coach, eine Claude Agent Skill, die individuelle Läufe sowie ganze Wochen anhand der eigenen Vorgeschichte plant, jede Woche in einen zusammenfassenden E-Mail-Newsletter im redaktionellen Stil umwandelt und sogar eine Playlist entsprechend der Länge des bevorstehenden Laufs zusammenstellt.
Das Laufen ist hier nur der Hintergrund. Das nützlichere Thema ist das, was nötig ist, um eine gute Fähigkeit zu entwickeln – also eine, die zuverlässig ausgelöst wird, den Kontext sparsam nutzt, auf jeder Plattform identisch funktioniert und im Laufe der Zeit nicht an Qualität verliert. Unten wird jede der veröffentlichten Erstellungsmethoden von Anthropic mit der Art und Weise abgeglichen, wie dieses Projekt sie anwendet.
Was eine Agentenfähigkeit ist
Eine Fähigkeit ist ein Ordner. In seinem Wurzelverzeichnis befindet sich eine SKILL.md-Datei, die mit YAML-Frontmatter beginnt, das einen name und eine description enthält, und anschließend mit Anweisungen in Markdown fortgesetzt wird. Referenzdokumente, Skripte, Vorlagen und andere Ressourcen können daneben liegen.
Interessant ist, wie eine Fähigkeit geladen wird, und zwar mithilfe eines dreistufigen Modells namens progressive Disclosure:
- Level 1, Metadaten. Werden immer bei der Startphase geladen, bei etwa 100 Tokens pro Fähigkeit. Sie bestehen nur aus Namen und Beschreibung.
- Level 2, Anweisungen. Werden erst geladen, wenn die Fähigkeit aktiviert wird, und bleiben bei etwa 5.000 Tokens. Dies ist der Inhalt von
SKILL.md. - Level 3, Ressourcen. Werden auf Anfrage über Bash heruntergeladen und bleiben solange verfügbar, bis sie verwendet werden. Referenzdateien, Skripte und Assets befinden sich hier.
Anthropic vergleicht eine Fähigkeit mit einem Einführungsleitfaden für einen neuen Kollegen. Das grundlegende Prinzip hinter allem anderen ist, dass das Kontextfenster gemeinsam genutzt wird – ein öffentliches Gut. Was eine Fähigkeit verbraucht, steht dem Rest dessen, was der Agent im Gedächtnis behalten möchte, nicht mehr zur Verfügung.
1. Die Beschreibung fungiert als API
Auf Ebene 1 sieht das Modell von einer Fähigkeit nur ihre Beschreibung. Sie dient weniger als Dokumentation und eher als Routing-Tabelle, da das Modell einen eingehenden Anfrage gegen sie abgleicht, um zu entscheiden, ob die Fähigkeit aktiviert werden soll. Sie muss sowohl angeben, was die Fähigkeit tut und wann sie verwendet werden soll, in der dritten Person verfasst sein und unter 1.024 Zeichen liegen; ein praktischer Grenzwert von etwa 200 Zeichen gilt, wenn die Beschreibung in Claude.ai’s Picker ungeschnitten angezeigt werden soll. Dies ist die Beschreibung, die running-coach verwendet:
name: running-coach
description: >-
Plans a run or a whole week as Google Calendar blocks, builds a weekly
running digest email, and makes playlists — from Strava, Spotify, AccuWeather
and Calendar. Use for pacing or planning a week.
Betrachten Sie, wie es aufgebaut ist. Es beginnt mit den Funktionen der Fähigkeit (eine Laufplanung erstellen, einen Zusammenfassungstext erstellen, Playlists anlegen), geht anschließend darauf ein, wann man sie nutzen sollte (zum Tempomanagement oder bei der Planung einer Woche), und listet die Datenquellen auf, sodass eine strava-ähnliche Frage auf diese Fähigkeit verlinkt werden kann. Der Name ist in Kleinschreibung und identisch mit dem Verzeichnisnamen – das ist eine strenge Regel und keine stilistische Präferenz, die außerdem durch den Build des Projekts durchgesetzt wird, wie später gezeigt wird.
Ob eine Beschreibung funktioniert, lässt sich im Voraus nicht wissen. Sie muss getestet werden, weshalb das Erste im Repository eine Reihe von Bewertungen und nicht Dokumentation ist.
2. Schreiben Sie zunächst Bewertungen, bevor Sie den Text überarbeiten
Der Rat von Anthropic lautet, zunächst Bewertungen zu erstellen, damit man die tatsächlich vorhandenen Probleme löst und nicht solche, die man sich nur vorstellt. Das Projekt enthält vier Szenariodateien in der Ordnerstruktur evals/ – eine für jede Fähigkeit. Es handelt sich dabei nicht um Unit-Tests, sondern um in Alltagssprache verfasste Verhaltensverträge. Hier ist die Datei zur Planung eines Laufs:
{
"skills": ["running-coach"],
"query": "I'm heading out for 8k this evening, how long is that going to take me?",
"expected_behavior": [
"Triggers the running-coach skill without being named, and routes to the planning capability",
"Reads references/run-planning.md and does not read the digest or playlist references",
"Runs scripts/cache.py status before projecting…",
"Executes scripts/planning/plan_run.py 8 rather than reading its source or reimplementing Riegel inline",
"Reports the projected finish time, the pace, and the recommended effort band…",
"Never asks for or uses a Strava access token"
]
}
Jede Aussage kodiert eine bewährte Vorgehensweise. Das Auslösen ohne Angabe einer benannten Testbeschreibung prüft die Qualität der Beschreibungen. Das Lesen nur der relevanten Referenztests stellt eine schrittweise Offenlegung von Informationen dar. Das Ausführen des Skripts ohne Neuimplementierung überprüft die Präferenz für Skripte gegenüber Prosa. Das Nichtberühren eines Tokens prüft die Grenzen der Berechtigungen. Gemeinsam verwandeln sie die gesamte Designphilosophie in beobachtbares Verhalten, und der Rest des Build-Prozesses dient dazu, sicherzustellen, dass diese Aspekte funktionieren.
3. SKILL.md als Router beibehalten
Die häufigste Art, den Kontextbudget eines Fähigkeitsbereichs aufzubrauchen, besteht darin, alles in SKILL.md zu packen. Ein besseres Vorgehen ist es, diese Datei als Inhaltsverzeichnis zu nutzen, das bei Bedarf auf tiefere Materialien verweist. Halten Sie sie kurz und beschränken Sie die Verweise auf eine Ebene, denn Agenten neigen dazu, tief verschachtelte Dateien nur teilweise zu lesen und am Ende nur ein unvollständiges Bild zu erhalten.
Vier Fähigkeiten hier würden jeweils eine ganze Seite benötigen, um erläutert zu werden, daher erklärt SKILL.md keine davon. Er leitet stattdessen weiter:
| Capability | Reference | Entry point |
| -------------- | -------------------------------- | --------------------------------- |
| Plan a run | references/run-planning.md | scripts/planning/plan_run.py |
| Plan the week | references/week-planning.md | scripts/planning/plan_week.py |
| Weekly digest | references/weekly-digest.md | scripts/digest/run_pipeline.py |
| Run playlist | references/run-playlist.md | scripts/playlist/build_playlist.py|
Work out which one is wanted, then read only that capability's reference.
Fragen Sie nach einer Playlist, und der Agent öffnet run-playlist.md – und nichts anderes. Die Workflow-Spezifikationen des Digests, seine Fallstricke sowie die Anmerkungen zu den Vorlagen kommen niemals in den Kontext, da ungenutzter gebundener Inhalt nichts kostet. Level 2 bleibt schlank, und Level 3 liefert genau eine Datei. Die Zeile „liest X, liest nicht Y“ in der Auswertung überprüft genau das.
4. Skripte statt Prosa: Führen Sie sie aus, lesen Sie sie nicht
Das könnte die wertvollste Idee bei der Gestaltung von Fähigkeiten sein. Wenn der Agent ein Skript über bash ausführt, gelangt nur die Ausgabe in den Kontext, niemals der Quellcode. Vorausgeschriebene Skripte sind außerdem zuverlässiger als Code, der spontan erstellt wird, und liefern jedes Mal das gleiche Ergebnis.
Daher befindet sich die Logik von running-coach in Python, und die Anweisungen weisen den Agenten ausdrücklich an, den Quellcode unberührt zu lassen:
**Run the scripts, don't read them.** They print everything needed; every one
takes --help and most take --json. Reading their source wastes context.
Die Prognose der Zielzeit mit Riegel, die Berechnung des Anstrengungsbandes sowie die Zusammenfassungsanalyse laufen alle mit deterministischem Python und liefern eine kompakte Antwort. Der Agent koordiniert den Ablauf und rechnet nicht erneut. Vergleichen Sie einen Agenten, der über Ihr Tempo entscheidet – welches langsam, variabel und ressourcenintensiv ist – mit einem, der einen Tempoberechner verwendet und die Zahl ausgibt; dieser ist schneller und liefert jedes Mal dasselbe Ergebnis.
5. Jedes Skript ist eine ordentliche CLI mit gemeinsamen Konventionen
Damit das Prinzip „Ausführen, nicht lesen“ funktioniert, muss der Agent ein Skript steuern, das er nicht öffnen darf. Dafür ist eine einheitliche, selbstbeschreibende Schnittstelle erforderlich, sodass jedes Skript denselben Konventionen folgt:
- einen Positionalargument für alles, was immer erforderlich ist (Entfernung für Planung und Playlists);
--data DIRüberall, damit jedes Skript auf einen anderen Cache verweisen kann, was das Offline-Testing sowie Sandboxes pro Sitzung ermöglicht;--jsonin fast allen Fällen, sodass die Ausgabe eines Skripts der nächsten Ausgabe als Eingabe dienen kann;--helpin jedem Fall – die Rückfallmöglichkeit des Agents, wenn er sich bei einem Parameter unsicher ist. Er liest den Hilfetext, was kostengünstig ist, und nicht die Quelle, die teuer und unzugänglich ist.
Hier ist die Übersicht, Fähigkeit für Fähigkeit.
Planning a run verwendet plan_run.py:
python3 scripts/planning/plan_run.py 8 # 8 km, defaults
python3 scripts/planning/plan_run.py 8 --band steady # force an effort band
python3 scripts/planning/plan_run.py 8 --start-in 3 # start 3h from now (weather-aware)
python3 scripts/planning/plan_run.py 8 --json # machine-readable plan
Der einzige erforderliche Parameter ist distance_km. Optional sind die Flags --exp, das den Ermüdungsexponenten von Riegeln anpasst, sowie --band, das einen bestimmten Anstrengungsbereich vorschreibt. Ohne spezifische Angaben wird der Anstrengungsbereich aus der bisherigen Trainingsbelastung des Läufers abgeleitet. Der heuristische Teil bietet Freiheit, während die genaue Prognose deterministisch bleibt.
Die Playlist wird von build_playlist.py verarbeitet, welches absichtlich die Struktur des Planers nachahmt:
python3 scripts/playlist/build_playlist.py 8 # size to the 8 km finish
python3 scripts/playlist/build_playlist.py 8 --genre "lo-fi"
python3 scripts/playlist/build_playlist.py 8 --minutes 55 # size by time instead
python3 scripts/playlist/build_playlist.py 8 --band hard
Weil beide die gleiche räumliche Entfernung einnehmen, ergänzen sich die beiden Funktionen: Die Endzeit, die von plan_run berechnet wird, entspricht der Dauer, für die build_playlist die Playlist erstellt. Das Skript gibt einen Prompt aus und nicht eine Playlist, und der Agent übermittelt diesen Prompt an den Spotify-Connector. Auch hier zeigt sich die Trennung der Aufgaben: Das Skript führt Rechenoperationen durch, während der Agent für Eingabe/Ausgabe zuständig ist.
Die wöchentliche Zusammenfassung ist ein kleiner Pipeline und kein Monolith. run_pipeline.py prüft den Cache und führt anschließend zwei Phasen aus:
python3 scripts/digest/run_pipeline.py # validate → analyse → render
python3 scripts/digest/run_pipeline.py --plan-km 8 # lead the digest with a planned run
python3 scripts/digest/run_pipeline.py --seed 3 # pin the masthead title choice
python3 scripts/digest/run_pipeline.py --skip-validate # skip the pre-flight cache check
Unterhalb davon aggregiert analyze.py die im Cache gespeicherte Woche in eine Datei digest_data.json, und build_email.py wandelt diese JSON-Datei in eine eigenständige HTML-E-Mail um. Die Trennung der Analyse von der Darstellung bedeutet, dass die E-Mail ohne Beeinflussung der Analyse neu gestaltet werden kann, und ein --seed-Flag sorgt dafür, dass die einzige zufällige Auswahl – der Titel des Masthead – reproduzierbar ist, was nützlich ist, um dieselbe Woche zweimal als Screenshot zu erstellen.
Planning the week ist die interessanteste CLI, da es sich um einen Pipeline-Prozess aus Planung, Überprüfung und Ausführung handelt, der als Unterbefehle dargestellt wird, die der Agent nacheinander durchläuft:
python3 scripts/planning/plan_week.py goal # show the weekly goal in force
python3 scripts/planning/plan_week.py propose # propose the split of runs (as JSON)
python3 scripts/planning/plan_week.py draft --split - # lay the split across the days
python3 scripts/planning/plan_week.py brief --draft - # hand the agent a per-run contract
python3 scripts/planning/plan_week.py events --draft - --content - # emit calendar blocks
Jede Phase gibt JSON aus, das von der nächsten Phase über stdin verarbeitet wird. Wo angebracht, akzeptieren die Phasen auch gängige Überschreibungsparameter (--km, --runs) sowie Planungsoptionen wie --start-date, --time, --weekend-time, --location und --tz. Die Richtlinien empfehlen diese Form von „überprüfbaren Zwischenergebnissen“ für anfällige Aufgaben: Der Agent schreibt niemals freiwillig einen Zeitplan. Er gibt einen strukturierten Plan aus, der Skript prüft und ihn formt, und erst danach werden daraus Kalendereinträge.
Zwischenzeitlich findet ein gezieltes Übergabeprozess statt. In der brief-Phase berechnet das Skript Entfernung, Zeitrahmen und Tag und gibt dem Agenten anschließend einen Vertrag für jede Aufgabe. Der Agent schreibt die menschenähnlichen Formulierungen hinein, sodass keine zwei Beschreibungen identisch aussehen. Das Skript ist für das Verantwortliche verantwortlich, während das Modell für das Natürliche sorgt. Geringe Freiheit bei empfindlichen mathematischen Berechnungen und hohe Freiheit bei Prosa – das ist das Prinzip der „angemessenen Freiheitsgrade“ in einem einzigen Befehl.
6. Lösen Sie Probleme, ignorieren Sie sie nicht
Eine schwache Skill-Definition überlässt schwierige Fälle dem Agenten mit vagen Anweisungen wie „Wenn die Daten veraltet erscheinen, finden Sie eine Lösung.“ Anthropics Vorgabe lautet, Probleme zu lösen und nicht abzutun: Behandeln Sie Fehlerbedingungen im Skript und delegieren Sie sie nicht. running-coach setzt dies durch ein Frische-Modell um. Für jede gespeicherte Datenmenge wird das Alter aufgezeichnet, und status gibt den genauen MCP-Aufruf an, der jede Lücke schließen würde:
python3 scripts/cache.py status # what's cached, how stale, what to call
python3 scripts/cache.py put streams --file - # ingest an MCP response from stdin
python3 scripts/cache.py show week --json # a compact summary, not the raw blob
python3 scripts/cache.py validate --for digest # shape-check before a run
cache.py verfügt über vier Funktionen (status, put, show, validate), von denen jede eine Stufe in der Aktualisierungsabfolge darstellt. status listet jeden Schlüssel zusammen mit seinem Frischheitsbudget auf – für die aktuelle Woche ist dieses Budget begrenzt, da es bei jedem Aufruf ändert sich, während für abgeschlossene Wochen sowie Athletendaten ein wöchentliches Budget gilt. Bei veralteten oder fehlenden Daten gibt die Funktion an, welches spezifische MCP-Tool aufgerufen werden soll. Der Agent führt diesen Aufruf durch und leitet die Antwort direkt an put weiter. Anschließend überprüft validate --for <capability>, ob das Ergebnis vor dem Ausführen eines nachfolgenden Skripts nutzbar ist; so wird ein fehlerhafter Abruf bereits dort mit einem Fehler gestoppt, anstatt später als fehlerhafter Zusammenfassung sichtbar zu werden.
Weitere Schutzmaßnahmen: put akzeptiert nur Schlüssel aus einer festgelegten Erlaubnisliste, show gibt eine Zusammenfassung aus, nicht das rohe JSON, sodass das Überprüfen des Caches keine Megabyte an GPS-Daten in den Kontext ausgibt, und der Agent wird angewiesen, diese JSON-Dateien nicht manuell zu bearbeiten. Das Ergebnis ist, dass der Agent nicht entscheiden muss, ob er neu abrufen soll oder was er abrufen soll, denn das Skript gibt dies vor. Ein ungenaues Urteil (“Ist das früh genug?”) wird zu einer deterministischen Anweisung – genau das meint eval, wenn es vor dem Projektieren cache.py status ausführt.
7. Die Bereichsgrenze der Zugangsdaten
Das ist die zentrale architektonische Entscheidung und zugleich eine Sicherheitspraxis: Überprüfung auf unerwartete Netzwerkaufrufe und Dateizugriffsmuster. Die Technologie macht diese Überprüfung durch ihre Konstruktion trivial, da nichts darin Zugangsdaten enthält oder Sockets öffnet.
agent --(Strava / Spotify / AccuWeather MCP)--> cache.py put --> the cache
the cache --> plan_run.py / run_pipeline.py / build_playlist.py --> output
Nur der Agent kommuniziert mit den MCP-Connectoren, und ausschließlich cache.py schreibt den Cache. Alle übrigen Skripte verarbeiten lediglich den im Cache gespeicherten Daten offline – es gibt keinen HTTP-Client, keine API-Schlüssel und keine Zugriffstoken in dem Paket.
# cache.py — the only gateway to the running-coach data cache.
# The agent is the only thing that talks to MCP; this script is the only thing
# that reads or writes the cache. Nothing here needs an access token.
Drei Vorteile ergeben sich daraus. Was Sicherheit angeht, gibt es nichts zu leaken, und die zu prüfende Netzwerkschnittstelle ist leer. Was Portabilität betrifft, ist es für die Fähigkeit unerheblich, ob Verbindungen lokal, entfernt oder fehlen, da sie lediglich einen Cache nutzt. Was Testbarkeit angeht, ermöglicht ein gefüllter Cache es jedem nachgelagerten Skript, vollständig offline ausgeführt zu werden – genau das macht einen Smoke-Test in CI möglich.
8. Eine Laufzeitanforderung: Python 3.10
Fähigkeiten werden nicht über verschiedene Netzwerkschnittstellen synchronisiert, und jede Schnittstelle hat ihre eigenen Laufzeitbeschränkungen. Die Claude API bietet weder Netzwerkzugang noch die Installation von Laufzeitpaketen, während Claude Code alles bereitstellt. Um eine Fähigkeit überall ausführen zu können, muss man sich am restriktivsten möglichen Umfeld orientieren.
Deshalb zieht running-coach keine externen Ressourcen heran. Es gibt weder ein requirements.txt noch ein virtualenv sowie keine Installierungsphase. In den Anweisungen steht, dass Python 3.10 oder neuer ausreicht, und python3 funktioniert bereits so, wie er ist – selbst in einer gehosteten Sandbox, in der das Installieren von Paketen nicht möglich ist.
Alles, was für diese Fähigkeit benötigt wird, befindet sich im Verzeichnis skills/running-coach/. Wenn man dieses Verzeichnis in ~/.claude/skills/ ablegt, steht es Claude Code zur Verfügung, während ein als ZIP hochgeladenes Archiv bei Cowork oder claude.ai genutzt werden kann – mit identischem Verhalten. Überall werden Schrägstriche als Trennzeichen verwendet, wodurch ein häufiges Problem zwischen verschiedenen Betriebssystemen vermieden wird. Cache- und Ausgabedateien werden an einen Ort außerhalb des Skill-Verzeichnisses gespeichert, sodass die installierte Kopie nur für Lesen zugänglich ist, und sie werden niemals in git eingefügt, da der Cache echte GPS-Polylinien enthält, die zu Routen umwandelt werden, die bei jemandem vor der Haustür beginnen.
9. Verpackungsprüfungen und CI, die die Angaben bestätigen
Die Verpackung ist der Schritt, den viele überspringen. Eine falsch installierte Fähigkeit zeigt sich auf unklare Weise als defekt: Ein Archiv mit losen Dateien in der Wurzel wird beim Hochladen stillschweigend abgelehnt. Deshalb enthält das Projekt package.py, einen Validator ohne Abhängigkeiten, der die in Anthropics eigenem Fähigkeits-Repository vorhandenen Prüfungen wiederholt. Er überprüft die zulässigen Frontmatter-Schlüssel, einen name im Kebab-Case, der mit dem Verzeichnis übereinstimmt, die Länge der Beschreibung innerhalb der Spezifikationen (mit einer Warnung bei der von claude.ai vorgegebenen Grenze von etwa 200 Zeichen) sowie ein Archiv, das genau ein oberes Verzeichnis mit SKILL.md in der Wurzel enthält.
GitHub Actions stellt anschließend jede Veröffentlichung anhand dieser Prüfungen frei. Wenn ein v*-Tag hochgeladen wird, führt der Workflow Folgendes aus:
- byte-compiliert jeden Skript (
python -m compileall) zur Erkennung von Syntaxfehlern; - überprüft das Frontmatter gegen die Spezifikation;
- führt jeden Eingangspunkt mit
--helpaus, wodurch zumindest gezeigt wird, dass jedes Skript unter Verwendung einer sauberen Python 3.10 importiert und analysiert wird; - stellt sicher, dass
running-coach/SKILL.mdsich im Wurzelverzeichnis des Archivs befindet; - und erst nach all dem wird das ZIP-Archiv veröffentlicht.
# 3.10 is the version the skill claims to support, so building on it is
# also how that claim stays honest.
- uses: actions/setup-python@v5
with:
python-version: "3.10"
Allgemeingültige Lektionen
Mehrere Punkte heben sich bei der Umsetzung hervor:
Eine Beschreibung umfasst etwa 100 Tokens, die 90 % der Arbeit leisten. Da dies der einzige Teil ist, der stets geladen wird, macht ein Versagen bei der Aktivierung alles andere irrelevant. Schenken Sie dieser Beschreibung besondere Aufmerksamkeit und fügen Sie Tests hinzu, die die Aktivierung überprüfen, ohne die Fähigkeit namentlich zu erwähnen.
Verlagern Sie die Logik von Anweisungen in deterministische Skripte. Der von dem Agenten gelesene Text variiert und verbraucht Tokens, während ein von ihm ausgeführtes Skript günstig ist und jedes Mal dasselbe Ergebnis liefert. Das Motto lautet: Ausführen statt Lesen.
Vertrauen Sie auf Grenzen, die man in einem Satz beschreiben kann. „Nur der Agent spricht mit MCP, ein Skript schreibt den Cache, alles andere ist offline“ ist wertvoller als Haufen an defensivem Code, da ganze Klassen von Fehlern und Datenlecks strukturell unmöglich werden.
Lassen Sie die Build-Verfahren Ihre Angaben überprüfen. Eine Fähigkeit, die Python 3.10 sowie keine Abhängigkeiten verspricht, sollte bei jeder Veröffentlichung genau auf diese Weise im CI gebaut werden. Ohne das bleibt das Versprechen nur eine Hoffnung.
Das ursprüngliche Ziel bleibt weiterhin offen, doch es gibt nun einen „Coach“, der die Woche plant, am Montagmorgen eine ehrliche Einschätzung abgibt und jedes Wochenende das Ziel anhand der zurückgelegten Strecke neu berechnet. Sobald das Laufen als solches technisches Problem betrachtet wurde, wurde es zu einem lösbaren Problem.
Jeder, der eine solche Fähigkeit installiert, benötigt die Aktivierung der Codeausführung sowie seinen eigenen Strava-Connector, da die Fähigkeit keine Anmeldeinformationen enthält. Dasselbe gilt für die Quellen, die man lesen sollte: Die Übersicht zu Agent Skills von Anthropic sowie deren Seite mit Best Practices für die Erstellung von Fähigkeiten – beides auf den Dokumenten der Claude Platform.
Weitere Literatur
- Gemini Spark erklärt: Aufgaben, Fähigkeiten, Zeitpläne, Sicherheit und Preise — Was das rund um die Uhr verfügbare Gemini Spark-Agent von Google in Gmail, Kalender und Docs leistet, wie seine Sicherheitsschichten funktionieren, wie viel es kostet, wo es blockiert ist und wer es nutzen sollte.
- Advanced RAG in der Produktion: Architektur, Tools und Kompromisse — Ein Überblick über RAG in der Produktion: Eingabe, Parsing, Aufteilung in Blöcke, Embeddings, Vektorlagern, hybride Suche, Neubewertung, Bewertung und Sicherheit sowie die jeweiligen Kompromisse.