Skills für Claude Code und Codex CLI: Der vollständige Leitfaden für wiederverwendbare Workflows

Wer Claude Code oder Codex CLI täglich verwendet, stößt sehr schnell auf ein Problem: Die gleichen Anweisungen werden immer wiederholt. Man bittet den Agenten, eine API nach einer bestimmten Methode zu analysieren, vor Änderungen am Backend stets dieselben Punkte zu prüfen, bei Security-Audits ein festgelegtes Verfahren einzuhalten oder vor einem Produktions-Release eine Checkliste abzuarbeiten. Natürlich kann man diese Anweisungen in einer Textdatei speichern und jedes Mal in den Prompt kopieren. Das ist jedoch weder besonders praktisch noch elegant.

Agent Skills lösen genau dieses Problem. Sie verwandeln eine Arbeitsmethode in einen wiederverwendbaren Workflow, den der Agent entdecken, laden und bei Bedarf anwenden kann. Die Idee ist einfach: Statt dem Agenten immer wieder zu erklären, wie er arbeiten soll, stellt man ihm ein strukturiertes Verfahren in einer Datei namens SKILL.md zur Verfügung.

Besonders interessant ist, dass dieses System nicht auf eine einzige Umgebung beschränkt ist. Claude Code und Codex CLI verwenden beide das Konzept der Skills, mit einem auf SKILL.md basierenden Format und dem offenen Agent-Skills-Standard. Ein großer Teil eines Skills kann deshalb einmal geschrieben und anschließend sowohl mit Claude Code als auch mit Codex CLI verwendet werden.

Dieser Leitfaden erklärt, wie das System funktioniert, wie man einen wirklich portablen Skill erstellt, wie man ihn in beiden Umgebungen installiert und welche typischen Fehler beim Aufbau einer Workflow-Bibliothek vermieden werden sollten.

Was ist ein Agent Skill?

Ein Agent Skill ist im Grunde ein Verzeichnis mit spezialisierten Anweisungen für einen KI-Agenten. In der einfachsten Form enthält es nur eine Datei namens SKILL.md. Bei komplexeren Workflows können zusätzlich Skripte, Referenzen oder weitere Ressourcen enthalten sein.

Eine typische Struktur sieht so aus:

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

Die Datei SKILL.md bleibt das zentrale Element. Sie beschreibt, was der Skill macht, wann er verwendet werden soll und welche Anweisungen der Agent befolgen muss. Die übrigen Verzeichnisse sind optional. Sie sind nützlich, wenn der Skill Skripte ausführen, ausführliche Dokumentation konsultieren oder bestimmte Ressourcen verwenden soll.

In der Praxis lassen sich Skills für sehr viele Aufgaben erstellen. Ein Team kann beispielsweise einen security-review-Skill für Sicherheitsprüfungen, einen api-review-Skill für die Analyse von Endpoints, einen release-check-Skill für die Kontrolle einer Anwendung vor dem Produktionsstart oder einen database-migration-Skill für interne Migrationsabläufe anlegen.

Der Nutzen besteht also nicht nur darin, einen Prompt zu speichern. Ein Skill hält eine Arbeitsmethode fest und macht sie wiederverwendbar.

Warum einen Skill statt eines langen Prompts verwenden?

Der erste Grund liegt auf der Hand: Man spart Zeit. Wer regelmäßig dieselben Anweisungen wiederholt, muss sie nicht in jeder Unterhaltung neu formulieren. Der andere Vorteil ist jedoch oft noch wichtiger: Konsistenz.

Stellen wir uns vor, ein Entwickler fragt heute „Analysiere diese API“, morgen „Führe eine vollständige Prüfung dieser Route durch“ und eine Woche später „Überprüfe, ob dieser Endpoint korrekt implementiert ist“. Die drei Anfragen sind sehr ähnlich, drücken aber nicht unbedingt dieselben Erwartungen aus. Je nach Formulierung kann der Agent bestimmte Aspekte prüfen und andere übersehen.

Mit einem Skill wird das Verfahren einheitlich. Der Agent kann beispielsweise immer Route, Eingabeparameter, Authentifizierung, Fehlerbehandlung, Datenbankzugriffe, Sicherheitsrisiken und Antwortstruktur prüfen. Die Anfrage des Entwicklers kann dadurch viel kürzer ausfallen, weil der Agent die anzuwendende Methode bereits kennt.

