CGS IT Solutions GmbH — Claude Code Training · Modul 8c · Skills im Detail · v2.0.1

Modul 8c

Skills im Detail

Vertiefung zu Modul 8 · Konfiguration, Lebenszyklus, Muster

Inhalt

1Konfiguration — Parameter nach Aufgabengebiet 2Lebenszyklus im Kontext — was bleibt, was /compact lässt 3Aufbau und Freiheitsgrade — wie viel Vorschrift 4Muster, die tragen — Checkliste, Loop, Template 5Code und Anti-Patterns — und warum ein Skill nicht zieht Glossar — Begriffe zum Nachschlagen

Eine Zeile Frontmatter entscheidet das Verhalten

Modul 8 zeigt, woraus eine SKILL.md besteht — dieses Deck zeigt, was die Felder im Kopf bewirken.
Links steht, was man hinschreibt, rechts, was man in vier Skills des Begleitprojekts agent-scaffolding beobachten kann.

# laeuft in EIGENEM Kontext, Ergebnis
# kommt zurueck, Suchmuell bleibt drin
context: fork
agent: Explore

# nur der MENSCH darf starten
disable-model-invocation: true

# EINE Datei, zwei Zeilen: nur das MODELL
# darf, und nur bei passenden Dateien
user-invocable: false
paths: ["src/**/*.java"]

# SCRIPT runs without a permission prompt
allowed-tools: Bash(${CLAUDE_SKILL_DIR}
  /scripts/count-endpoints.py *)
  1. Fork — finding-validations. /context vor und nach dem Lauf: die durchsuchten Dateien fehlen im Hauptkontext.
  2. Nur Mensch — drafting-release-notes. Für alles mit Seiteneffekt.
  3. Nur Modell und pfadgebunden — java-conventions, eine Datei mit beiden Zeilen. Hintergrundwissen, das als Kommando keinen Sinn ergibt und erst beim Anfassen einer Java-Datei lädt.
  4. Skript — counting-endpoints. Läuft ohne Rückfrage; Zeile entfernen und es wird gefragt.
checked am 2026-09-26 gegen docs/en/skills

Konfiguration

Parameter nach Aufgabengebiet

Frontmatter-Felder nach Aufgabengebiet

20 Felder, keines Pflicht.
Die Tabelle ordnet sie nach dem, was man erreichen will.

Aufgabengebiet Felder
Gefunden werdendescription · when_to_use · name
Auslösung steuerndisable-model-invocation · user-invocable · paths
Anderswo laufen lassencontext: fork · agent · background
Werkzeuge freigebenallowed-tools · disallowed-tools
Verhalten erzwingenhooks
Argumente annehmenargument-hint · arguments
Ausstattung wählenmodel · effort · shell
Nur beschreibenlicense · compatibility · metadata
Empfohlen ist nur description — daran entscheidet sich, ob der Skill gefunden wird.
Einen falsch geschriebenen Feldnamen ignoriert Claude Code ohne Fehlermeldung.
checked am 2026-09-26 gegen docs/en/skills

Argumente übergeben: Einsetzen ja, Prüfen nein

Claude Code setzt Argumente als Text in den Skill ein.
Typ, Pflichtfeld oder Wertebereich prüft dabei niemand.

  1. Deklarieren: argument-hint zeigt beim Tippen die erwartete Form, arguments gibt den Positionen Namen.
  2. Einsetzen: $ARGUMENTS für alles, $0, $1 nach Position, $version nach Name. Nimmt kein Platzhalter das Argument auf, hängt Claude Code ARGUMENTS: … an.
  3. Prüfen ist eine Anweisung im Rumpf — „ist das keine Versionsnummer: nachfragen und anhalten". Das Modell kann sie übergehen.
  4. Ein Argument ist Fremdtext. Nie ungeprüft in eine Befehlszeile setzen, allowed-tools eng fassen.
