Diese Anleitung ist bewusst allgemein gehalten — das Rezept dahinter funktioniert für jede Domäne, nicht nur für die Schweizer Java-Jobsuche aus der Bewerbungspipeline. Am Ende steht eine kopierbare Vorlage für eine eigene Skill.
SKILL.md, references/ und scripts/ nach genau diesem Muster für dich entwerfen — beschreib einfach deinen Workflow in eigenen Worten und lass daraus einen ersten Entwurf schreiben. Die Schritte unten helfen dir dann, das Ergebnis zu prüfen und gezielt nachzubessern, statt bei null anzufangen.scripts/-Verzeichnis braucht (z.B. um wie im Beispiel ein PDF zu rendern), muss Python 3 auf dem System installiert sein. Ohne Python kann dir ein Assistent das Skript zwar schreiben, aber niemand kann es tatsächlich ausführen.Eine Skill ist nur ein Ordner. Eine Datei ist Pflicht, zwei weitere sind optional und existieren nur, damit SKILL.md selbst schlank bleibt:
| Frontmatter-Feld | Wirkung |
|---|---|
name | Eindeutiger Bezeichner in kebab-case, entspricht dem Ordnernamen. |
description | Das Einzige, was der Agent sieht, bevor er entscheidet, die Skill zu laden. Muss wie ein Filter funktionieren: was sie tut + wann genau sie auslösen soll, mit konkreten Beispielsätzen. |
Bevor du eine Zeile SKILL.md schreibst: zeichne die Etappen deines eigenen Workflows auf, so wie hier Entdeckung → Erstellung → Ablage. Jede Etappe wird später eine eigene Skill.
Eine Etappe pro Skill hält jede Skill fokussiert und macht Trigger-Sätze eindeutig — eine Skill, die "alles" macht, feuert entweder nie zuverlässig oder ständig.
Leg einen festen Wurzelordner an und darunter: einen Ordner für Dinge, die sich nie ändern (CV, Zertifikate), einen Ordner für vergängliche Einzelfälle, die nach Gebrauch gelöscht werden dürfen, einen Ordner für abgeschlossene Fälle mit je einem eigenen Unterordner, und eine einzelne Datei an der Wurzel, die niemals gelöscht wird und als permanentes Gedächtnis dient.
Diese Trennung — vor allem die permanente Gedächtnisdatei — ist der Kern, der später Duplikate verhindert.Frontmatter mit name und description, danach Freitext: Rolle, Leitplanken, Workflow. Halte die description an ein Muster: was die Skill tut + wann genau sie auslösen soll (3–5 Beispielsätze) + wann nicht.
Nenne konkrete Beispielsätze in den Sprachen, die Nutzer tatsächlich tippen, und grenze explizit gegen Nachbar-Skills ab. Im echten Beispiel sagt ch-it-jobsuche ausdrücklich, dass sie nicht für eine bereits bekannte Anzeige zuständig ist — das übernimmt ch-it-bewerbung.
Leg fest, welche Kriterien nie aufgeweicht werden dürfen, und welche in fester Reihenfolge gelockert werden dürfen, wenn zu wenig herauskommt. Schreib "nie erfinden" explizit fest, sobald die Skill mit echten Daten über eine Person oder Firma arbeitet — das ist die wichtigste Leitplanke im ganzen System.
Alles, was lang, aber nicht immer gebraucht wird (Regionenliste, Ausgabeformat, Tech-Stack-Referenz), kommt in eine eigene Datei unter references/ und wird aus SKILL.md nur verlinkt, z.B. [regionen.md](references/regionen.md). Diese Dateien laden nur bei Bezug und kosten sonst nichts.
Für alles, was als Code zuverlässiger läuft als als Text-Anweisung (z.B. PDF-Rendering), leg ein scripts/-Verzeichnis an. SKILL.md beschreibt nur, wann und wie das Skript aufgerufen wird — die Logik selbst lebt im Skript.
Für ein mehrstufiges System brauchst du einen gemeinsamen Zustand, den alle Skills lesen und nur ergänzen — nie überschreiben. Eine feste, kleine Menge an Status-Werten reicht (z.B. "Gefunden", "Erledigt"). Jede Skill liest diese Datei zuerst, bevor sie etwas Neues vorschlägt oder erstellt.
Leg den fertigen Ordner unter ~/.claude/skills/<name>/ ab. Teste mit den Beispielsätzen aus deiner description: löst die Skill zuverlässig aus? Löst sie fälschlich auch bei Anfragen aus, die eigentlich einer Nachbar-Skill gehören? Schärfe die description iterativ nach — das ist normal, keine Skill trifft beim ersten Versuch perfekt.
Die Struktur unten spiegelt genau das Muster der drei echten Skills aus der Bewerbungspipeline (Rolle, Leitplanken, harte Kriterien, Workflow, Sprache) — mit Platzhaltern statt konkretem Inhalt.
---
name: <deine-skill-in-kebab-case>
description: <Ein bis zwei Sätze, was die Skill tut>. Use this skill whenever <Trigger-Beispiel 1>, <Trigger-Beispiel 2>, or <Trigger-Beispiel 3> — even if <Randfall, der trotzdem zählt>. This skill does NOT handle <Abgrenzung zur Nachbar-Skill> — use <andere-skill> for that instead.
---
# <Skill-Name>
## Rolle
<In welcher Rolle agiert die Skill? Z.B. "Du agierst als ..." — das setzt Ton und
Kompetenzrahmen für den Rest der Datei.>
## Nie erfinden / Leitplanken
<Welche Angaben dürfen nie erfunden werden? Was passiert, wenn eine zentrale Grundlage
komplett fehlt (nachfragen, bevor gearbeitet wird) gegenüber wenn nur ein Detail fehlt
(liefern + kurz nachfragen)?>
## Harte Kriterien (nie aufweichen)
1. <Kriterium, das nie verhandelbar ist>
2. <ggf. ein zweites>
## Workflow
1. <Schritt 1>
2. <Schritt 2>
3. <...>
## Referenzen
- [references/<datei>.md](references/<datei>.md) — <wofür diese Datei da ist>
## Sprache
<Antwortet die Skill in der Sprache des Users, schreibt aber Dokumente/Dateien in einer
festen Sprache? Das hier festhalten, statt es implizit zu lassen.>SKILL.md statt in references/ blähen jede Anfrage auf, auch wenn der Punkt gar nicht gebraucht wird.render_letter.py-Beispiel — vor dem Teilen immer durch Platzhalter ersetzen.Fertig mit der Anleitung? Sieh dir das fertige Beispiel an.
Zur Bewerbungspipeline →