Genau das macht Skills im professionellen Umfeld interessant. Sie verwandeln Gewohnheiten, interne Regeln und Arbeitsweisen eines Teams in Workflows, die Agenten regelmäßiger und zuverlässiger anwenden können.

Claude Code und Codex CLI folgen demselben Grundprinzip

Claude Code und Codex CLI sind natürlich nicht identisch, aber der Kern ihres Skill-Systems beruht auf demselben Prinzip. In beiden Umgebungen kann ein Skill mit einer Datei SKILL.md beschrieben werden. Diese enthält YAML-Frontmatter mit Angaben wie Name und Beschreibung, gefolgt von den Anweisungen in Markdown.

Hier ist ein minimales Beispiel:

---
name: api-review
description: Review an API endpoint for correctness, validation, authentication, error handling and security. Use when the user asks to review, audit or explain an API endpoint.
---

# API Review

Inspect the endpoint implementation.

Check:

1. Route and HTTP method
2. Input parameters
3. Request validation
4. Authentication and authorization
5. Database operations
6. Error handling
7. Response format
8. Security risks

Report problems before suggesting changes.

Do not modify the code unless the user explicitly asks for it.

Diese Datei bleibt bewusst einfach. Sie verwendet keine Funktion, die speziell an Claude Code oder Codex gebunden ist, und ist deshalb zwischen beiden Umgebungen portabel.

Der Agent-Skills-Standard verlangt mindestens name und description. Der Name sollte zum Skill-Verzeichnis passen, zum Beispiel:

api-review/
└── SKILL.md

mit:

name: api-review

Der Name sollte einfach bleiben, normalerweise in Kleinbuchstaben mit Zahlen oder Bindestrichen. Die Beschreibung erfordert dagegen deutlich mehr Aufmerksamkeit.

Die Beschreibung ist wahrscheinlich der wichtigste Teil

Die Eigenschaft description wirkt auf den ersten Blick wie eine reine Information. Tatsächlich spielt sie eine zentrale Rolle: Sie hilft dem Agenten zu verstehen, wann ein Skill verwendet werden soll.

Eine Beschreibung wie diese ist viel zu vage:

description: Helps with APIs.

Sie erklärt weder, was der Skill tatsächlich tut, noch in welchen Situationen er ausgelöst werden soll. Eine deutlich nützlichere Variante wäre:

description: Review REST API endpoints for request validation, authentication, authorization, error handling and security issues. Use when the user asks to audit, review or inspect an API endpoint.

Diese Beschreibung liefert dem Agenten zwei entscheidende Informationen: Was macht der Skill und wann soll er verwendet werden? Das ist eine gute Grundregel für eigene Skills: Die Beschreibung sollte immer beide Fragen beantworten.

Es kann außerdem hilfreich sein zu definieren, was den Skill nicht auslösen soll. Ein Security-Skill könnte beispielsweise festlegen, dass er nur bei einem ausdrücklich angeforderten Audit oder Security-Review verwendet wird, nicht aber bei einer einfachen Bitte um eine Code-Erklärung. Je klarer die Grenzen zwischen den Skills sind, desto zuverlässiger wird die Auswahl.

Einen portablen Skill für beide Umgebungen erstellen

Nehmen wir nun ein realistischeres Beispiel mit einem api-review-Skill. Ziel ist eine einzige Datei, die sowohl mit Claude Code als auch mit Codex CLI verwendet werden kann.

---
name: api-review
description: Review and explain API endpoints. Use when the user asks to audit, review, inspect, document or understand an API route or endpoint. Check validation, authentication, authorization, database operations, error handling, response structure and security.
---

# API Review

Review the API endpoint requested by the user.

## Locate the endpoint

Find the file containing the relevant route or handler.

Identify the HTTP method, route path, handler function and framework.

Do not assume the implementation before reading the relevant code.

## Explain the endpoint

Describe the route, its purpose, inputs, authentication requirements and outputs.

For inputs, include path parameters, query parameters, request body fields and relevant headers.

For outputs, describe the success status code, response structure and important returned fields.

## Review the implementation

Check input validation, authentication, authorization, database access, external API calls, error handling, status codes, response validation, logging and hardcoded configuration.

## Security review

Look for missing authorization checks, injection vulnerabilities, unsafe user input, exposed secrets, sensitive data leakage, insecure direct object references and excessive error information.

Do not invent vulnerabilities. Only report issues supported by the code.

## Report findings