# drafting-release-notes/SKILL.md
---
argument-hint: "[version]"
arguments: version
---
Version: `$version`
(ohne Argument: `unreleased`)

# Aufruf
/drafting-release-notes 2.4.0

# ohne Argument:
# $version wird leer
# $0 bleibt woertlich stehen
checked am 2026-09-26 gegen docs/en/skills

Derselbe Skill in der Claude-App und über die API

Claude Code kennt alle 20 Felder. Upload in die Claude-App, Skills-API und package_skill.py erlauben nur sechs:
name, description, license, compatibility, metadata, allowed-tools.

  1. Jedes andere Feld bricht den Upload ab — Claude Code dagegen ignoriert unbekannte Felder still.
  2. Beim Upload Pflicht: name (höchstens 64 Zeichen, Kleinbuchstaben, Ziffern, Bindestriche, ohne „claude" und „anthropic") und description (höchstens 1024 Zeichen).
  3. Dieselbe Grenze gilt beim Aktivieren im claude.ai-Konto — so kommt ein eigener Skill in die Claude-App, in Cloud-Sessions und Routines.
  4. Wer beide Welten bedienen will, bleibt bei den sechs Feldern. Auslösung, Werkzeugsperren und Fork gibt es dann nur in einer eigenen Claude-Code-Fassung.
  5. Befehle im Rumpf (!befehl) wirken außerhalb von Claude Code nicht.
# Upload eines Claude-Code-Skills
# in die Claude-App:
---
name: drafting-release-notes
description: ...
argument-hint: "[version]"
---

Unexpected key(s) in SKILL.md
frontmatter: argument-hint.
Allowed properties are: allowed-tools,
compatibility, description, license,
metadata, name
checked am 2026-09-26 gegen docs/en/skills

Wer einen Skill auslösen darf

Zwei Felder, drei Zustände.
Wer auslösen darf, entscheidet mit, was überhaupt im Kontext liegt.

(nichts gesetzt)
Mensch   Modell
Beschreibung immer
voller Inhalt beim Auslösen
disable-model-invocation
Mensch   Modell
gar nichts,
bis ein Mensch ihn ruft
user-invocable: false
Mensch   Modell
Beschreibung immer
voller Inhalt beim Auslösen
Frontmatterwas im Kontext liegt
Ein Skill mit disable-model-invocation kostet im Ruhezustand nichts — nicht einmal seine Beschreibung liegt im Kontext.
Versucht das Modell ihn trotzdem aufzurufen, blockt Claude Code den Aufruf.
checked am 2026-09-26 gegen docs/en/skills

allowed-tools gibt frei, schränkt nicht ein

allowed-tools nimmt für die genannten Werkzeuge die Rückfrage weg.
Die Freigabe gilt nur für den Zug, der den Skill auslöst.

# counting-endpoints/SKILL.md
---
allowed-tools: Bash(${CLAUDE_SKILL_DIR}
  /scripts/count-endpoints.py *)
---
Fuehre ${CLAUDE_SKILL_DIR}/scripts
/count-endpoints.py aus.

# DIESELBE Variable an BEIDEN Stellen:
# die Regel passt auf den Befehl,
# so: no permission prompt.
  1. Mit der nächsten Nachricht ist die Freigabe weg — der Skill-Inhalt bleibt.
  2. Alle anderen Werkzeuge bleiben aufrufbar, für sie gelten die normalen Permissions.
  3. Einschränken geht mit disallowed-tools, ebenfalls nur bis zur nächsten Nachricht.
  4. deny- und ask-Regeln schlagen allowed-tools. Was die Permissions verbieten, gibt kein Skill frei.
allowed-tools wirkt ohne Workspace-Trust — auch in einem -p-Lauf in einem Ordner, dem nie jemand vertraut hat.
Eingecheckte Projekt-Skills deshalb lesen, bevor man Claude Code in einem fremden Repository startet.
checked am 2026-09-26 gegen docs/en/skills

