Eine Skill ist ein Ordner. skills.sh legt ihn nur hin.

Ich klebe dieselbe Checkliste in jedes Chatfenster. Wie ein Pull Request hier aussehen soll. Wann der Agent aufhören muss, statt «fertig» zu sagen. Wie auf dieser Site ein Blogpost gebaut wird. AGENTS.md ist schon lang — und wird mit jeder Ausnahme länger.

Genau dafür sind Skills da. Und skills.sh ist der Teil, der sie findet und hinlegt.

Die kurze Antwort

Eine Skill ist ein Ordner mit einer Datei namens SKILL.md. Darin steht, was der Agent tun soll und wann. Optional liegen Skripte, Referenztexte und Vorlagen daneben. Der Agent sieht zuerst nur Name und Beschreibung. Den Rest lädt er, wenn die Aufgabe dazu passt.

skills.sh ist das öffentliche Verzeichnis und das CLI dazu, betrieben von Vercel. Das Format kommt von Anthropic und liegt offen unter agentskills.io. Die Website ist nicht die Spezifikation. Das CLI ist nicht der Agent.

Installieren:

npx skills add vercel-labs/agent-skills

Das CLI erkennt, welche Agenten du lokal hast — und legt die Ordner dort hin, wo sie sie erwarten: .claude/skills/ bei Claude Code, .agents/skills/ bei Cursor und so weiter. Standard ist das aktuelle Projekt. Mit -g landet die Skill in deinem Home-Verzeichnis und gilt überall.

Die offizielle Doku ist skills.sh/docs, das CLI liegt auf GitHub. Was folgt, ist die Fassung, die ich selbst gern gehabt hätte: was eine Skill von MCP und von AGENTS.md unterscheidet, wie du eine findest, ohne dem Leaderboard zu glauben — und die Stellen, an denen sie lautlos nicht greift.

Drei Namen, eine Verwechslung

Agent Skills ist der Ordner. YAML-Frontmatter mit name und description, darunter Markdown. Das ist die Spezifikation. Ein Agent, der sie spricht, kann denselben Ordner lesen — Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI und Dutzende mehr. Die aktuelle Liste steht im CLI-README.

skills.sh ist npm für diese Ordner. Die Site zeigt, was Leute installieren. Das CLI (npx skills) kopiert oder verlinkt sie in den Pfad, den dein Agent kennt. Ohne CLI kannst du denselben Ordner von Hand hinlegen. Ohne die Site kannst du das CLI trotzdem nutzen. Beides ist unabhängig vom Format.

Der lokale Pfad ist, wo dein Agent sucht. Eine Skill, die in ~/.claude/skills/ liegt, sieht Cursor nicht. Eine, die nur in .agents/skills/ liegt, sieht Claude Code nicht. Das CLI nimmt dir das Verdrahten ab — wenn du ihm sagst, für welchen Agenten.

Wer «Skills» googelt, landet mal bei Anthropic, mal bei Vercel, mal bei einem Leaderboard voller Install-Zahlen. Es sind drei Schichten. Nur die erste ist die Fähigkeit. Die anderen zwei transportieren sie.

Skill, MCP oder AGENTS.md

Drei Mechanismen, die Leute in denselben Topf werfen:

AGENTS.md und CLAUDE.md sind immer an. Fakten über das Repo, Konventionen, Dinge, die in jeder Session stimmen müssen. Wird die Datei zum Verfahren — Checkliste, mehrstufiger Ablauf, «lies zuerst X, dann Y» — gehört das in eine Skill. Die Beschreibung kostet ein paar Tokens. Der Rest lädt nur, wenn die Aufgabe passt.

Eine Skill ist Verfahrenswissen. Wann handeln, in welcher Reihenfolge, woran merkst du, dass du fertig bist, welche Fallen es gibt. Sie kann Skripte mitbringen, die der Agent ausführt, statt sie jedes Mal neu zu schreiben.