Order findings by severity: Critical, High, Medium, Low and Improvements.

For every issue, provide its location, the problem, its impact and a recommended correction.

If no significant issue is found, say so explicitly.

## Modification policy

Do not modify files automatically.

Explain the findings first and only make changes if the user explicitly asks for them.

Der Inhalt bleibt bewusst unabhängig vom verwendeten Produkt. Genau das ist entscheidend, wenn eine gemeinsame Workflow-Bibliothek gepflegt werden soll.

Einen Skill in Claude Code installieren

In Claude Code wird ein projektspezifischer Skill normalerweise unter .claude/skills/ abgelegt.

Unser Beispiel sieht dann so aus:

my-project/
└── .claude/
    └── skills/
        └── api-review/
            └── SKILL.md

Der vollständige Pfad lautet:

.claude/skills/api-review/SKILL.md

Soll der Skill in allen Projekten verfügbar sein, kann er im Benutzerverzeichnis gespeichert werden:

~/.claude/skills/api-review/SKILL.md

Für ein Team ist es oft sinnvoller, Skills direkt im Repository abzulegen. Sie können dann mit Git versioniert werden, und alle Entwickler arbeiten mit denselben Verfahren.

Ein Skill kann in Claude Code explizit über seinen Namen als Kommando aufgerufen werden:

/api-review

Er kann auch automatisch ausgelöst werden, wenn die Anfrage des Benutzers ausreichend gut zu seiner Beschreibung passt.

Den gleichen Skill in Codex CLI installieren

Mit Codex CLI ist die Logik nahezu identisch, aber der Speicherort ändert sich. Projekt-Skills werden unter .agents/skills/ abgelegt.

my-project/
└── .agents/
    └── skills/
        └── api-review/
            └── SKILL.md

Für einen persönlichen Skill, der in allen Projekten verfügbar sein soll, verwendet man:

$HOME/.agents/skills/api-review/SKILL.md

Codex kann .agents/skills-Verzeichnisse in verschiedenen Teilen eines Repositorys durchsuchen. Das ist besonders in Monorepos praktisch. So kann ein allgemeiner Skill an der Projektwurzel liegen, ein weiterer für das Frontend und ein dritter ausschließlich für das Backend.

Zum Beispiel:

project/
├── .agents/
│   └── skills/
│       └── project-review/
│
├── frontend/
│   └── .agents/
│       └── skills/
│           └── frontend-review/
│
└── backend/
    └── .agents/
        └── skills/
            └── api-review/

In Codex wird ein Skill explizit mit dem Präfix $ aufgerufen:

$api-review review the login endpoint

Mit /skills können verfügbare Skills angezeigt oder ausgewählt werden. Wie Claude Code kann auch Codex einen Skill automatisch auswählen, wenn die Anfrage zu seiner Beschreibung passt.

Was sich zwischen Claude Code und Codex CLI tatsächlich ändert

In der Praxis betreffen die wichtigsten Unterschiede vor allem die Dateipfade und einige erweiterte Funktionen.

Der Kern des Systems bleibt also sehr ähnlich. Das macht das Format für Teams interessant, die mehrere Agenten einsetzen.

Wie Skills den Kontext verwenden

Ein wichtiger Punkt: Ein Skill wird nicht bei jeder Nachricht vollständig in den Kontext geladen. Das System arbeitet mit einer schrittweisen Offenlegung.

Zunächst muss der Agent vor allem den Namen und die Beschreibung der verfügbaren Skills kennen. Damit kann er erkennen, welche Skills existieren und welcher zur Anfrage passt. Erst nach der Auswahl wird der vollständige Inhalt von SKILL.md geladen. Zusätzliche Dateien in references/, scripts/ oder assets/ können anschließend bei Bedarf gelesen werden.

Dieses Verfahren ist wichtig, weil nicht die gesamte Dokumentation einer Skill-Bibliothek in jede Anfrage injiziert wird. Ein Skill kann daher umfangreich sein, ohne bei jeder Unterhaltung seinen vollständigen Inhalt zu verbrauchen.

Das bedeutet allerdings nicht, dass Skills völlig kostenlos sind.

Damit ein Skill ausgewählt werden kann, muss der Agent zumindest wissen, dass er existiert und was seine Beschreibung sagt. Bei fünf oder zehn gut definierten Skills sind die Kosten normalerweise vernachlässigbar. Bei Dutzenden oder Hunderten von Skills mit jeweils langen Beschreibungen sieht die Situation anders aus. Der Agent muss mehr Metadaten verarbeiten, was Kontext verbrauchen und die Auswahl unpräziser machen kann.

