Agent Skills Leitfaden 2026: Installation und welche Skills Claude Code und Codex brauchen

Stand September 2026 nutzen Claude Code, Codex, Cursor und eine Reihe quelloffener Coding-Agents dasselbe offene Format: ein Verzeichnis plus eine SKILL.md. Ein Skill ist kein zweiter Plugin-Marktplatz. Es ist eine Verfahrensanleitung, die nur geladen wird, wenn sie gebraucht wird. Viele Teams kleben Release-Checklisten, Review-Schritte und Rollback-Sprüche weiter in CLAUDE.md oder AGENTS.md, oder sie installieren per Ein-Klick Dutzende Community-Pakete von GitHub. Die Kauffrage lautet nicht, wie viele Skills Sie besitzen. Sie lautet, ob dieses Verfahren in jeder Runde in den Kontext muss, ob die Beschreibung beim falschen Job automatisch zündet, und ob scripts/ im Ordner mit denselben Rechten läuft wie Sie. Dieser Artikel wiederholt nicht den gesamten offenen Standard. Er beantwortet Installation und Shortlist: welche Skills Claude Code und Codex tragen sollen, wie Sie sie installieren, und wie Sie sie abnehmen.

Warum Verfahren in den globalen Prompt zu stopfen 2026 bereits die falsche Entscheidung ist

Der alte und der neue Weg prallen ganz konkret aufeinander. Der alte Weg ist prompt-first: ein immer längeres Handbuch in der Repo-Wurzel, das jede Sitzung vollständig injiziert wird. Der neue Weg ist skill-first: stabile Fakten bleiben in CLAUDE.md oder AGENTS.md; wiederholbare Mehrschritt-Arbeit wird eine SKILL.md. Der Agent startet mit Name und Beschreibung und lädt den Inhalt erst, wenn er das Skill nutzt. Dieselbe Bitte — „bringe dieses Release raus“ — berechnet Ihnen im alten Weg das Handbuch jede Runde, im neuen nur auf der Release-Aufgabe. Wer das ignoriert, zahlt weiter Text, den niemand in dieser Sitzung braucht.

Drei Dinge haben daraus ein Planungsproblem statt eines Hobbyvergleichs gemacht. Erstens hat Claude Code eigene Slash-Befehle in Skills zusammengeführt. Eine Datei unter .claude/commands/deploy.md und ein Skill unter .claude/skills/deploy/SKILL.md werden beide zu /deploy. Alte Befehlsdateien bleiben gültig. Die neuen Fähigkeiten — Begleitdateien, Auto-Aufruf, Sub-Agents — leben auf dem Skill-Verzeichnis. Zweitens scannt Codex .agents/skills vom Arbeitsverzeichnis nach oben bis zur Repository-Wurzel. Persönliche Skills liegen unter ~/.agents/skills. Der ältere Pfad ~/.codex/skills wird weiter gescannt, deshalb sieht ein Skill, das „installiert“ im falschen Baum liegt, aus wie ein fehlendes Skill. Drittens kann die npx skills-CLI von Vercel dasselbe Paket in Claude Code, Codex, Cursor und Dutzende andere Agents schreiben. Portabilität hält nur, wenn Sie das Skill nicht gegen das private Frontmatter eines einzelnen Anbieters geschrieben haben. Ein Team, das diese drei Punkte nicht aufschreibt, debattiert nächste Woche wieder, warum „es auf meinem Rechner geht“.

Eine Schicht wird leicht übersprungen. Skills sind nicht MCP, und sie sind nicht Function Calling. Werkzeugprotokolle entscheiden, wie ein Modell eine lebende Schnittstelle aufruft. Ein Skill entscheidet, wann ein menschliches Verfahren geladen wird. Wie die Tool-Schleife geformt sein sollte, steht unter Was ist Function Calling. Dynamischer Zustand über Sitzungen gehört nicht in einen Skill-Text; das ist ein Memory-Schicht-Problem, behandelt in Self-hosted Agent Memory vs SaaS. Welches Harness Sie um das Modell legen, ist eine eigene Kauffrage in Pi vs Claude Code vs Codex. Wer diese Schichten vermischt, kauft dreimal dasselbe und behebt nichts.

Wie Sie Agent Skills klassifizieren

Skill-Namen als Gleichrangige nebeneinanderzulegen, garantiert eine aufgeblähte Favoritenliste. Klassifizieren Sie sie danach, wer sie pflegt, wann sie laden, und ob sie Nebenwirkungen haben. Lassen Sie eine Klasse weg, bleibt Ihnen nur Reputation. Die Klasse sagt mehr über Rechnung, Risiko und Nacharbeit aus als jeder Store-Screenshot.

