Zum Hauptinhalt springen

Schreibe deinen ersten Skill von A bis Z

Fortgeschritten
What you'll learn
  • Einen funktionierenden Skill von Grund auf bauen und nachweisen, dass er tatsächlich aktiviert wird
  • Eine description schreiben, die zum richtigen Zeitpunkt auslöst — das eine Feld, das entscheidet, ob ein Skill überhaupt je läuft
  • Entscheiden, wann ein Helfer-Skript für deterministische Datenerhebung sinnvoll ist
  • Einen Skill diagnostizieren, der nie auslöst, und die drei Fallstricke kennen, die das verursachen

Lass uns einen funktionierenden Skill von Grund auf bauen und nachweisen, dass er aktiviert wird. Wir erstellen einen kleinen Skill für "Changelog-Einträge" — generisch und wiederverwendbar.

Schritt 1 — Den Ordner erstellen​

Den Skill-Ordner erstellen

mkdir -p .claude/skills/changelog-entry

(Verwende ~/.claude/skills/… für einen persönlichen Skill über alle Projekte hinweg.)

Schritt 2 — SKILL.md schreiben​

.claude/skills/changelog-entry/SKILL.md:

---
name: changelog-entry
description: Use when the user wants to turn recent git commits into a Keep a Changelog entry.
---

# Changelog Entry

When asked for a changelog entry:
1. Run `git log --oneline -20` to see recent commits.
2. Group them into Added / Changed / Fixed / Removed (Keep a Changelog style).
3. Write concise, user-facing bullets (not raw commit messages).
4. Output only the formatted entry.

Die description ist der Auslöser — formuliere sie als "Use when…", damit Claude den Skill zum richtigen Zeitpunkt lädt.

Schritt 3 — (Optional) ein Helfer-Skript hinzufügen​

Skills können Skripte mitliefern. Füge scripts/recent.sh hinzu und verweise aus der SKILL.md darauf, wenn du eine deterministische Datenerhebung möchtest:

#!/usr/bin/env bash
git log --oneline -20

Schritt 4 — Nachweisen, dass er auslöst​

Starte eine Sitzung und probiere den Prompt unten. Claude sollte die Absicht erkennen, den Skill laden und seinen Schritten folgen. Wenn er nicht aktiviert wird, ist deine description wahrscheinlich nicht spezifisch genug darin, wann er verwendet werden soll — schärfe sie nach.

Nachweisen, dass der Skill auslöst

Draft a changelog entry for recent work.

Schritt 5 — Ihn teilen​

Bündle ihn (mit anderen) zu einem Plugin, damit dein Team ihn in einem Schritt installiert — oder steuere ihn zu den Skill-Packs von AILmanac bei.

Fallstricke​

  • Vage description → löst nie aus (oder immer). Sei spezifisch.
  • Zu viel in einem Skill → halte ihn auf eine klare Aufgabe begrenzt.
  • Secrets in einem geteilten Skill → niemals; siehe Code von Drittanbietern überprüfen.
Key takeaways
  • Ein Skill ist ein Ordner plus eine SKILL.md — .claude/skills/<name>/ für das Projekt, ~/.claude/skills/ für jedes Projekt
  • Die description ist der Auslöser. Formuliere sie als "Use when…", damit Claude den Skill im richtigen Moment lädt
  • Skills können Skripte mitliefern — nutze eines, wenn du eine deterministische Datenerhebung willst, statt Claude den Befehl improvisieren zu lassen
  • Weise die Funktion nach, indem du die Absicht promptest, nicht indem du den Skill beim Namen nennst. Wenn er nicht auslöst, ist die description nicht spezifisch genug darin, WANN
  • Halte einen Skill auf eine klare Aufgabe begrenzt und lege niemals Secrets in einen Skill, den du teilst

Teste dich selbst

0/3
  1. Dein Skill wird nie aktiviert, egal was du fragst. Welches Feld ist mit ziemlicher Sicherheit das Problem?
  2. Du willst einen Changelog-Skill in jedem Projekt verfügbar haben, nicht nur in diesem. Wohin gehört er?
  3. Warum ein Helfer-Skript wie scripts/recent.sh mit einem Skill mitliefern?

Weiter​