Die beste Strategie besteht darin, Beschreibungen kurz, präzise und ausreichend unterscheidbar zu halten.

Claude Code und die Kontrolle der Skill-Kosten

Claude Code lädt die für die Skill-Erkennung erforderlichen Informationen und erst bei tatsächlicher Verwendung den vollständigen Inhalt. Außerdem gibt es ein Budget für die Beschreibungen, damit eine sehr große Bibliothek nicht den gesamten Kontext einnimmt.

Claude Code stellt dafür auch ein nützliches Werkzeug bereit: /skill-doctor.

Dieses Werkzeug zeigt, welche Skills in der Sitzung vorhanden sind, wie oft sie verwendet werden und wie viel Kontext sie verbrauchen. Die Idee ist einfach: Wenn ein Skill wochenlang installiert ist, aber nie verwendet wird, sollte man ihn vielleicht deaktivieren, nur manuell auslösen oder entfernen.

In neueren Claude-Code-Versionen sind diese Informationen in den Statistiken des Plugin-Managers verfügbar. Das ist besonders hilfreich, wenn die Skill-Sammlung wächst, weil man tatsächlich verwendete Workflows von unnötig vorhandenen unterscheiden kann.

Auch Codex schützt seinen Kontext

Codex begrenzt ebenfalls die Informationen, die für die Erkennung von Skills verwendet werden. Die anfängliche Liste ist auf ungefähr 2 % des Modellkontexts oder auf 8.000 Zeichen begrenzt, wenn die Kontextgröße nicht bekannt ist.

Wird die Bibliothek zu groß, kürzt Codex zuerst die Beschreibungen. Reicht das nicht aus, erscheinen manche Skills möglicherweise nicht mehr in der anfänglichen Liste.

Dieser Schutz ist sinnvoll, ersetzt aber keine gute Organisation. Auch wenn das System die Auswirkungen auf den Kontext automatisch begrenzt, ist eine zu große oder schlecht strukturierte Bibliothek schwerer zu pflegen und erhöht die Wahrscheinlichkeit falscher Auslösungen.

Eine große SKILL.md ist nicht automatisch ein schlechter Skill

Dass eine SKILL.md-Datei lang ist, ist nicht grundsätzlich problematisch, da ihr vollständiger Inhalt normalerweise erst bei Verwendung des Skills geladen wird. Trotzdem sollte nicht alles in einer einzigen Datei landen.

Eine gute Praxis ist, SKILL.md auf den zentralen Workflow zu konzentrieren und ausführliche Dokumentation in ein Verzeichnis namens references/ auszulagern.

Nehmen wir einen PostgreSQL-Skill:

postgres-review/
├── SKILL.md
└── references/
    ├── indexing.md
    ├── migrations.md
    └── security.md

Die Hauptdatei kann den Agenten einfach anweisen, beim Analysieren von Indizes references/indexing.md, bei Migrationen references/migrations.md und bei Sicherheitsprüfungen references/security.md zu konsultieren.

Der Agent liest dann nur die Dokumentation, die er tatsächlich benötigt. Dadurch werden Skills außerdem deutlich leichter zu pflegen.

Skripte in einem Skill verwenden

Skills können auch Skripte enthalten. Das ist sinnvoll, wenn ein Vorgang deterministisch oder reproduzierbar sein soll.

Zum Beispiel:

dependency-audit/
├── SKILL.md
└── scripts/
    └── scan.py

Der Skill kann den Agenten auffordern, das Skript auszuführen und das Ergebnis zu analysieren. Das ist besonders nützlich zum Parsen von Logs, zur Validierung von JSON-Daten, zum Extrahieren eines Datenbankschemas, zum Prüfen von Dependency-Versionen oder zum Erstellen eines Berichts.

Als einfache Regel gilt: Der Agent sollte Operationen selbst ausführen, die er mit seinen Werkzeugen sinnvoll bewältigen kann. Skripte kommen dort zum Einsatz, wo ein präziser oder wiederkehrender Vorgang von Automatisierung profitiert.

Ein Skill ist kein Subagent

Skills und Subagents werden manchmal verwechselt, obwohl sie unterschiedliche Aufgaben erfüllen.