Die gebündelten Skills von Claude Code sind Prompt-Orchestrierung, keine festen Binaries: /code-review, /debug, /run, /verify, /run-skill-generator, /doctor. Ab v2.1.145 können die letzten drei einen Start aus README oder package.json ableiten. Bei einem Projekt, das eine Datenbank, eine Env-Datei oder einen mehrstufigen Build braucht, einmal /run-skill-generator fahren und Installationsbefehle, Env-Variablen und Startskript als In-Repo-Skill committen, damit spätere Sitzungen das Rezept nicht neu entdecken. Codex bündelt Leitfäden wie skill-installer, skill-creator, review-agent und openai-docs. Beide Seiten nutzen Progressive Disclosure: zuerst Name und Beschreibung, den Inhalt bei Nutzung. Das Beschreibungsfeld ist keine Dekoration. Zu kurz, und das Skill zündet nie. Zu weit, und es zündet bei jeder Kleinigkeit. Wer die Beschreibung als Marketingzeile schreibt, kauft sich Fehlauslöser auf Dauer.

Kernvergleich: Einstieg, Ausführung, Kontext, Zielgruppe

Der echte Unterschied ist der Einstieg, nicht welches Labor einen größeren Skill-Katalog veröffentlicht hat. Nutzen Sie einen Satz von Spalten, sonst können Sie nicht entscheiden. Dieselben fünf Überschriften halten den Vergleich ehrlich und verhindern, dass aus einer Tabelle eine Werbeliste wird.

Eine zweite Tabelle deckt nur die Fallen „ich dachte, es sei installiert“ ab. Die Überschriften bleiben dieselben, damit der Fließtext nicht in leere Adjektive kippt. Lesen Sie die Zeilen als Buchhaltung, nicht als Geschmacksurteil.

# Claude Code — project skill (this repo only)
mkdir -p .claude/skills/review-change

# Codex — project skill (open .agents/ convention)
mkdir -p .agents/skills/review-change

# Personal skill, every repo on this machine
mkdir -p ~/.claude/skills/review-change
mkdir -p ~/.agents/skills/review-change

# Cross-agent package manager (Vercel skills CLI)
npx skills add vercel-labs/agent-skills --skill react-best-practices -a claude-code
npx skills add vercel-labs/agent-skills --skill react-best-practices -a codex

# Codex bundled installer (often writes ~/.codex/skills)
# Inside a Codex session:
# $skill-installer linear

Eine minimale SKILL.md braucht nur die offenen Standardfelder name und description. Die Datei darunter reicht, um Auslöser und das Laden des Inhalts zu testen. Fügen Sie scripts/ erst hinzu, wenn diese Schleife langweilig ist. Wer Skripte vor dem Trigger-Test committet, misst zuerst Schaden, nicht Nutzen.

---
name: review-change
description: Reviews an uncommitted diff and lists risks. Use when the user asks what changed, wants a commit message, or asks to review the working tree. Do not use for greenfield feature design.
---

## Current changes

Run git diff HEAD and summarize in three bullets.
Flag missing tests, hardcoded secrets, and edits outside the named module.
If the diff is empty, say so and stop.

Welche Skills Claude Code und Codex wirklich tragen sollten

Ein empfohlener Stack ist keine Anbieter-Store-Top-Ten. Es ist eine Nebenwirkungsleiter. Behalten Sie gebündelte Skills. Behalten Sie nur die Projektabläufe, die Sie jede Woche wiederholen. Behalten Sie repo-übergreifende Regeln erst, nachdem jemand den Inhalt gelesen hat. Menge ohne Audit ist kein Vorsprung, sondern eine längere Auslöserliste.

Ein Solo-Entwickler sollte ein review-change-Skill und ein release-Skill landen, bevor er entscheidet, dass er React-Regeln braucht. Ein kleines Produktteam sollte „Checks, die vor einem PR laufen müssen“ als Projekt-Skill kodieren und persönlichen Geschmack in einer benutzerweiten CLAUDE.md lassen. Kundenpfade gehören nicht in ein benutzerweites Skill. Ein Unternehmen sollte Skills wie Code behandeln: SKILL.md und scripts/ per Pull Request, und Mitglieder ablehnen, die ungeprüfte Pakete nach ~/.agents/skills symlinken. Wer das als „Prozess-Overhead“ abtut, entdeckt den Overhead erst nach dem ersten ungeprüften Schreibzugriff.

Wie Sie nach Szene wählen

Die Szene entscheidet vor der Marke. Schreiben Sie zuerst auf, welcher Ablauf sich jede Woche wiederholt, welches CLI bereits bezahlt ist, und welche Rechte ein Skill ohne Nachfrage haben darf. Dann erst wählen Sie die Klasse. Die folgende Tabelle ist eine Routing-Regel, kein Ranking.

Empfohlene Kombinationen

