Ich habe Matts Skill-Quellcode auseinandergenommen: Vier eiserne Regeln für gute Skills – und dabei erwischt, wie er caveman gelöscht hat

In 30 Sekunden

Ein verlässlicher Skill hat nur ein Ziel: predictability (Vorhersagbarkeit) – gleiche Lage, gleicher Ablauf, jedes Mal. Vier eiserne Regeln dienen genau dem, jede mit einem Gegenbeispiel:

Wie es ausgelöst wird: Soll das Modell selbst entscheiden, wann es greift (und dafür dauerhaft Kontext belegen) – oder startet es nur, wenn du es ausdrücklich rufst? Falsch gewählt = Kontext umsonst belegt.

Wie viel rein darf: In die SKILL.md kommt nur, was auf jedem Pfad gebraucht wird; der Rest wandert nach außen. Gegenbeispiele: sprawl (Wucherung), sediment (Ablagerung).

Welche Wörter: Ein leading word (Leitwort) borgt sich ein Konzept, das die KI längst kennt, und verankert damit ein ganzes Verhalten. Gegenbeispiele: no-op (wirkungslos), duplication (Doppelung).

Wie es abschließt: Jeder Schritt braucht ein nachprüfbares completion criterion (Abschlusskriterium). Gegenbeispiel: vorzeitig abbrechen.

Alle vier stammen aus Matt Pococks writing-great-skills; alle vier Gegenbeispiele sind echte Fälle aus seiner eigenen Überarbeitungshistorie.

Ich habe Matts Skill-Quellcode durchgekämmt

Du tippst /, und der eine Skill bringt jedes Mal die Sache zu Ende, der andere mal so, mal so. Der Unterschied ist kein Glück, sondern Handwerk.

Niemand hat Zeit, sich durch Skill-Quellcode zu wühlen – ich schon. Ich habe mir Matt Pocock vorgenommen, den Mann hinter einem ganzen Satz KI-Kollaborations-Skills. Eins davon ist ein hübscher Kunstgriff: ein Skill, der erklärt, wie man gute Skills schreibt (writing-great-skills). Diesen einen, plus den Quellcode und die Commit-Historie von Dutzenden seiner Skills, habe ich durchgelesen und vier eiserne Regeln herausgezogen.

Nur vier – aber zu jeder gibt es ein Gegenbeispiel, und keins davon ist erfunden. Alle stammen aus Matts eigenen Commits: Fehler, die er selbst gemacht und selbst wieder ausgebügelt hat. Wenn sogar er zurückgehen und korrigieren muss, sind die Fallen echt.

Lern die vier: Du baust bessere Skills – oder klaust dir, ganz ohne selbst einen zu schreiben, sein Denkmuster, wie man einer zufälligen KI Vorhersagbarkeit abringt.

Gute Skills haben nur einen Maßstab: predictability

Ein Modell ist stochastisch – stell zweimal dieselbe Frage, und die Antwort weicht ab. Der ganze Sinn eines Skills ist, dieser Zufallsmaschine Vorhersagbarkeit abzupressen: dass sie jedes Mal denselben Ablauf geht.

“A skill exists to wrangle determinism out of a stochastic system.” — Matt, writing-great-skills

Wohlgemerkt: der Ablauf, nicht das Ergebnis. Brainstorming soll jedes Mal andere Einfälle ausspucken – aber die Art, wie es sie entfaltet, muss stabil bleiben.

Ob ein Skill gut ist, entscheidet dieser eine Maßstab: predictability. Die vier Regeln darunter dienen alle ihm.

Regel 1 · Wie es ausgelöst wird: rufst du, oder entscheidet das Modell?

Die erste Entscheidung beim Skill-Schreiben: Soll das Modell selbst urteilen, wann der Skill greift – oder startet er nur, wenn du ihn ausdrücklich rufst? Technisch ist das ein einziger Schalter: schreibst du eine description oder nicht.

Vom Modell ausgelöst (model-invoked, mit description): Die KI sieht den Skill selbst und entscheidet selbst, wann sie ihn nutzt. Der Preis: Diese description hängt in jeder Gesprächsrunde im Kontext, frisst token und Aufmerksamkeit – das ist Kontextlast.
Vom Nutzer ausgelöst (user-invoked, mit disable-model-invocation): Die description wird weggenommen, das Modell sieht den Skill nicht; er startet nur, wenn du seinen Namen tippst. Kostet die KI keinen Funken Kontext, dafür verlagert sich der Preis zu dir: Du musst dich erinnern, dass er existiert – das ist kognitive Last.