Ein Skill stellt dem Hauptagenten vor allem ein Verfahren, Wissen und möglicherweise zusätzliche Ressourcen bereit. Er sagt sinngemäß: „So erledigen wir diese Aufgabe.“

Ein Subagent ist dagegen eher eine Delegation an einen separaten Kontext oder einen spezialisierten Agenten. Er isoliert eine Aufgabe oder überträgt sie an eine dafür vorgesehene Instanz.

Ein Skill erzeugt also nicht automatisch einen neuen Agenten. Er erweitert hauptsächlich das Verhalten des bestehenden Agenten.

Was sollte in einen Skill verwandelt werden?

Die besten Kandidaten sind Verfahren, die regelmäßig wiederholt werden. Code-Reviews, Security-Audits, Release-Vorbereitungen, Datenbankmigrationen, Interface-Analysen und Bug-Untersuchungen sind gute Beispiele.

Nicht jede Information über ein Projekt sollte jedoch ein Skill werden.

Regeln wie „Wir verwenden TypeScript“, „das Backend liegt unter /backend“ oder „verwende immer pnpm“ sind dauerhafte Projektinformationen. In Claude Code gehören sie normalerweise in CLAUDE.md. In Codex können sie in AGENTS.md gespeichert werden.

Die Unterscheidung ist einfach: Muss eine Information immer bekannt sein, gehört sie in die dauerhaften Projektanweisungen. Handelt es sich um ein Verfahren, das nur bei bestimmten Aufgaben verwendet wird, ist es wahrscheinlich ein guter Kandidat für einen Skill.

Mega-Skills vermeiden

Ein häufiger Fehler ist ein riesiger Skill namens developer, der gleichzeitig Frontend-, Backend-, Security-, Datenbank-, Test-, Deployment-, Dokumentations- und CI/CD-Regeln enthält.

Auf dem Papier wirkt das bequem. In der Praxis wird der Skill dadurch schwerer auszuwählen, schwerer zu pflegen und deutlich weniger wiederverwendbar.

Besser ist es, Verantwortlichkeiten mit Skills wie diesen zu trennen:

frontend-review
api-review
security-review
database-review
release-check

Jeder Skill besitzt dann eine klar erkennbare Aufgabe.

Auch zu starke Überschneidungen sollten vermieden werden. Wenn api-review, backend-review, code-review, security-review und quality-review alle sagen, dass sie bei einem „Code-Review“ verwendet werden sollen, muss der Agent zwischen fast identischen Kandidaten auswählen.

Die Beschreibungen sollten deshalb präzise genug sein, damit jeder Skill einen klar abgegrenzten Zuständigkeitsbereich besitzt.

Spezifische Funktionen von Claude Code

Obwohl der Kern des Formats portabel bleibt, bietet Claude Code einige interessante Erweiterungen.

Mit folgendem Eintrag kann verhindert werden, dass ein Skill automatisch ausgelöst wird:

disable-model-invocation: true

Das ist nützlich für sensible Workflows wie Produktions-Deployments, potenziell destruktive Migrationen oder Vorgänge, die niemals ohne eine ausdrückliche Entscheidung des Benutzers starten sollen.

Claude Code bietet außerdem mehrere Sichtbarkeitsebenen. Damit lässt sich steuern, ob ein Skill vollständig aktiv, nur über seinen Namen sichtbar, ausschließlich manuell verwendbar oder komplett deaktiviert sein soll.

Diese Optionen sind nützlich, bleiben aber spezifisch für Claude Code. Wer Portabilität priorisiert, sollte die Kernlogik im gemeinsamen Standard halten und produktspezifische Erweiterungen nur einsetzen, wenn sie einen echten Mehrwert liefern.

Spezifische Funktionen von Codex

Auch Codex besitzt eigene Erweiterungen.

Die automatische Auslösung eines Skills kann beispielsweise über agents/openai.yaml gesteuert werden:

policy:
  allow_implicit_invocation: false

Der Skill bleibt verfügbar, wird von Codex aber nicht mehr automatisch aufgrund einer einfachen Übereinstimmung mit dem Prompt aufgerufen. Der Benutzer muss ihn explizit mit folgendem Aufruf starten:

$skill-name

Codex kann diese Datei außerdem für zusätzliche Metadaten und Abhängigkeiten verwenden.

Wie bei Claude Code ist es sinnvoll, den Kern des Workflows portabel zu halten und produktspezifische Erweiterungen nur bei Bedarf einzusetzen.