A — Solo-Entwickler, ein primäres CLI: gebündelte Skills anlassen. Committen Sie nur zwei Projekt-Skills: den uncommitteten Diff reviewen, und mit dem bestehenden Skript releasen. Schreiben Sie Wann nutzen / wann nicht nutzen in die Beschreibung. Dateischreiben und Bash gehören in einen Container oder auf einen Remote-Mac, der den Workspace pro Sitzung isoliert. Legen Sie API-Ausgaben und Knotenmiete auf dasselbe Blatt; monatliche Knotenkosten stehen unter Mac-mini-Preise. Wer Token und Miete getrennt betrachtet, unterschätzt die Monatszahl fast immer.

B — Kleines Produktteam, Claude Code und Codex zusammen: Regelpakete wie react-best-practices oder web-design-guidelines pro Agent mit npx skills installieren. Nicht den ganzen Katalog kippen. Release und Rollback bleiben im Projektbaum und werden im PR reviewed. Persönliche Formulierungen bleiben in einem benutzerweiten Prompt, nicht in einem Skill. Nehmen Sie beide CLIs gegen dieselbe Sample-Release-Aufgabe ab. Nehmen Sie nicht an, dass ein Skill, das in einem Harness zündet, im anderen zündet. Ein Team, das beide Pfade einmal misst, streitet weniger über „bei mir geht es“.

C — Enterprise oder hohe Sicherheit: behandeln Sie Skills wie Code. Verzeichnis, Skripte und Beschreibung gehen durch Pull Request. Verbieten Sie ungeprüfte Pakete in Benutzerordnern. Skripte, die Netz öffnen oder Geheimnisse berühren, laufen nur auf einem wegwerfbaren Knoten. Konto- und Liefergrenzen stehen im Hilfecenter. Wenn Sie einen isolierten Workspace brauchen, beginnen Sie bei Mac mini mieten, statt das Bürolaptop als Labor zu nutzen. Audit will reproduzierbare Knoten, nicht einen Agent mit denselben Rechten wie Slack und der Browser.

Häufige Fallstricke

1. Nach Favoriten einkaufen: „mehr Skills machen einen klügeren Agent.“ Jede weite Beschreibung ist ein Budget für Fehlauslöser. Eine Favoritenliste ist kein Shortlist-Kriterium.
2. Verfahren im globalen Prompt lassen: eine Release-Checkliste, die jede Sitzung lädt, ist ein Handbuch, das Sie jede Runde bezahlen. Der Text ist nicht kostenlos, nur weil er schon im Repo liegt.
3. Pfade für universell halten: .claude/skills von Claude Code ist nicht die Codex-Standardwurzel. Der Codex-Installer kann weiter nach ~/.codex/skills schreiben. Ein fehlender Aufruf ist oft ein falscher Baum, kein fehlendes Feature.
4. Benutzer-Ebene installieren, bevor Skripte gelesen sind: scripts/ erben den startenden Nutzer. Zuerst Projektverzeichnis, zuerst isolierter Knoten. Ein ungeprüftes Paket unter ~/.claude/skills leakt in jedes Repo auf der Maschine.
5. Tests durch ein Community-Skill ersetzen: /verify und Ihre CI sind keine Substitute. Ein Skill kann eine Rot-Grün-Suite nicht ersetzen. Wer das Skill als Test betrachtet, misst Prosa, nicht Verhalten.

Aktionsplan: 7 Schritte

1. Öffnen Sie CLAUDE.md oder AGENTS.md. Markieren Sie jedes Verfahren länger als einen Absatz als Kandidat: Release, Review, Rollback, Changelog. Fakten behalten. Schritte verschieben. Was kürzer als ein Absatz ist, bleibt oft eine Tatsache, kein Skill.
2. Schreiben Sie eine SKILL.md ohne scripts/. Setzen Sie Wann nutzen und wann nicht nutzen in die Beschreibung. Rufen Sie sie einmal mit /review-change oder $review-change auf. Ohne diesen manuellen Beweis ist Auto-Trigger nur Hoffnung.
3. Fragen Sie in Alltagssprache und prüfen Sie, ob es automatisch zündet. Zündet es beim falschen Job, schreiben Sie die Beschreibung neu. Installieren Sie kein zweites Skill, um das erste zu überdecken. Eine zweite weite Beschreibung verdoppelt das Budget für Fehlauslöser.
4. Legen Sie Claude-Code-Skills nach .claude/skills/ und Codex-Skills nach .agents/skills/. Wenn Cursor oder ein anderer Agent dasselbe Paket sehen muss, nutzen Sie npx skills add … -a, statt den falschen Ordner per Hand zu kopieren. Ein vertauschter Baum sieht aus wie ein totgeborenes Skill.
5. Halten Sie bei gebündelten Skills plus zwei bis vier Projekt-Skills. Ein Community-Paket betritt den Projektbaum erst, nachdem jemand die SKILL.md und die Skripte gelesen hat. Es betritt nicht zuerst ~/.claude/skills oder ~/.agents/skills. Benutzer-Ebene ist die Ausnahme, nicht der Default.
6. Fahren Sie Skills, die scripts/ mitbringen, in einem Container oder auf einem Remote-Mac. Halten Sie Geheimnisse aus dem Prompt und aus dem Skill-Text. Der Workspace muss am Sitzungsende wischbar sein. Isolation ist Teil der Abnahme, nicht ein Nachgedanke nach dem Leak.
7. Nehmen Sie gegen eine Release- oder Review-Aufgabe ab: hat es gezündet, welche Dateien hat es berührt, und sind die Original-CI-Tests grün. Ein warmer lokaler Cache, der „grün aussieht“, ist keine Abnahme. Reproduzierbarkeit schlägt eine einmalig grüne Demo.