Lebenszyklus im Kontext

Was bleibt, was verfällt, was /compact übrig lässt

Inhalt bleibt, Rechte verfallen, Änderungen greifen live

Der ausgelöste Inhalt tritt als eine Nachricht in die Unterhaltung und bleibt die ganze Session.
Die Skill-Datei beobachtet Claude Code weiter und erkennt Änderungen ohne Neustart.

  1. Der Inhalt bleibt, die Rechte nicht. allowed-tools verfällt mit eurer nächsten Nachricht.
  2. Ein zweiter Aufruf mit gleichem Inhalt hängt nichts an. Bei anderen Argumenten oder neuer Skript-Ausgabe wird er voll neu angehängt.
  3. Neuer Ordner .claude/skills/, der beim Start fehlte: /reload-skills. Diesen Ordner beobachtet Claude Code nicht.
  4. Nach /compact zurückgeholt — aber gekürzt, siehe rechts.
die Unterhaltung, von oben nach unten
1System · CLAUDE.md
2eure Nachricht
3Skill-Inhalt — tritt einmal ein
4Antwort, Tool-Calls, …
…der Skill-Inhalt bleibt oben stehen
nnach /compact: erste 5.000 Token je Skill, 25.000 gesamt, jüngster zuerst
Systemder SkillVerlauf
checked am 2026-09-26 gegen docs/en/skills

Shell-Kommandos im Skill laufen vor dem Modell

Ein Skill kann Shell-Kommandos ausführen, bevor das Modell etwas sieht.
Die Ausgabe ersetzt den Platzhalter — das Modell bekommt Daten, nicht den Befehl.

# einzeilig, inline
- PR-Diff: !`gh pr diff`

# mehrzeilig: Code Fence mit !
```!
git status --short
git log --oneline -5
```

# Pruefer endet bei Befund mit 1:
!`./check.sh || true`

KEY=!`cmd` # laeuft NICHT --
# das ! muss am Zeilenanfang oder
# nach einem Leerzeichen stehen
  1. Ein Durchlauf. Ausgaben werden nicht erneut nach Platzhaltern durchsucht.
  2. Keine Rückfrage, aber eine Permission-Prüfung: was keine allow-Regel und kein allowed-tools deckt, bricht das Auslösen ab.
  3. Ein Exit-Code ungleich 0 bricht das ganze Auslösen ab — das Modell sieht den Skill dann gar nicht.
  4. Abschaltbar per Richtlinie mit disableSkillShellExecution — ausgenommen sind gebündelte Skills und solche aus Managed Settings.
checked am 2026-09-26 gegen docs/en/skills

Aufbau und Freiheitsgrade

Wie groß, wie tief, wie viel Vorschrift

Aufteilen, aber nur eine Ebene tief

Große Referenzdateien kosten nichts, solange sie nicht gelesen werden.
Verschachtelte Verweise kosten Verlässlichkeit.

eine Ebene
SKILL.md
finance.md
sales.md
examples.md
drei Ebenen
SKILL.md
overview.md
details.md
actual.md
hier steht es wirklich
der RumpfReferenzdatei
  1. Rumpf unter 500 Zeilen, darüber aufteilen.
  2. Alle Verweise direkt aus der SKILL.md. Bei tieferer Verschachtelung liest das Modell Zieldateien womöglich nur an und arbeitet mit Lücken.
  3. Referenzdateien über 100 Zeilen bekommen ein Inhaltsverzeichnis.
  4. Nach Domäne aufteilen, nicht nach doc1, doc2.
checked am 2026-09-26 gegen platform best-practices

Wie eng ein Skill vorschreibt

Wie genau ein Skill vorschreibt, richtet sich nach der Zerbrechlichkeit der Aufgabe.

# HOCH -- viele Wege sind richtig
1. Struktur des Codes ansehen
2. Auf Randfaelle pruefen
3. Lesbarkeit vorschlagen