Eine gemeinsame Bibliothek für mehrere Agenten

Für ein Unternehmen ist es besonders interessant, eine interne Skill-Bibliothek zu pflegen, die unabhängig von den eingesetzten Agenten ist.

Eine mögliche Struktur wäre:

skills/
├── api-review/
├── security-review/
├── frontend-review/
├── database-review/
├── release-check/
└── documentation/

Jedes Verzeichnis enthält eine SKILL.md nach dem gemeinsamen Standard. Dieselben Skills können anschließend über .claude/skills/ für Claude Code und über .agents/skills/ für Codex bereitgestellt werden.

So müssen nicht zwei vollständig unterschiedliche Bibliotheken für Agenten gepflegt werden, die häufig dieselben Aufgaben erledigen.

Mit der Zeit kann ein Team auf diese Weise eine Art „ausführbares Betriebshandbuch“ aufbauen. Entwicklungsverfahren, Checklisten, Konventionen und Auditmethoden werden direkt für KI-Agenten nutzbar.

Wahrscheinlich wird genau an diesem Punkt der wichtigste Nutzen sichtbar.

Einen Skill testen, bevor man ihm vertraut

Einen Skill zu erstellen ist einfach. Sicherzustellen, dass er korrekt funktioniert, erfordert etwas mehr Arbeit.

Zwei Dinge sollten getrennt getestet werden. Erstens die Auslösung: Der Skill sollte gewählt werden, wenn die Anfrage wirklich zu seiner Aufgabe passt, aber nicht bei themenfremden Aufgaben erscheinen.

Zum Beispiel:

Audit this endpoint.

sollte sinnvollerweise api-review auslösen.

Dagegen sollte:

Rename this variable.

den Skill nicht auslösen.

Zweitens muss das Ergebnis geprüft werden. Ein Skill kann zum richtigen Zeitpunkt ausgelöst werden und trotzdem schlechte Anweisungen liefern. Deshalb sollten die Antworten mit und ohne Skill verglichen werden, idealerweise anhand mehrerer realistischer Anfragen.

Claude Code und Codex bieten Werkzeuge zum Erstellen und Organisieren von Skills. Die endgültige Qualität hängt jedoch weiterhin stark von der Qualität der Anweisungen und der durchgeführten Tests ab.

Vorsicht bei Skills aus dem Internet

Ein Skill sollte nicht als harmlose Textdatei betrachtet werden. Er kann Anweisungen enthalten, die den Agenten zum Ausführen von Befehlen, Starten von Skripten, Lesen bestimmter Dateien oder Verwenden externer Ressourcen auffordern.

Vor der Installation eines Skills aus GitHub oder einem unbekannten Repository sollte man daher dessen SKILL.md lesen, die zugehörigen Skripte untersuchen, die auszuführenden Befehle prüfen und verstehen, auf welche Dateien zugegriffen werden soll.

Die beste Haltung ist, einen Skill aus einer fremden Quelle wie Code zu behandeln, den man der eigenen Entwicklungsumgebung hinzufügt, und nicht wie einen einfachen Prompt, den man in eine Unterhaltung kopiert.

Wie könnte eine echte Unternehmensbibliothek aussehen?

Ein Team, das an einer SaaS-Anwendung arbeitet, könnte seine Skills beispielsweise so organisieren:

skills/
├── architecture-review/
│   └── SKILL.md
│
├── api-review/
│   └── SKILL.md
│
├── database-migration/
│   ├── SKILL.md
│   └── references/
│       └── migration-policy.md
│
├── security-review/
│   ├── SKILL.md
│   └── references/
│       ├── auth.md
│       └── secrets.md
│
├── frontend-audit/
│   └── SKILL.md
│
└── release-check/
    ├── SKILL.md
    └── scripts/
        └── validate-release.sh

An diesem Punkt sind Skills keine einfachen Abkürzungen mehr. Sie werden zu einer Möglichkeit, das Wissen eines Teams zu formalisieren und direkt für KI-Agenten nutzbar zu machen.

Hier wird ihr eigentlicher Wert besonders deutlich.

Skills, Prompts und Modelle sind nicht dasselbe

Ein Skill ersetzt weder das Modell noch vollständig den Prompt des Benutzers.

Man kann das System als Kette betrachten:

Benutzer
    ↓
Prompt
    ↓
Agent
    ↓
Passender Skill
    ↓
KI-Modell
    ↓
Werkzeuge, Terminal und Dateien