MCP hängt Werkzeuge an: APIs, Datenbanken, den Browser. Der Agent kann dann etwas aufrufen. Eine Skill sagt ihm, wann und wie. Beides ergänzt sich. Ein Browser-MCP ohne Skill klickt irgendwo. Eine Skill ohne Werkzeug beschreibt Schritte, die der Agent nicht gehen kann.

Faustregel: steht es in jeder Session, gehört es nach AGENTS.md. Wiederholst du dasselbe Verfahren, wird es eine Skill. Braucht der Agent eine externe Schnittstelle, ist das MCP.

Eine Skill installieren

Du brauchst Node, damit npx da ist — und mindestens einen Agenten, den das CLI kennt. Dann reicht die Kurzform owner/repo:

npx skills add vercel-labs/agent-skills

Das ist das Beispiel aus der offiziellen Doku. Es klont das Repo, sucht darin nach SKILL.md und fragt, welche Skills und welche Agenten. Für CI oder wenn du die Fragen nicht willst:

npx skills add vercel-labs/agent-skills --skill frontend-design -a claude-code -y

--skill nimmt einen Namen, oder '*' für alle. -a zielt auf einen Agenten (claude-code, cursor, codex, …). -g schreibt nach ~/ statt ins Projekt. --copy kopiert statt zu verlinken; Symlinks sind die Empfehlung, weil ein Update dann eine Quelle hat.

Es muss kein GitHub-Kürzel sein. Volle GitHub-URL, GitLab, beliebige Git-URL, ein lokaler Pfad, sogar eine direkte SKILL.md oder ein Archiv. Private Repos nutzen die Anmeldung, die Git schon hat — kein extra Token, ausser du setzt GITHUB_TOKEN bewusst.

Nach dem Lauf:

npx skills list

In Claude Code sollte der Ordner unter .claude/skills/<name>/ liegen, bei Cursor unter .agents/skills/. Tippe / und such den Namen, oder stell eine Frage, die zur description passt. Wenn nichts passiert: YAML prüfen, Pfad prüfen, Agent neu starten. Das CLI loggt den Zielpfad; rate nicht.

Eine Skill nutzen, ohne sie zu installieren:

npx skills use vercel-labs/agent-skills@web-design-guidelines | claude

Das schreibt die Dateien in ein Temp-Verzeichnis und druckt einen Prompt. Mit --agent startet das CLI den Agenten gleich. Sinnvoll zum Testen. Für etwas, das du behalten willst, lieber add.

Teams können auf skills.sh ein Pack schnüren: mehrere Skills, auch private, eine Install-URL der Form npx skills add https://skills.sh/p/<id>. Packs sind unlisted, nicht zugangskontrolliert. Wer die URL hat, kann installieren. Keine Secrets hineintun.

Suchen, ohne dem Leaderboard zu glauben

Die Site hat All-Time, Trending (24h) und Hot. Die Zahlen kommen aus anonymer Telemetrie des CLI — standardmässig an, stündlich dedupliziert, nur welche Skill auf welchem Agenten. Keine Inhalte, keine Personen. Abschalten mit DISABLE_TELEMETRY=1 oder DO_NOT_TRACK=1.

Das Leaderboard zählt Installationen, nicht Qualität. Eine Meta-Skill, die beim Suchen hilft, sammelt Installationen, weil das CLI sie anbietet — nicht weil sie dein konkretes Problem löst. Azure-Packs, Design-Kits, Video-Pipelines: hohe Zahlen heissen «viele Leute haben npx skills add gedrückt», oft für ein ganzes Repo auf einmal.

Besser:

npx skills find

Ohne Argument ein interaktives Suchen, mit Argument ein Keyword (npx skills find typescript). --owner vercel schränkt auf Repos dieser Org ein. Und dann die SKILL.md lesen, bevor du installierst. skills.sh zeigt pro Eintrag die Quelle, Security-Audits der Partner und auf welchen Agenten sie landet. Skills, die bei jedem Partner durchfallen, fliegen aus dem Verzeichnis. Das ist kein Freibrief. Anthropic sagt dasselbe in den eigenen Docs: eine Skill kann Anweisungen und Code mitbringen. Behandel sie wie Software, die du installierst.

