Erste eigene Skill in 30 Minuten, wenn Slash-Commands nicht mehr reichen

Slash-Commands sind super, solange Du Dich erinnerst sie zu tippen. Genau da liegt das Problem. Nach drei Wochen weißt Du, dass Du /review haben wolltest, aber Du tippst es halt nicht mehr. Skills lösen genau das. Sie sind Markdown-Dateien wie Slash-Commands, aber sie triggern automatisch wenn Claude im Prompt erkennt dass die Skill passt. Du sagst "schau Dir den Auth-Code mal an", und Claude lädt still im Hintergrund Deine simplify Skill und arbeitet danach. Ich zeig Dir wie Du in 30 Minuten Deine erste sinnvolle Skill schreibst und wo die Stolperfallen sind.

1. Verstehen wie Skills technisch funktionieren

Eine Skill ist ein Verzeichnis unter ~/.claude/skills/<name>/ mit mindestens einem File drin: SKILL.md. Frontmatter oben definiert wann die Skill triggern soll. Der Body ist die Anleitung was Claude tun soll wenn sie triggert. Claude scannt bei jedem Prompt die Frontmatter aller verfuegbaren Skills und entscheidet auf Basis der description ob eine matched. Wenn ja, lädt er den Body als zusätzlichen Kontext und benutzt ihn für die Antwort.

Das heißt: die Beschreibung in der Frontmatter ist nicht Doku, das ist der Trigger-Mechanismus. Wenn da steht "for German blog posts", dann triggert es bei "schreib mir nen Blog-Post auf Deutsch". Wenn da steht "use this skill for code review", triggert es nicht weil "code review" zu vage ist. Präzise Trigger sind alles.

2. Den ersten Skill anlegen

Mach das Verzeichnis und das File:

mkdir -p ~/.claude/skills/simplify
cat > ~/.claude/skills/simplify/SKILL.md <<'EOF'
---
name: simplify
description: |
  Use when reviewing code the user just wrote or edited. Looks
  for unused imports, duplicated logic, premature abstractions,
  dead error paths, and overlong functions. Triggers on phrases
  like "review this", "check my code", "anything to clean up".
---

# Simplify

When invoked:

1. Read the changed files in the working directory
2. Look specifically for:
   - Unused imports or variables
   - Logic duplicated within 50 lines
   - Functions over 60 lines that could split
   - Catch blocks that swallow errors silently
   - Premature abstractions used only once
3. Return max 5 concrete findings with line numbers
4. No general praise, no "looks good overall", just findings
EOF

Speichern, fertig. Claude Code muss nicht neugestartet werden, Live-Detection nimmt das auf. Tippst Du jetzt "review meinen letzten File", sollte Claude die Skill stillschweigend laden und nach den genannten Patterns suchen.

3. Die description ist Dein Trigger, nicht Deine Doku

Das ist der einzige Punkt wo Anfänger immer scheitern. Sie schreiben sowas wie description: A code review helper und wundern sich warum die Skill nie triggert. Claude entscheidet anhand der description ob die Skill passt, also muss da konkret drinstehen WANN sie passen soll. Format das als "Use when..." plus typische Trigger-Phrasen.

Schlecht: description: Helps with code review.

Gut: description: Use when the user asks you to review, check, or clean up code they just wrote. Looks for duplication and dead code. Triggers on "review this", "any improvements", "code smell".

Schreib so viel rein wie nötig damit Claude sicher matchen kann. 200 bis 400 Zeichen sind ueblich. Drueber wird's redundant, drunter triggert's unzuverlässig.

4. allowed-tools begrenzen wenn Sicherheit wichtig ist

Wenn Deine Skill Bash-Commands ausführen oder Files schreiben soll, kannst Du die Permissions per Frontmatter eingrenzen. Das ist nicht kosmetisch, das verhindert dass die Skill versehentlich rm -rf ausführt weil der LLM-Output schiefgegangen ist.

---
name: deploy-staging
description: Use when the user says "deploy to staging" or "push to staging". Runs the staging deploy script and reports back.
allowed-tools: Bash(./scripts/deploy-staging.sh), Read
---

# Deploy Staging

1. Run `./scripts/deploy-staging.sh`
2. Tail the last 50 lines of output
3. Report success or failure clearly

Der Bash(./scripts/deploy-staging.sh) Eintrag erlaubt nur exakt diesen einen Befehl. Andere Bash-Calls fragen weiter nach Bestätigung. So baust Du eine Skill die viel kann, aber nicht aus Versehen Deinen Server killt.

5. Skripte und Referenzen mitbundeln

Skills dürfen mehr als nur SKILL.md sein. Du kannst Hilfs-Files dazupacken die Claude bei Bedarf liest. Verzeichnis-Layout:

~/.claude/skills/release-notes/
├── SKILL.md
├── scripts/
│   └── git-summary.sh
└── references/
    └── tone-guide.md

In SKILL.md verweist Du dann darauf:

# Release Notes

When invoked:
1. Run `./scripts/git-summary.sh` to get commits since last tag
2. Read `./references/tone-guide.md` for our style
3. Write release notes following the tone guide

Vorteil: die Skill bleibt lesbar, Logik liegt in Scripts, Style-Guides in Referenz-Files. Bei Updates editierst Du nur den entsprechenden File, nicht alles auf einmal.

6. Skills versionieren und im Team teilen

Persoenliche Skills liegen in ~/.claude/skills/. Projekt-Skills in .claude/skills/ im Repo, die committest Du mit. Vorteil Projekt-Skills: alle im Team kriegen automatisch dasselbe Setup. Nachteil: Deine weekly-review Skill schwappt nicht ins nächste Repo.

