Schreiben Sie Ihren ersten Skill

Den Aufbau lernen, ein geprüftes Beispiel studieren, die Datei unten erzeugen.

Abstract

Ein Skill ist eine Methode in Klartext, die Ihr Leser einem KI-Assistenten übergibt. Einen zu schreiben ähnelt eher dem Verfassen einer Arbeitsanweisung für eine kluge neue Kollegin als dem Herumprobieren an Prompts: Sie legen die Eingaben fest, die Schritte, den Ausgabevertrag und die Regeln, die tragen, wenn es mehrdeutig wird. Dieses Dokument vermittelt den Aufbau, zeigt ein geprüftes Beispiel, listet die häufigen Ablehnungsgründe auf und endet mit einem Editor, der eine spezifikationskonforme Datei erzeugt.

1.Aufbau eines Skills

1. Frontmatter. name in Kebab-Case, identisch mit dem Dateinamen. description erfüllt zwei Aufgaben in einem Absatz: was der Skill tut und — entscheidend — wann er greifen soll („Use when asked to…"). Assistenten wählen Skills über dieses Feld; eine vage Beschreibung ergibt einen Skill, der ewig schläft. Version, Lizenz und Autoren schließen den Block ab.
2. Identitätsabsatz. Zwei bis drei Sätze nach dem Titel, in der zweiten Person: wer der Assistent wird und wobei er keine Abstriche macht. Das ist Tonfall und Maßstab in einem Atemzug: „You write commit messages worthy of the permanent record."
3. Inputs. Die nummerierte Liste dessen, was der Skill braucht, mit markierten Pflichtangaben und einer Regel für Lücken (nachfragen und anhalten, oder mit ausgewiesenen Annahmen weitermachen). Einmal fragen — ein Skill, der in Runden verhört, zermürbt seine Nutzer.
4. Method. Nummerierte Schritte, jeder entscheidbar: eine Anweisung, der der Assistent folgen oder die er prüfen kann, mit ausformulierten Ermessensregeln („wenn X über Y liegt, tue Z"). Schritte wie „sei gründlich" geben den schwierigen Teil an den Zufall zurück.
5. Output format. Der Vertrag: Abschnitte, Reihenfolge, Längen dort, wo sie zählen. Zwei Läufe desselben Skills sollten dieselbe Form ergeben — der Formatabschnitt macht einen Skill wiederholbar statt improvisiert.
6. Rules. Die Invarianten, die jeden Grenzfall überstehen: was abgelehnt wird, was gekennzeichnet wird, was wie degradiert. Halten Sie fest, wie sich der Skill verhält, wenn eine Fähigkeit fehlt — „mit Begründung als n. v. markieren" schlägt einen geratenen Erfolg.

2.Ein geprüftes Beispiel, kommentiert

---
name: honest-status-report
description: Status reports that declare failures,
  blockers and partial results as visibly as successes.
  Use when asked for a status update, a progress report,
  or an end-of-task summary.
---✓ review — name matches filename; description states the trigger ("Use when…"): the assistant knows when to wake this skill
2. Classify each item, strictly:
   - Done & verified — completed AND checked.
   - Failed / errored — attempted, went wrong.
   - Silently skipped — planned, then untouched.✓ review — each category is decidable: two readers classify the same item the same way
The order is fixed: problems before achievements.✓ review — an output contract, stated as a rule: the shape survives every run

3.Was in der Prüfung abgelehnt wird

Jede Einreichung wird nach bestandenen automatischen Prüfungen von einem Maintainer Zeile für Zeile gelesen. Das sind die wiederkehrenden Ablehnungsgründe — schreiben Sie mit dieser Liste vor Augen:

1. REJECTED — Nicht entscheidbare Schritte. „Sorgfältig analysieren", „hilfreich sein", „nach bestem Ermessen" ohne jedes Kriterium. Ein Schritt verdient seinen Platz, wenn der Assistent feststellen kann, ob er ihn befolgt hat.
2. REJECTED — Fehlende Degradation. Die Methode setzt Webzugriff, Codeausführung oder Dateiwerkzeuge voraus und sagt nichts darüber, was auf einem Assistenten ohne sie geschieht. Nennen Sie den Rückfall.
3. REJECTED — Versteckte oder kodierte Inhalte. Base64-Blobs, Zero-Width-Zeichen, Anweisungen zum Nachladen entfernter Inhalte zur Laufzeit. Die Abmachung lautet: schlichtes, lesbares Markdown — was der Leser sieht, führt der Agent aus.
4. REJECTED — Exfiltrationswege. Schritte, die Nutzerdaten irgendwohin senden. Ein Skill verarbeitet, was er bekommt, an Ort und Stelle.
5. REJECTED — Anbieterspezifische Formulierungen. „Nutze das WebFetch-Tool", „rufe Code Interpreter auf". Benennen Sie Fähigkeiten („wenn Live-Webzugriff verfügbar ist"), dann läuft der Skill auf jedem Assistenten.
6. REJECTED — Marketing in der Methode. Superlative über den Skill selbst, Produktlinks, Eigenwerbung. Die Methode spricht durch ihre Schritte.
7. REJECTED — Fehlender Ausgabevertrag. Zehn präzise Methodenschritte und kein Wort dazu, wie das Ergebnis aussieht. Der Formatabschnitt ist die halbe Miete.

4.Der Editor — Ihre Datei erzeugen

Füllen Sie die Abschnitte aus; der Editor setzt eine spezifikationskonforme .md zusammen. Alles läuft in dieser Seite — Ihr Entwurf berührt keinen Server. Das Formular bleibt englisch: was Sie hineinschreiben, wird der Skill, und die Skills dieser Bibliothek sind englisch.

5.Einreichen

1. Lassen Sie Ihren Skill zuerst an einem echten Fall laufen — die Probeausgabe zeigt, wo die Methode dünn ist.
2. Forken Sie die Bibliothek, legen Sie Ihre Datei unter skills/<category>/<name>.md ab und öffnen Sie einen Pull Request pro Skill.
3. Signieren Sie jeden Commit mit git commit -s. Dieses eine Flag fügt die Zeile Signed-off-by hinzu, mit der Sie bestätigen, die Arbeit unter Apache-2.0 freigeben zu dürfen — das Developer Certificate of Origin. Eine Pflichtprüfung kontrolliert das, der Pull Request lässt sich also zusammenführen, sobald sie da ist. Schon ohne committet? git commit --amend -s --no-edit für den letzten, git rebase --signoff main für mehrere, dann git push --force-with-lease.
4. Die automatischen Prüfungen laufen, dann liest ein Maintainer sie Zeile für Zeile. Die Nennung steht in der Datei selbst.