Das Prinzip: Nur wenn das Modell (oder ein anderer Skill) ihn selbst erreichen muss, lass ihn automatisch auslösen; sonst auf manuell stellen und die Kontextlast geschenkt mitnehmen.

Gegenbeispiel: Ein Skill, den du in Wahrheit nur von Hand tippst, behält trotzdem seine description – und belegt rundenweise umsonst deinen Kontext.

Echter Fall: Diese Abwägung hat Matt selbst hin- und hergewogen. Den disable-model-invocation-Schalter bei grill-with-docs hat er erst gelöscht – das Modell durfte selbst auslösen –, in der neuesten Version aber wieder hinzugefügt, zurück auf rein manuell. Derselbe Schalter, gelöscht und wieder dran. Das zeigt: “automatisch oder manuell” ist eine echte Abwägung, kein Schalter, den man im Vorbeigehen umlegt.

So nutzt du es: Standardmäßig manuell, spar zuerst den Kontext; gib eine description erst, wenn du das Modell wirklich selbst urteilen lassen willst, dass “jetzt der Moment ist”. Der Selbsttest in einem Satz: “Wer muss diesen Skill erreichen?” Lautet die Antwort “nur ich”, dann manuell.

Häufst du zu viele manuelle Skills an, behältst du sie selbst nicht mehr im Kopf – die kognitive Last platzt. Die Lösung ist ein weiterer Routing-Skill: ein manueller Skill, der nichts tut, als die anderen aufzulisten und dir zu sagen, wann du welchen nimmst. Matts ask-matt macht genau das.

Regel 2 · Wie viel rein darf: in die SKILL.md nur, was auf jedem Pfad gebraucht wird

Informationsleiter: Was auf jedem Nutzungspfad gebraucht wird, kommt in den Fließtext der SKILL.md; was nur in manchen Fällen greift, wandert nach außen in eine eigene verlinkte Datei, und im Fließtext bleibt nur ein Zeiger “bei Bedarf dort nachschlagen”. Das Ziel: die oberste Ebene bleibt jederzeit übersichtlich – staut sich zu viel, ertrinkt die Aktion, die die KI eigentlich ausführen soll.

Zwei Gegenbeispiele, beide mit Namen:

sprawl (Wucherung): Alles in eine Datei stopfen, immer länger. Selbst wenn jede Zeile stimmt und nichts doppelt ist – allein die Länge ist die Krankheit; die KI muss sich erst durch einen Wust von Wörtern wühlen, bevor sie die Aufgabe erreicht.
sediment (Ablagerung): Altes wird nur ergänzt, nie gelöscht, Schicht über Schicht; Nachgeborene müssen wie Archäologen graben, um zu finden, was noch gilt.

Echter Fall: grill-with-docs war früher ein fetter Monolith – Verhörlogik, Dokumentformat, ADR-Vorlage, alles in einer Datei. Matt hat es in drei zerlegt: die Verhörhälfte zu grilling, die Dokumenthälfte zu domain-modeling, und auch die Formatdateien für ADR und Glossar nach domain-modeling ausgelagert; grill-with-docs blieb eine einzeilige dünne Hülle, die beide verknüpft. Genau so nimmt die Informationsleiter einem überladenen Skill Gewicht ab.

So nutzt du es: Nach dem Schreiben zurückgehen und kürzen. Bei jeder Zeile fragen “Braucht man die auf jedem Pfad?” Wenn nein, entweder auslagern oder direkt streichen. Eine grobe, aber brauchbare Faustregel – je kürzer die SKILL.md, je mehr sie auf den Stamm reduziert ist, desto verlässlicher meist.

Regel 3 · Welche Wörter: borg dir Konzepte, die die KI schon kennt

Diese Regel ist die widersinnigste; ich selbst habe eine Weile gebraucht, bis es klick gemacht hat.

leading word (Leitwort): ein fertiges Konzept, das die KI im Training längst gelernt hat und das eine ganze Wolke an Assoziationen mitbringt. Nicht auf Fachbegriffe beschränkt – Spiele, Militär, Medizin, Alltagsredewendungen zählen alle, solange die KI es auf Anhieb versteht. Schreibst du es in den Skill, musst du nichts erklären; das Wort ruft das ganze Verhalten ab.