Mein Setup: was projekt-spezifisch ist (Coding-Standards, Deploy-Skripte, interne Tone-of-Voice) liegt im Repo. Was generell nuetzlich ist (simplify, debrief, tone-fix) liegt im Home-Dir. Eine private Skill ~/.claude/skills/dailylog/ die meine eigenen Notizen managed, will ich nicht in jedem Kunden-Repo haben.

Wenn Du Skills mit Anderen teilst die nicht im selben Repo arbeiten: pack sie in ein Git-Repo, lass die Leute das clonen nach ~/.claude/skills/. Plugin-System ist Overkill bevor Du nicht 10 Skills hast.

7. Drei Skills die fast jeder braucht

Damit Du nicht bei null anfaengst, drei Skills die sich bei mir bewaehrt haben.

simplify, schon oben gezeigt. Nach jedem größeren Edit triggern lassen, faengt 80 Prozent von "ach ja das hatte ich vergessen aufzuraeumen" ab.

debrief, am Ende einer Session aufrufen. Liest die letzten 20 Aktionen, schreibt eine kurze Zusammenfassung, speichert sie in nex_summarize oder einem Memory-Tool. So weißt Du Tage später noch was in dem einen Session los war.

deutsche-texte, wenn Du oft auf Deutsch schreibst. Erzwingt echte Umlaute statt oe/ae/ue/ss. Triggert auf "schreib mir nen", "erstell einen Post auf Deutsch", "uebersetz das ins Deutsche".

---
name: deutsche-texte
description: Use when writing German text users will see (blog posts, landing pages, social media, i18n strings). Forces real umlauts ä, ö, ü, ß instead of ASCII digraphs ae, oe, ue, ss. Skip for filenames, slugs, code identifiers.
---

# Deutsche Texte

When the user asks for German text:
- Use real umlauts: ä, ö, ü, ß
- Never use ASCII digraphs: ae, oe, ue, ss
- Exception: file paths, URL slugs, code identifiers stay ASCII
- After writing, scan output once for accidental digraphs

Drei kleine Files, sofortiger Payoff.

8. Wann Skill, wann Slash-Command

Beides ist Markdown plus Frontmatter, der Unterschied ist wie es triggert. Skills feuern wenn Claude das aus dem natuerlichen Prompt erkennt. Slash-Commands feuern nur wenn Du /name tippst. Daraus folgt:

Skills sind besser für Sachen die Claude immer machen sollte wenn der Kontext passt. Code-Review nach jedem Edit. Tone-Check bei Deutsch-Texten. Debrief nach Session-Ende.

Slash-Commands sind besser für Sachen die Du explizit anstoßen willst. Deploy. Test-Run mit bestimmten Flags. Status-Snapshot wo Du genau weißt Du brauchst ihn jetzt.

Faustregel: wenn Du es vergessen wuerdest manuell zu starten, mach eine Skill. Wenn es destruktiv oder teuer ist, mach einen Slash-Command damit Du es bewusst tippen musst.

9. Die zwei Fehler die jeder am Anfang macht

Trigger zu vage formuliert. Wenn Du description: Code helper schreibst, triggert die Skill entweder bei jedem Prompt oder nie. Beides ist scheisse. Konkrete Trigger-Phrasen rein, "Use when..." Format, mind. zwei beispielhafte User-Sätze.

Body zu schwammig. Wenn der Body lautet "review the code carefully", kriegst Du Wall-of-Text zurück. Akzeptanz-Kriterien rein. Max-Anzahl Findings, konkrete Output-Form, was NICHT zurückkommen soll. Genau wie bei Slash-Commands gilt: ein Skill ist nur so gut wie der Prompt drin.

Bonus-Fehler: zu viele Skills auf einmal anlegen. Du erinnerst Dich nicht welche Du hast, sie kollidieren in Triggern, eine triggert wo eine andere sollte. Anfangen mit drei. Erst weitere bauen wenn die drei wirklich laufen.

10. Was als nächstes

Wenn die ersten drei Skills laufen, wirst Du merken dass manche Patterns sich wiederholen. Genau dann wird's Zeit für Hooks, die laufen automatisch bei Events ohne dass ueberhaupt ein Prompt nötig ist. Schau ins Playbook Hooks gegen Halluzinationen wenn Du das nächste Level willst.

Wenn Du Skills mit anderen teilen willst und die Distribution wichtig wird, schau ins Playbook MCP Server publishen, das gilt sinngemaess auch für Skill-Bundles. Und wenn Du in komplexere Workflows einsteigen willst, Erster Sub-Agent in 30 min zeigt wie Du eine Skill in einen dedizierten Sub-Agent ausweitest.

Mein Tipp: leg jetzt eine einzige Skill an, simplify, mit dem Frontmatter aus Schritt 2. Lass sie eine Woche laufen. Dann weißt Du selbst was Dir noch fehlt und welche Skill als nächste sinnvoll ist.

Source

Specs verifiziert via verify_anthropic_doc_spec gegen offizielle Doku am 2026-05-06:

• https://code.claude.com/docs/en/skills (Frontmatter-Reference, allowed-tools, Bundled Scripts, Live Change Detection, Auto-Discovery)

Konsultierte Recipes in der Academy:

• Phase 1, Recipe 1.2 "Skills", kurze Einführung mit Trigger-Beispielen
• Lesson L4-04 "Hooks und Skills", konzeptionelle Abgrenzung