Verifizierungs-Skills

Warum ein Verifizierungs-Skill der erste sein sollte, den du baust

Denk darüber nach, wie du normalerweise Claudes Arbeit überprüfst. Du bittest es, etwas zu refaktorieren, es ist fertig, und dann musst du daran denken, noch einmal nachzuprüfen. Vielleicht bittest du es, die Tests auszuführen. Vielleicht liest du den Diff selbst. Das Problem ist, dass die Überprüfung davon abhängt, dass du daran denkst, danach zu fragen. Überspringst du diesen Schritt einmal, schlüpft schlechter Code durch.

Ein Verifizierungs-Skill beseitigt diese Abhängigkeit. So sieht das aus. Du bittest Claude, etwas zu refaktorieren. Wenn es fertig ist, passt die Änderung zur Beschreibung des Skills, sodass der Skill von selbst auslöst. Von da an:

• Führt er die Testsuite aus.
• Liest er den Diff.
• Prüft er, dass kein Test nur abgeschwächt wurde, um ihn bestehen zu lassen.
• Meldet er Erfolg oder Fehlschlag, mit den beigefügten Belegen.

Der gesamte Ablauf läuft, ohne dass du danach fragst. Die Beschreibung des Skills ist das, was ihn auslöst, und einmal ausgelöst, durchläuft er jedes Mal dieselben Schritte.

Beachte die letzte Prüfung in dieser Kette. Es reicht nicht, die Tests auszuführen und Grün zu sehen. Ein Test kann still und heimlich gelockert werden, sodass er immer bestanden wird, egal was passiert. Deshalb liest der Skill den Diff und bestätigt, dass Tests nicht abgeschwächt wurden. „Fertig" heißt nicht „der Code sieht richtig aus", nur weil man den Diff gelesen hat. Fertig bedeutet, dass die Prüfungen ausgeführt und beobachtet wurden, mit explizit festgehaltenen Ergebnissen.

Dieselbe Struktur trägt jede Prozedur, die dein Team wiederholt. Eine Release-Checkliste. Ein Migrationsrezept. Eine Pre-PR-Prüfung. Die Faustregel: Wenn du dieselbe mehrstufige Anweisung zweimal eingetippt hast, ist das ein Skill.

Ein Skill-Ordner kann mehr als nur Anweisungen enthalten

Ein Skill ist nicht nur eine einzelne SKILL.md-Datei. Der Ordner darum herum kann weitere Dinge enthalten, und genau das macht Skills für die Verifizierung nützlich.

• Lege eine reference.md neben SKILL.md für detailliertes Material ab und verlinke dann von SKILL.md darauf. Claude liest sie nur, wenn diese Tiefe benötigt wird. Deine Hauptdatei bleibt kurz.
• Lege auch Skripte in den Ordner. Claude führt sie aus, statt ihren Inhalt in den Kontext zu laden. Das bedeutet, ein Skill kann sein eigenes Tooling mitbringen, etwa ein check.sh, das alle Prüfungen ausführt.

Die Erkenntnis: Halte SKILL.md selbst schlank. Verschiebe das umfangreiche Material (die langen Erklärungen und die ausführbaren Skripte) in Nebendateien. Die schlanke Datei beschreibt, was zu tun ist. Die Nebendateien enthalten die Tiefe und die Werkzeuge.

Welche Anweisungsebene welche Regel besitzt

Inzwischen hast du drei Orte, an denen du Anweisungen unterbringen kannst, und es ist leicht, sie zu vermischen. Hier ist eine schnelle Möglichkeit, sie auseinanderzuhalten.

Konventionen, die immer gelten, Dinge wie Benennungsregeln oder wo Dateien liegen, gehören in deine CLAUDE.md-Datei. Prozeduren und Referenzmaterial, die an eine bestimmte Art von Aufgabe gebunden sind, gehören in einen Skill.

Es gibt einen dritten Fall. Eine Regel, die Claude nicht überspringen darf, gehört in einen Hook, nicht in eines der beiden oben genannten. Das liegt daran, dass CLAUDE.md und Skills beide Anweisungen sind, denen Claude folgt, während ein Hook Code ist, der tatsächlich ausgeführt wird. Wenn es nicht akzeptabel ist, die Regel zu überspringen, überlasse es nicht dem Befolgen von Anweisungen.

Die Zusammenfassung

Ein Skill ist ein Ordner mit einer SKILL.md darin: ein Name, eine Beschreibung, die ihn auslöst, und die Prozedur selbst. Nur die Beschreibungen werden in den Kontext geladen, bis ein Skill benötigt wird, sodass es kaum Kosten verursacht, jede Prozedur zu verpacken, die du wiederholst.

Beginne mit der Verifizierung. Baue den Skill, checke ihn in die .claude/skills deines Projekts ein, und jetzt erbt das gesamte Team denselben Schritt. Die Arbeit aller wird auf dieselbe Weise überprüft, automatisch, ohne dass jemand daran denken muss, danach zu fragen.