Beispiele (alle geborgt, keins von Matt erfunden):

fog of war (Kriegsnebel, aus Spielen/Militär) → die KI versteht sofort “die Sicht nach vorn ist trüb, handle mit dem lokalen Wissen, das du hast”.
tracer bullets (Leuchtspurgeschosse, aus The Pragmatic Programmer) → “erst eine dünnste Ende-zu-Ende-Spur durchziehen, Richtung prüfen, dann ausbauen”.
triage (Sichtung, aus der Notaufnahme), caveman (Höhlenmensch = wortkarg), grilling (Verhör) – fertige Konzepte einfach mitnehmen.

Wo du sie findest: Erst das gewünschte Verhalten klar benennen, dann rückwärts fragen “welches fertige Wort, welche Anspielung ist schon genau das?” Fisch in Redewendungen, Klassikern, Methodenlehren, Spiel und Militär, Medizin und Sport. Was die KI gelesen hat, ist dein Wortschatz.

Wie du prüfst – der no-op-Test: Schreib das Wort allein hinein, ohne Erklärung. Tut die KI dann, was du wolltest? Ja = ein echtes Leitwort, das auf dem Vorwissen der KI reitet; brauchst du noch eine lange Erklärung, bis sie es kapiert = das Wort leistet nichts und fällt in die Gegenbeispiele:

no-op (wirkungslos): geschrieben, aber die KI hätte es ohnehin getan. Etwa “be thorough” (gründlich sein) – die KI ist von Haus aus schon etwas gründlich, die Zeile ist quasi nicht da. Der Fix ist keine Erklärung, sondern ein härteres Wort: “be thorough” → “relentless” (unerbittlich).
duplication (Doppelung): dieselbe Aussage mehrfach geschrieben. Kostet Pflege (eine Stelle ändern heißt alle ändern) und bläht das Gewicht dieser Aussage in den Augen der KI über Gebühr auf.

Echter Fall: An diesen beiden hat Matt wirklich das Messer angesetzt. Beim Straffen des review-Skills steht im Commit-Text schwarz auf weiß “single-sourced rules, no-op cuts” – doppelte Regeln zusammengeführt, wirkungslose Zeilen gestrichen. Er ist sogar an writing-great-skills selbst zurückgegangen und hat eigens “no-ops bis auf Satzebene gejagt”.

So nutzt du es: Beschreib das gewünschte Verhalten nicht mit einem ganzen Satz, sondern fang es mit einem fertigen Wort ein; dann zieh jedes Adjektiv und Adverb einzeln durch den no-op-Test – ändert sich das Verhalten der KI, wenn du es löschst? Was sich nicht ändert, ist Wasser, raus damit.

Regel 4 · Wie es abschließt: jeder Schritt braucht ein nachprüfbares Abschlusskriterium

Ein Skill ist oft eine Kette von Schritten. Ob ein Schritt wirklich fertig ist, entscheidet das completion criterion (Abschlusskriterium).

Ein gutes Abschlusskriterium hat zwei Eigenheiten: erstens nachprüfbar – die KI kann objektiv feststellen, ob “fertig” oder “nicht fertig”, statt nach Gefühl zu urteilen; zweitens erschöpfend, wo es sein muss – etwa “jedes geänderte Modell muss benannt werden”, nicht das schwammige “eine Änderungsliste erstellen”.

Gegenbeispiel · premature completion (vorzeitiger Abschluss): Ist das Abschlusskriterium verwaschen (“Konsens erreicht”, “ausreichend verstanden”), findet die KI keine klare Grenze; ihre Aufmerksamkeit rutscht von “die Aufgabe zu Ende bringen” zu “schnell als erledigt verbuchen”, und sie zieht weiter, ohne wirklich fertig zu sein.

Dazu ein Begleiteffekt: Sieht die KI, welche Schritte noch in der Schlange stehen, wird der Sog “schnell fertig werden und weiter” stärker. Eine Gegenmaßnahme: die folgenden Schritte in einem anderen Skill verstecken, damit der aktuelle Schritt nicht ans Weiterhetzen denkt.