# MITTEL -- Muster mit Parametern
def report(data, format="markdown",
          charts=True):

# NIEDRIG -- genau dieser Befehl
python scripts/migrate.py \
  --verify --backup
Keine zusaetzlichen Flags.
  1. Hoch: Entscheidung hängt vom Kontext ab. Beispiel Code-Review.
  2. Mittel: ein bevorzugtes Muster gibt es, Abweichung ist erlaubt.
  3. Niedrig: zerbrechlich, feste Reihenfolge. Beispiel Datenbank-Migration.
Das Bild: schmale Brücke mit Abgründen braucht ein Geländer, offenes Feld braucht eine Richtung.
checked am 2026-09-26 gegen platform best-practices

Muster, die tragen

Checkliste, Feedback-Loop, bedingter Ablauf, Template

Workflow mit Checkliste

Bei mehrschrittigen Abläufen wird die Checkliste in die Antwort kopiert und abgehakt.
Das verhindert, dass Prüfschritte übersprungen werden.

## checking-conventions/SKILL.md

Uebertrage diese Checkliste und
hake sie ab:

```
Fortschritt:
- [ ] 1: Pruefer laufen lassen
- [ ] 2: Verstoesse beheben
- [ ] 3: Pruefer erneut
- [ ] 4: weiter, wenn gruen
```
  1. Die Checkliste sorgt dafür, dass kein Schritt entfällt.
  2. Funktioniert auch ohne Code — das Doku-Beispiel ist eine Recherche-Synthese in fünf Schritten.
  3. Ihr seht den Fortschritt und könnt eingreifen, bevor der letzte Schritt läuft.
checked am 2026-09-26 gegen platform best-practices

Der Feedback-Loop

Das Muster der Doku in drei Worten: prüfen, beheben, wiederholen.
Es steht im Rumpf des Skills — als nummerierte Schritte mit einer eigenen Abbruchbedingung.

bis 0 Verstöße
Prüfer laufen lassen
Datei, Zeile,
erwartete Form
EINEN beheben
zurück — Prüfer erneut
Exit 0 — erst jetzt weiter
mvn -o test
Schrittdie Schleife
  1. Schritt 3 ist der Loop. Ohne ihn ist das eine Liste, die einmal durchläuft — der häufigste Fehler beim Nachbauen.
  2. Der Prüfer ist die Wahrheit, nicht die Einschätzung des Modells — meist ein Skript mit Exit-Code.
  3. Er muss kein Skript sein. Auch eine Stilrichtlinie taugt als Prüfer — dann liest und vergleicht das Modell. Das Muster bleibt dasselbe.
  4. Meldungen ausführlich halten — Datei, Zeile, erwartete Form. Wer nur „ungültig" meldet, erzwingt Raten.
Im Begleitprojekt belegt: erster Lauf 2 Verstöße, Exit 1 — nach zwei Änderungen 0 Verstöße, Exit 0.
Der Skill meldet am Ende, wie viele Durchläufe er gebraucht hat.
checked am 2026-07-30 gegen best-practices

Bedingter Ablauf: nur der passende Zweig wird gelesen

Zwei Wege, ein Entscheidungspunkt am Anfang — und die Zweige in eigenen Dateien.
Nur der zutreffende wird gelesen.

# changing-endpoints/SKILL.md

Schritt 1: Art der Aenderung
bestimmen.

- Neuer Endpunkt: lies create.md
- Bestehender: lies edit.md

Unsicher? Pruefe mit Grep, ob der
Pfad schon vorkommt.

Schritt 2: dem Ablauf der
gelesenen Datei folgen.
  1. Der Gewinn ist Kontext, nicht Ordnung: wer beide Zweige in die SKILL.md schreibt, lädt immer beide.
  2. Der Entscheidungspunkt braucht ein Kriterium, nicht nur eine Frage — hier der Grep.
  3. Im Transkript ist sichtbar, welche Datei gelesen wurde. Das ist der Beobachtungsweg im Begleitprojekt.