Auf dem Leaderboard stehen heisst: Leute haben npx skills add owner/repo ausgeführt. Es gibt keinen Review, der dich aufnimmt. Es gibt auch keinen, der eine schlechte Skill wieder runterholt, solange die Audits nicht fehlschlagen.

Eine eigene schreiben

Wenn du dieselbe Anleitung zum dritten Mal in ein Chatfenster kippst, ist das der Moment.

npx skills init my-skill

legt ein SKILL.md an. Die zwei Pflichtfelder:

---
name: my-skill
description: What this skill does and when to use it
---

name ist klein, Bindestriche, maximal 64 Zeichen, gleich dem Ordnernamen. description sagt beides: was sie tut und wann der Agent sie laden soll. «Hilft bei PDFs» ist zu dünn. «Extracts text and tables from PDF files, fills forms, merges files. Use when handling PDFs.» trifft, weil der Agent die Beschreibung gegen deine Nachricht hält.

Der Rest ist Markdown. Schritte, Beispiele, Kanten. Die Spezifikation empfiehlt, SKILL.md unter 500 Zeilen zu halten und Details nach references/ zu schieben. Skripte nach scripts/. Vorlagen nach assets/. Der Agent lädt die Anhangdateien erst, wenn die Anleitung darauf zeigt.

Eine gute Skill ist langweilig zu lesen. Sie sagt, was zu tun ist, woran man erkennt, dass es sitzt — und wann man aufhören soll. Sie erklärt nicht, warum Skills die Zukunft sind. Das merkt der Agent nicht — und du willst die Tokens nicht dafür ausgeben.

Zum Verteilen reicht ein öffentliches GitHub-Repo, in dem das CLI eine SKILL.md findet — im Root, unter skills/, oder in den Pfaden, die der Agent selbst nutzt (.claude/skills/, .agents/skills/, …). Sobald jemand npx skills add darauf ausführt, taucht sie in der Telemetrie auf.

Wenn sie nicht greift

Die übliche Liste, in der Reihenfolge, in der ich prüfe:

1. Liegt der Ordner dort, wo dieser Agent sucht? Claude Code guckt nicht in ~/.cursor/skills/.
2. Sind name und description gültiges YAML? Ohne beide Felder findet das CLI die Skill nicht.
3. Trifft die Beschreibung die Aufgabe? Steht da nur «utility for developers», lädt sie der Agent nie. Die Beschreibung ist der Index.
4. Hast du global installiert und erwartest sie im Projekt — oder umgekehrt?
5. Hat jemand disable-model-invocation gesetzt? Dann musst du sie selbst mit /name aufrufen. Das ist ein Claude-Code-Feld, kein Teil der offenen Spezifikation.

npx skills list zeigt, was das CLI glaubt installiert zu haben. Der Agent hat seine eigene Sicht. Beide gegen den Pfad halten, nicht gegeneinander.

Und: eine Skill, die ein Skript startet, läuft mit denselben Rechten wie der Agent. Lies SKILL.md und alles unter scripts/, bevor du -y drückst.

Was ich wirklich laufen lasse

Auf dieser Site liegen Skills für das Cover eines Posts, für Infografiken und für Text, der nach Chatbot klingt. Es sind Ordner. Ich habe sie nicht vom Leaderboard geholt, ich habe sie geschrieben, weil ich denselben Ablauf jedes Mal neu erklärt habe.

Ich installiere nicht vierzig Stück «für alle Fälle». Jede Beschreibung sitzt ab Start im Kontext. Zwanzig vage Skills sind teurer und unzuverlässiger als drei präzise. Die, die ich behalte, haben eine klare Kante: diesen einen Ablauf, den ich sonst wieder eintippe.

Wenn eine Skill bei dir nicht zündet und du nicht den Abend in YAML verbraten willst: schreib mir. Manchmal fehlt nur der Satz «Use when…» in der Beschreibung.