arnesano/ blog

Grundlagen

01 Skills

Hinweis

Ein Skill ist eine wiederverwendbare Arbeitsanleitung für einen Agent. Er bündelt Schritte, Qualitätskriterien und bei Bedarf Skripte oder Vorlagen.

Persönliche und Projekt-Skills

Ein Skill liegt in einem Ordner mit SKILL.md. Sein Speicherort bestimmt, in welchen Projekten er verfügbar ist.

Geltungsbereich Codex Claude Code
Persönlich, für mehrere Projekte ~/.agents/skills/<name>/SKILL.md ~/.claude/skills/<name>/SKILL.md
Im Projekt, mit dem Team geteilt .agents/skills/<name>/SKILL.md .claude/skills/<name>/SKILL.md

In Davides lokalem Setup liegen persönliche Skills unter ~/.codex/skills; diese Session stellt sie bereit. Die Tabelle zeigt die aktuell dokumentierten Standardpfade für neue lokale Skills. Plugins bringen eigene Skill-Verzeichnisse mit.

Unterordner: Codex sucht vom aktuellen Arbeitsverzeichnis bis zur Repo-Wurzel nach .agents/skills. Gleichnamige Skills werden nicht zusammengeführt. Claude lädt Projekt-Skills aus übergeordneten Verzeichnissen; tiefer liegende Skills werden verfügbar, sobald es dort Dateien bearbeitet oder liest. Das vererbt die Verfügbarkeit. Ein Skill wird erst bei Auswahl angewendet, während AGENTS.md allgemeine Arbeitsregeln vorgibt. Quellen: Codex, Claude Code.

Wann lädt der Agent einen Skill?

Zuerst sieht der Agent die Metadaten: Name und Beschreibung. Passt der Auftrag, wählt er den Skill und liest die vollständige SKILL.md. Referenzen und Skripte folgen bei Bedarf. Eine gute Beschreibung nennt deshalb Aufgabe und Einsatzgrenze.

Du kannst die Auswahl ausdrücklich anfordern:

Codex CLI/IDE: $skill-creator Erstelle einen Skill für unseren Release-Check.
Claude Code:  /skill-creator Erstelle einen Skill für unseren Release-Check.

Das setzt voraus, dass der Skill installiert und verfügbar ist. In der Desktop-Oberfläche den angebotenen Skill-Selektor verwenden. Ohne ausdrücklichen Aufruf kann das Modell anhand der Beschreibung auswählen, sofern das erlaubt ist. Codex-Aufrufe.

Wer darf den Skill aufrufen?

Einstellung Codex Claude Code
Normalfall Mensch und Modell können auswählen. Mensch und Modell können auswählen.
Nur ausdrücklich policy.allow_implicit_invocation: false in agents/openai.yaml disable-model-invocation: true im YAML-Kopf der SKILL.md
Nur durch das Modell Kein entsprechendes Feld in der verlinkten Skill-Referenz dokumentiert. user-invocable: false im YAML-Kopf

Bei Claude ist user-invocable standardmäßig true: Der Skill ist als /name aufrufbar. disable-model-invocation ist standardmäßig false: Claude darf ihn selbst auswählen. Diese Felder nicht unverändert als Codex-Steuerung übernehmen. Claude-Aufrufregeln, Codex-Metadaten.

Codex-Beispiel für einen ausschließlich ausdrücklich gewählten Skill:

# agents/openai.yaml
policy:
  allow_implicit_invocation: false

Zwei bekannte Beispiele

Vereinfachte Metadaten, keine vollständigen Installationsvorlagen. Unter dem YAML-Kopf stehen jeweils die eigentlichen Arbeitsschritte.

---
name: skill-creator
description: Create or update a reusable agent skill.
---

Skill Creator führt durch Aufbau und Prüfung eines Skills.

---
name: pdf
description: Read, create, or review PDF files when layout matters.
---

PDF beschreibt Werkzeuge und visuelle Prüfungen für PDF-Arbeit. Ein Skill ist dabei die Anleitung; ein Tool führt die einzelne Aktion aus.

Von einer Anweisung zum Arbeitsablauf

Skills sind Markdown-Anleitungen mit Metadaten. Manche bestehen fast nur aus Text. Andere verweisen auf Vorlagen, Referenzen und ausführbare Skripte, die der Agent bei Bedarf über seine Tools startet.

Kurz: Matt Pococks wait-what fordert eine verständlichere Erklärung mit fehlendem Kontext und den Begriffen des Projekts. Sein YAML-Kopf setzt für Claude disable-model-invocation: true; der Mensch entscheidet, wann die Erklärung nicht angekommen ist.

Umfangreicher: Unser lokaler setup-workspace-Skill erstellt den Arbeitsvertrag eines Projekts. Vereinfachte Struktur:

setup-workspace/
├── SKILL.md
├── references/
│   └── workspace.example.toml
└── scripts/
    └── workspace-validation.py

Seine SKILL.md, vereinfacht dargestellt:

---
name: setup-workspace
description: Create or update a project's workspace.toml contract.
---

# Setup Workspace

1. Vorlage und bestehende Projektregeln lesen.
2. Workspace-Regeln im Interview oder anhand freigegebener Defaults festlegen.
3. workspace.toml schreiben, Tracker-Zugriff und Vertrag prüfen.
4. AGENTS.md verknüpfen und CodeGraph-Bereitschaft prüfen.

Die Vorlage liefert die Struktur, zum Beispiel diesen Auszug:

schema_version = "1.1"
setup_complete = false
project_name = "example-project"

[issues]
enabled = true
type = "gh"
url = "https://github.com/example/project"

Der Agent ersetzt Beispielwerte und ergänzt Regeln für Dokumentation, Code, Git und Qualität. Das Python-Skript prüft den Vertrag. Ein lokaler Router-Hook kann dessen Status beim Lesen des Router-Skills einblenden. Hooks sind separat eingerichtete Auslöser; eine SKILL.md allein registriert keinen Hook.

Quellen geprüft am 3. November 2026; das Setup-Beispiel basiert auf Davides lokalem Skill. Weiter: Grill me und Wayfinder.