Echter Fall: Die Paradedisziplin von grilling (die aus grill-with-docs herausgelöste Verhörhälfte) ist genau das – eine Frage nach der anderen, die nächste erst, wenn du die vorige beantwortet hast; sein leading word ist “relentless” (unerbittlich). Dass damals Verhör und Dokumentschreiben in zwei Skills getrennt wurden, folgt derselben Logik: Die KI soll beim Verhören nicht schon ans “schnell fertig fragen, dann das Dokument schreiben” denken, sonst pfuscht sie den Abschluss. Getrennt bleibt beim Verhörschritt nur Verhör übrig.

So nutzt du es: Schreib die Abschlussbedingung jedes Schritts nachprüfbar, am besten erschöpfend (“jedes X muss …”, nicht “passt schon”); ertappst du die KI dabei, dass sie bei einem Schritt ständig vorprescht, schieb die nachfolgenden Schritte in einen anderen Skill.

Mit den vier Regeln auf einen seltsamen Fall: Warum hat er caveman gelöscht?

Nimm die vier Regeln und schau dir einen echten Tatort an.

Den caveman aus unserem ersten Artikel (die KI zum Schweigen bringen, nur die Sache sagen) findest du in Matts ursprünglichem Repo heute nicht mehr – gelöscht. Die Löschspur ist nüchtern:

Ende Mai hat er die ganze caveman-SKILL.md gelöscht, Commit-Text in einer Zeile: “streamline productivity skills” (Produktivitäts-Skills verschlanken).
Zwei Wochen später hat er die in README und Plugin-Liste verbliebenen Verweise weggeräumt.
Kein neuer Skill übernimmt. Einfach gelöscht.

Warum? Miss es mit den vier Regeln, und es wird klar: caveman ist ein manueller Skill, er belegt deine kognitive Last – du musst dich erinnern, dass es ihn gibt. Aber das bisschen, das er tut (sich kurzfassen, Floskeln streichen), holst du dir mit einer einzigen Anweisung oder einem globalen Ausgabestil; es lohnt kein eigenes “Fach, das du dir merken musst”. Ihn zu löschen heißt, auf Ebene der gesamten Skill-Sammlung zu beschneiden – die Last wegzuschneiden, die sich nicht rechnet.

Eine ehrliche Einschränkung: Matts Commit-Text sagt nur “streamline”, ohne Begründung – das ist meine Deutung mit diesem Raster. Aber das Raster liefert eine in sich stimmige Erklärung – und genau das ist sein Nutzen.

Die vier Regeln sind nicht nur eine Checkliste fürs Skill-Schreiben; sie erklären auch, warum ein Skill in der echten Welt lebt oder stirbt.

Spickzettel

Regel	So machst du’s	Gegenbeispiel	Selbsttest in einem Satz
Wie es ausgelöst wird	description nur, wenn das Modell ihn selbst erreichen muss, sonst manuell	Kontextlast umsonst belegt	”Wer muss diesen Skill erreichen?”
Wie viel rein darf	In die SKILL.md nur, was auf jedem Pfad nötig ist, Rest auslagern	sprawl / sediment	”Braucht man diese Zeile auf jedem Pfad?”
Welche Wörter	Ein fertiges Konzept als leading word borgen, ein Wort verankert ein Verhalten	no-op / duplication	”Ändert sich das Verhalten der KI, wenn ich die Zeile lösche?”
Wie es abschließt	Jeder Schritt mit nachprüfbarem, erschöpfbarem Abschlusskriterium	premature completion	”Kann die KI objektiv feststellen, ob der Schritt fertig ist?”

Der einzige Maßstab: predictability – gleiche Lage, gleicher Ablauf, jedes Mal. Alle vier dienen ihm.

Zum Schluss

Vier Regeln, beim Skill-Schreiben direkt anwendbar. Selbst wenn du nie im Leben einen Skill baust – das Denkmuster dahinter, wie man einer zufälligen KI Vorhersagbarkeit abringt, macht auch dein alltägliches Arbeiten mit der KI stabiler. Am Ende ist das der wahre Gewinn beim Abschauen vom Meister: Du nimmst nicht ein paar Regeln mit, sondern sein Urteil.

Quelle: Dieser Artikel zerlegt Matt Pococks writing-great-skills (samt GLOSSARY.md), Repo mattpocock/skills, MIT-Lizenz, Version 6eeb81b. Die “echten Fälle” im Text lassen sich alle in der Commit-Historie des Repos nachprüfen (Commit-Links beigefügt).

Gleiche Serie: Erster Artikel · caveman · Zweiter Artikel · grill-with-docs