Vorlage und Ergebnis

Wenn die Form zählt, gibt man sie vor.
Links die Vorlage im Skill, rechts was dabei herauskommt.

# reviewing-with-template/SKILL.md
Benutze genau diese Vorlage.
Keine zusaetzlichen Abschnitte.

```markdown
# Review: <Dateiname>
## Einschaetzung
<ein Satz>
## Befunde
| Zeile | Schwere | Befund |
## Was gut ist
- <ein bis drei Punkte>
```
Schwere: kritisch | warnung | hinweis
Nichts anderes.
# und so sieht die Antwort aus
# Review: Booking.java

## Einschaetzung
Fachlich klar, aber der Geldbetrag
ist als Gleitkommazahl abgelegt.

## Befunde
| 18 | kritisch | double fuer Geld |
| 30 | hinweis | Setter ohne Pruefung |

## Was gut ist
- Namen sagen, was gemeint ist
- keine Fachlogik in der Resource
Streng formulieren, wenn die Form weiterverarbeitet wird („benutze genau diese Vorlage").
Weich formulieren, wenn Anpassung hilft („das ist ein sinnvoller Standard, urteile nach Lage").

Code und Anti-Patterns

Mitgelieferte Skripte — und warum ein Skill nicht zieht

Mitgelieferte Skripte melden Fehler als Befund

Eine Ausnahme, die das Skript nach oben durchlässt, wird zum Rätsel für das Modell.
Behandelt sie da, wo ihr wisst, was sie bedeutet.

# schlecht: reicht die Ausnahme weiter
def pruefe(pfad):
  # let the agent figure it out
  return open(pfad).read()

# Das Modell sieht dann nur:
PermissionError: [Errno 13] ...
# und muss raten, ob das ein Befund,
# ein Aufruffehler oder ein Bug ist.

# gut: die Ausnahme WIRD ein Befund
try:
    zeilen = pfad.read_text().splitlines()
except OSError as e:
    return [{"regel": "unlesbar",
        "datei": str(pfad),
        "erwartet": str(e)}]
  1. Eine unlesbare Datei ist ein Befund, kein Absturz. Sie landet in derselben Struktur wie jeder andere Befund — der Aufrufer braucht keinen Sonderfall.
  2. Keine unbegründeten Konstanten. TIMEOUT = 47 — wenn ihr den Wert nicht kennt, kennt das Modell ihn auch nicht.
  3. Sagt, ob ausführen oder lesen. „Führe x.py aus" gegen „siehe x.py für den Algorithmus".
  4. Plan, prüfen, ausführen bei Stapel- und riskanten Änderungen: erst eine prüfbare Zwischendatei.
checked am 2026-07-30 gegen best-practices

Rückgabe-Vertrag und Aufrufer

Ein Skript, das ein Skill aufruft, braucht eine zugesagte Rückgabe.
Sonst muss der Aufrufer Text lesen und rät bei jeder Änderung neu.

# tools/check-conventions.py --json
{
  "gate": "conventions",
  "exit": 1, # 0 sauber 1 Verstoss 2 Aufruf
  "geprueft": 26,
  "verstoesse": [{
    "regel": "mandant",
    "datei": "...SeminarRepository.java",
    "zeile": 19,
    "gefunden": "list(\"startDate > ?1\"...)",
    "erwartet": "der Mandant gehoert in
      JEDE Abfrage"
  }]
}

# auch bei exit 2 gueltiges JSON,
# dann mit Feld "fehler"
# checking-conventions/SKILL.md
allowed-tools: Bash(python3 tools
  /check-conventions.py *)
---
1. `python3 tools/check-conventions.py
   --json`

2. Bei "exit": 2 ist es ein Aufruf-
   fehler: melde `fehler`, halte an.

3. Arbeite `verstoesse[]` ab. Je Eintrag:
   - oeffne `datei` an `zeile`
   - vergleiche mit `gefunden`
   - setze `erwartet` um
   - nach `regel` unterscheiden:
     mandant | geld | logging

4. Erst weiter, wenn "exit": 0.
Der Vertrag steht im Kopfkommentar des Skripts — dort sucht ihn, wer ihn braucht.
Beides liegt im erweiterten Beispiel cgsit-claude-training-ext, nicht im Begleitprojekt; alle drei Exit-Codes sind dort durchgespielt.
checked am 2026-07-30 gegen ext-Uebungsprojekt

Anti-Patterns im Skill helper

Sieben Fehler mit Namen.
Alle sieben stecken absichtlich im Skill helper des Begleitprojekts — er ist das Material der Übung.

Fehler Warum er schadet
Vage Beschreibungder Skill wird nicht gefunden. Der einzige, der ihn unsichtbar macht.
Verschachtelte VerweiseZieldateien werden nur angelesen, Information fehlt
Windows-Pfade mit Backslashfunktioniert auf keinem Unix-System
Viele Optionen ohne Vorgabedas Modell wählt beliebig statt richtig
Zeitabhängige Angabenveraltet zwangsläufig. Altes in einen eigenen Abschnitt
Unbegründete Konstantenniemand kann den Wert anpassen, auch das Modell nicht
Wechselnde Begriffe„Feld", „Box", „Element" für dasselbe — erschwert das Befolgen
checked am 2026-09-26 gegen platform best-practices

Die Beschreibung entscheidet, ob ein Skill zieht

Ob ein Skill gewählt wird, entscheidet das Modell allein an description und name.
Der Inhalt spielt dafür keine Rolle, er lädt erst danach.

# zieht nicht
description: Helps with code.

# zieht unzuverlaessig -- sagt WAS,
# aber nicht WANN
description: Prueft die Java-
  Konventionen dieses Repositories.

# zieht
description: Prueft die Java-
  Konventionen und behebt Verstoesse
  gegen die Regeln zu Geldbetraegen
  und Logging. Zu benutzen bei
  Aufraeumarbeiten, vor einem Commit,
  oder wenn nach Konventionen gefragt
  wird.
  1. Was er tut UND wann er anzuwenden ist. Der zweite Satz entscheidet.
  2. Dritte Person. Die Beschreibung landet im System-Prompt; „ich kann dir helfen" stört die Auswahl.
  3. Die Wörter nennen, die eure Leute tippen — nicht nur die Fachsprache des Skills.
  4. Namen in Verlaufsform: processing-pdfs, nicht helper, utils, tools.
checked am 2026-09-26 gegen platform best-practices

Warum der Skill trotzdem nicht zieht

Stimmt die Beschreibung und der Skill zieht trotzdem nicht, kommt sie beim Modell nicht an.
Jede der drei Ursachen lässt sich mit einem Befehl nachsehen.

  1. Kaputtes YAML: der Skill lädt ohne Metadaten. /name funktioniert, die automatische Auswahl nicht.
  2. Voller Katalog: die Liste aller Beschreibungen hat rund ein Prozent des Kontextfensters. Darüber fallen Beschreibungen weg, zuerst die der selten genutzten Skills — also die des neuen.
  3. Zu lange Beschreibung: description und when_to_use werden zusammen bei 1.536 Zeichen gekappt. Wichtigsten Anwendungsfall zuerst.
# steht er in der Liste?
/skills
> „Welche Skills gibt es?"

# parst das Frontmatter?
claude plugin validate .claude/skills

# was kostet der Katalog, wer frisst ihn?
/doctor
/skill-doctor # ungenutzte Skills
/context # Zeile „Skills"

# Platz schaffen (settings.json)
"skillOverrides": { "legacy": "name-only" }
"skillListingBudgetFraction": 0.02
checked am 2026-09-26 gegen docs/en/skills

Vor dem Teilen: prüfen, was sich prüfen lässt

Das Begleitprojekt prüft die Checkliste der Doku mit einem Skript statt von Hand.
Was kein Skript prüfen kann, muss man beobachten.

$ bash verify.sh # im Begleitprojekt
OK checking-conventions: Frontmatter
   und Verweise in Ordnung
OK count-endpoints.py laeuft (Exit 0)
OK validate-conventions.py meldet
   Verstoesse (Exit 1)
OK helper: Windows-Pfad noch vorhanden

Was verify.sh NICHT kann:
ob der Skill im Gespraech zieht.
Das entscheidet das Modell an der
Beschreibung — und das kann nur
ein Mensch beobachten.
  1. Maschinell prüfbar: Feldnamen, Verweistiefe, Pfadform, Ausführbarkeit, Rumpflänge. Ob das YAML parst, prüft claude plugin validate.
  2. Nur beobachtbar: ob die Beschreibung greift. Dafür eine Aufgabe in Alltagssprache, ohne den Namen zu nennen.
  3. Erst Evaluationen, dann Dokumentation — drei Fälle, an denen messbar ist, ob der Skill etwas verbessert.
  4. Eine Instanz baut, eine andere benutzt. Beobachtet wird die zweite.
checked am 2026-09-26 gegen platform best-practices

Modul 8c in fünf Sätzen

Was von diesem Deck hängenbleiben soll.

  1. Eine Zeile Frontmatter ändert das Verhalten. Wer auslöst, wo es läuft, was erlaubt ist — alles einzeln einstellbar.
  2. Ein ausgelöster Skill bleibt die ganze Session im Kontext und wird nie neu gelesen. Dauer-Anweisungen schreiben, keine Schrittfolgen.
  3. Die Rechte verfallen, der Inhalt nicht. allowed-tools gilt für einen Zug — und ist eine Freigabe, keine Einschränkung.
  4. Der Feedback-Loop bringt den größten Qualitätsgewinn, wenn der Prüfer ein Exit-Code ist und die Abbruchbedingung dasteht.
  5. Zieht ein Skill nicht, liegt es an der Beschreibung — oder daran, dass sie beim Modell nicht ankommt: kaputtes YAML, voller Katalog.

Glossar Glossar

Frontmatter Der Kopfteil einer Datei zwischen zwei Zeilen aus drei Bindestrichen, in YAML geschrieben. Trägt die Einstellungen eines Skills, Subagenten oder einer Regel — nicht seinen Inhalt.
YAML (YAML Ain't Markup Language) Textformat für Konfiguration, das Einrückung statt Klammern benutzt. Format des Frontmatter in Skills und Subagenten.
Progressive Disclosure Aufbauprinzip für Skills: die SKILL.md ist ein Inhaltsverzeichnis, die Einzelheiten stehen in Begleitdateien und werden erst gelesen, wenn sie gebraucht werden. Ungelesene Dateien kosten keinen Kontext.
Feedback-Loop Ablaufmuster: prüfen, Fehler beheben, erneut prüfen, und erst bei bestandener Prüfung weitermachen. Der Prüfer ist meist ein Skript mit Exit-Code, nie die Einschätzung des Modells.
Skill-Katalog Die Liste aus Name und Beschreibung aller Skills, die in jeder Anfrage mitgeht. Daran wählt das Modell aus. Sie hat ein festes Budget; bei vielen Skills fallen Beschreibungen weg.
Workspace-Trust-Abfrage Die Frage beim ersten Start in einem Ordner, ob man dessen Konfiguration vertraut. allowed-tools in Skills wirkt auch ohne sie.
Exit-Code Die Zahl, mit der ein Programm endet: 0 heißt in Ordnung, alles andere heißt Fehler. Sie ist das Signal, an dem ein Skill erkennt, ob er noch einen Durchlauf braucht.

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 8c · Skills · v2.0.1