FAQ

Worin unterscheiden sich Skills von CLAUDE.md oder AGENTS.md?

Stabile Fakten gehören in CLAUDE.md oder AGENTS.md und werden jede Sitzung gelesen. Wiederholbare Mehrschritt-Verfahren gehören in Skills und laden nur bei Nutzung. Eine Release-Checkliste im globalen Prompt heißt: Sie zahlen das Handbuch jede Runde. Der Unterschied ist Ladezeitpunkt, nicht Dateiendung.

Können Claude Code und Codex dasselbe Skill teilen?

Sie teilen das offene SKILL.md-Format. Sie teilen nicht Pfade und Aufruf. Claude Code liest .claude/skills/ und ~/.claude/skills/. Codex liest .agents/skills/ und ~/.agents/skills/ und scannt noch den älteren Pfad ~/.codex/skills. Mit npx skills -a zielen Sie auf einen Agenten. Wer nur eine Seite prüft, erklärt ein installiertes Skill oft für tot.

Soll ich jedes beliebte GitHub-Skill per Ein-Klick installieren?

Nein. Eine weite Beschreibung zündet bei den falschen Jobs. scripts/ laufen mit denselben Rechten wie Sie. Lesen Sie die SKILL.md und alle Skripte, dann ins Projektverzeichnis — nicht in den Benutzerordner, der in jedes Repo leakt. Ein-Klick-Pakete mit Dutzenden Skills sind eine Favoritenliste, keine Shortlist.

Unterschied zwischen Codex $skill-installer und npx skills?

$skill-installer ist ein gebündelter Codex-Installer und schreibt oft nach ~/.codex/skills. npx skills ist ein agentenübergreifender Paketmanager und kann claude-code oder codex treffen. Selbst geschriebene Skills gehören nach .agents/skills oder .claude/skills. Beide Bäume prüfen, bevor Sie „nicht installiert“ sagen. Der typische Fehlschluss ist, nur den Baum zu lesen, in den Sie selbst geschrieben haben.

Darf ich Skills mit Skripten auf dem Alltagslaptop laufen lassen?

Sie laufen. Tun Sie das nicht auf einem unbekannten Repo oder mit Produktionsgeheimnissen. Legen Sie sie zuerst in einen Container oder auf einen Remote-Mac-Knoten, bestätigen Sie Auslöserumfang und Schreibgrenzen, und entscheiden Sie dann, ob das Skill ins Team-Repo darf. Ein Laptop, auf dem Mail, Slack und der Agent dieselben Rechte teilen, ist kein Labor, sondern eine gemeinsame Angriffsfläche.

Fazit

2026 eine Community-Rangliste als Einkaufswagen für Agent Skills zu behandeln, ist die falsche Entscheidung. Wählen Sie zuerst nach Einstiegsklasse: gebündelte Skills als Anbieter-Rückfall, Projekt-Skills für Release und Review, die Sie jede Woche wiederholen, und repo-übergreifende Regeln erst, nachdem jemand sie gelesen hat. Claude Code und Codex teilen ein Format. Sie teilen kein Standardverzeichnis. Halten Sie Beschreibungen eng, installieren Sie Skripte spät, und behandeln Sie den Benutzerordner als Ausnahme statt als Default. Schreiben Sie die Trennung, den Auslöser, den Pfad und den wischbaren Knoten in die Sieben-Schritte-Abnahme. Remote-Knoten beginnen auf der Mietseite und der Preisseite. Kontofragen gehen an das Hilfecenter. Wer diese Reihenfolge einhält, kauft weniger Fehlauslöser und mehr wiederholbare Releases.

Weiterlesen

• Pi vs Claude Code vs Codex: Harness 2026 wählen →
• Was ist Function Calling: OpenAI, Gemini, Claude →
• Self-hosted Agent Memory vs SaaS Memory →