Der Prompt beschreibt die aktuelle Anfrage. Der Skill liefert ein Verfahren oder eine Arbeitsmethode. Das Modell stellt die Fähigkeiten für Schlussfolgerungen und Generierung bereit, während der Agent den Zugriff auf Terminal, Dateien und andere Werkzeuge koordiniert.

Diese Unterscheidung wird besonders interessant, wenn ein Agent hinter derselben Oberfläche mehrere unterschiedliche Modelle verwenden kann.

Ein paar einfache Regeln für eine gesunde Bibliothek

Man braucht keine fünfzig Skills, um vom System zu profitieren. Fünf gute, klar definierte und tatsächlich verwendete Skills sind normalerweise wertvoller als eine riesige Sammlung redundanter Workflows.

Für den Anfang decken Skills wie api-review, security-review, frontend-review, bug-investigation und release-check bereits einen großen Teil der üblichen Anforderungen ab.

Beobachten Sie anschließend einfach Ihre tägliche Arbeit. Wenn Sie sich dabei ertappen, etwas zu schreiben wie „Führe immer zuerst A, dann B und dann C aus und prüfe vor dem Abschluss D“, haben Sie wahrscheinlich einen hervorragenden Kandidaten für einen neuen Skill gefunden.

Umgekehrt erfüllt ein Skill, der monatelang installiert bleibt, ohne jemals verwendet zu werden, wahrscheinlich keinen großen Zweck mehr. Genau solche Fälle können Werkzeuge wie /skill-doctor in Claude Code sichtbar machen.

Der eigentliche Wert von Skills

Skills werden manchmal als eine neue Art beschrieben, Prompts zu schreiben. Diese Definition greift jedoch zu kurz.

Ihr tatsächlicher Wert liegt darin, dass ein Team seine Arbeitsweisen festhalten kann. Entwicklungsverfahren, Checklisten, Konventionen, Validierungsprozesse, Auditmethoden und bestimmtes internes Wissen können in Workflows verwandelt werden, die Agenten direkt verwenden.

Damit verschiebt sich das Modell allmählich: Nicht mehr jeder Entwickler muss der KI immer wieder erklären, wie er arbeiten möchte. Stattdessen besitzt die Organisation bereits eine Bibliothek von Methoden, die ihre Agenten anwenden können.

Für Unternehmen, die Claude Code, Codex CLI oder andere Coding Agents zunehmend einsetzen, ist diese Entwicklung wahrscheinlich wichtiger, als sie heute wirkt.

Fazit

Claude Code und Codex CLI verwenden heute dasselbe grundlegende Konzept: Agent Skills auf Basis von SKILL.md.

Die Pfade unterscheiden sich:

Claude Code
.claude/skills/

und:

Codex CLI
.agents/skills/

Auch die Methoden für den expliziten Aufruf unterscheiden sich:

Claude Code
/api-review

gegenüber:

Codex CLI
$api-review

Zusätzlich bietet jede Umgebung einige spezifische Funktionen.

Der entscheidende Punkt bleibt jedoch gleich: Ein sauber nach dem gemeinsamen Standard erstellter Skill kann dieselbe SKILL.md, dieselbe Logik und einen großen Teil desselben Workflows in beiden Umgebungen verwenden.

Für Teams, die mehrere Coding Agents einsetzen, ist das wahrscheinlich der beste Ansatz: eine vom Anbieter unabhängige Workflow-Bibliothek aufbauen und Claude-Code- oder Codex-spezifische Funktionen nur dort nutzen, wo sie einen echten Mehrwert bieten.

Das Ziel ist nicht, möglichst viele Skills zu besitzen. Das Ziel ist eine kleine Anzahl präziser, nützlicher und getesteter Workflows, damit den Agenten nicht ständig aufs Neue erklärt werden muss, wie sie arbeiten sollen.

Quellen

Agent Skills — Spezifikation des SKILL.md-Formats: https://agentskills.io/specification

Anthropic — Claude-Code-Skills-Dokumentation: https://code.claude.com/docs/en/skills

Anthropic — Kontext, Skills, Hooks und Subagents: https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more

OpenAI — Codex-Skills-Dokumentation: https://developers.openai.com/codex/skills

Informationen im September 2026 geprüft. Claude Code und Codex entwickeln sich schnell weiter, daher können sich einzelne Befehle oder erweiterte Funktionen in zukünftigen Versionen ändern.