4. Skills und Slash-Befehle — welche Wiederholung es wert ist, auf eine Zeile verdichtet zu werden

Dies ist Teil 4 der Alice Way-Serie. Die Teile 2 Persona-Design und 3 Gedächtnissystem behandelten, wo Geist eingeschrieben und wo er gehalten wird. Dieser Beitrag behandelt die nächste Schicht — wie man die wiederkehrenden Bewegungen des Geistes auf eine einzige Zeile verdichtet.

0. Ein Skill verdichtet wiederkehrende Geistbewegung auf eine Zeile

Im Geist eines Betreibers gibt es zwei Arten von Inhalten. Die eine Art ist „was muss ich jetzt entscheiden." Die andere ist „welches Verfahren entfalte ich um diese Entscheidung herum." Das Erste ändert sich jedes Mal. Das Zweite ist oft dasselbe.

Wenn dasselbe Verfahren jeden Tag wiederholt wird und man es dem Kollaborateur jeden Tag mit denselben Worten erklärt, hat sich dieses Verfahren bereits zu einem Geistmuster verfestigt. Eine verfestigte Bewegung verdient einen einzeiligen Namen.

Skills und Slash-Befehle sind dieser Name. Sie verdichten eine wiederkehrende Geistbewegung in eine einzige Wort-Invokation. Namen existieren, damit dasselbe Verfahren nicht jedes Mal in Sprache entrollt werden muss.

Dieser Beitrag ist eine Sammlung von Kriterien dafür, welche Wiederholungen diesen Namen verdienen und wie man diese Namen gestaltet.

Der „Skill"-Mechanismus selbst ist aus dem Skill-System von Anthropic Claude Code entlehnt. Dieser Beitrag ist die Aufzeichnung, wie dieser Mechanismus verwendet wird — keine Erfindung davon.

1. Promotionskriterien — welche Wiederholungen zu Skills werden

Nicht jedes tägliche Verfahren sollte ein Skill werden. Nur die, die alle fünf davon bestehen, bekommen einen einzeiligen Namen.

1.1 Hat es sich mindestens zweimal wiederholt?

Einmal ist ein Zufall. Zweimal ist ein Muster. Dasselbe Verfahren muss mindestens zweimal gelaufen sein, um sich zu qualifizieren.

Dieses Kriterium ist das einfachste, wird aber am häufigsten verletzt. Es blockiert den Impuls „ich werde das wahrscheinlich oft tun, ich erstelle vorher einen Skill." Künftige Wiederholung ist eine Vermutung; vergangene Wiederholung ist eine Tatsache. Nur auf Basis von Fakten promovieren.

1.2 Sind Start und Ende klar definiert?

Ein Skill benötigt eindeutige Start- und Endbedingungen. „Ein Projekt betreten", „eine Sitzung abschließen", „nach dem Linten bauen" — das hat klare Grenzen. „Code schreiben" hat in keine Richtung eine, und wird kein Skill.

Ohne klare Grenzen weiß der Kollaborateur nicht, wo er nach dem Aufruf aufhören soll. Ein Skill mit unscharfem Ende wird vom Betreiber jedes Mal manuell abgebrochen.

1.3 Ist der Invokationszeitpunkt entscheidbar?

Invokation gibt es in zwei Varianten. Betreiberbewusst (Slash-Befehle) oder systemgesteuert (Hooks — nächster Beitrag). So oder so muss der Zeitpunkt der Invokation entscheidbar sein.

„Es kommt auf den Moment an" ist kein Skill. Das legt das Urteil jedes Mal auf den Kollaborateur zurück, und dieses Urteil selbst verlangt frischen Geist.

1.4 Nimmt es dieselbe Eingabe (oder nur einfache Argumente)?

Die Eingabe muss einfach sein. Entweder keine Argumente oder ein oder zwei kurze Argumente. Viele Argumente machen das Ausfüllen zu einem eigenen neuen Verfahren — die Einsparungen verschwinden.

1.5 Kann das Ergebnis konsistent verifiziert werden?

Nach dem Ausführen sollte der Skill dem Kollaborateur erlauben, das Ergebnis selbst zu verifizieren. Signale wie „Erfolg", „Fehler", „Vorbedingung fehlt" müssen klar sein.

Ein Skill, dessen Ergebnisse nicht verifiziert werden können, bedeutet, dass der Betreiber jedes Mal manuell prüfen muss. Die halbe Ersparnis verschwindet dort.

2. Skills · Slash-Befehle · Funktionen — Rollen trennen

Alle drei reduzieren Wiederholung, spielen aber unterschiedliche Rollen.

Ein Skill ist die gemeinsame Verfahrensdefinition, die sowohl Slash-Befehle als auch Hooks aufrufen können. Dasselbe /verify-Verfahren kann vom Betreiber direkt eingegeben oder von einem Hook kurz vor einem „fertig"-Bericht automatisch gefeuert werden. Beide Wege zeigen auf denselben Skill.

Ist diese Trennung nicht sauber, wird entweder jede Automatisierung zu einer Funktion und die Kontextbewusstheit des Kollaborateurs bleibt ungenutzt — oder alles wird ein Slash-Befehl und der Betreiber muss jeden manuell aufrufen.

3. Skills im tatsächlichen Betrieb — der akkumulierte Effekt

Eine Teilmenge der Skills, die ich täglich aufrufe.

3.1 /start <project> — ein Projekt betreten

Das genannte Projekt betreten, README.md · CLAUDE.md · HANDOFF.md · PLAN.md automatisch laden, dann aktuellen Git-Status und das vorherige Sitzungs-Handoff in einer Ansicht berichten. Stoppen und auf die nächste Anweisung des Betreibers warten.

Ohne diesen Skill erfordert jeder Eintritt, dass der Betreiber entrollt: „geh zu diesem Ordner, lese das README, lese das HANDOFF, prüfe git status, zeige mir die letzte Commit-Nachricht." In ein Wort verdichtet.

3.2 /session-end — die Sitzung schließen

Arbeitsprotokoll schreiben, HANDOFF.md aktualisieren (das Sitzungs-Handoff, das das System automatisch lädt), commit, push — alles in einer Bewegung. Nicht mehr „heutige Arbeit in history.md zusammenfassen, was die nächste Sitzung braucht in HANDOFF schreiben, commit, push" buchstabieren.

3.3 /verify — der Verifikationsloop

Nach Codeänderungen führt lint · build · test · Sicherheitsprüfungen · Diff-Review automatisch aus. Ein „fertig"-Bericht kann nicht rausgehen, bis er besteht. Später in der Serie ausführlich behandelt.

3.4 /council — Vier-Perspektiven-Parallelanalyse

Für genuinely ambige Entscheidungen führt Architekt · Skeptiker · Pragmatiker · Kritiker-Perspektiven parallel aus und synthetisiert die Ergebnisse. Dieses Muster ist adaptiert von Andrej Karpathys Multi-Perspektiven-Kritikansatz für LLM-Reasoning.

3.5 Der akkumulierte Effekt

Keiner davon ist für sich allein eine große Erfindung. Aber wenn täglich rund 30 einzeilige Namen aufgerufen werden, verschwindet die Zeit, die der Betreiber damit verbringt, Verfahren in Sprache zu entrollen, fast vollständig. Der Geist des Betreibers muss sich nur auf „was muss ich jetzt entscheiden" konzentrieren; die Namen übernehmen „wie entfalte ich die Entscheidung."

4. Designprinzipien — was ich beim Aufbau eines Skills beachte

Auf was ich mich beim Skill-Design festgelegt habe.

4.1 Idempotent

Zweimaliges Aufrufen mit denselben Argumenten sollte dasselbe Ergebnis liefern oder zumindest nicht brechen. Ein nicht-idempotenter Skill lässt den Betreiber jedes Mal denken: „Ist es sicher, das jetzt aufzurufen?" Das ist frische Geist-Steuer.

4.2 Fail-Fast

Wenn Vorbedingungen nicht erfüllt sind, stoppt der Skill in Zeile eins mit einer klaren Meldung. „Dieses Verzeichnis ist kein Git-Repo. Führe git init aus und versuche es erneut." Halb ausgeführte Skills in einem Zwischenzustand sind die gefährlichsten.

4.3 Kurze Ausgabe

Wenn der Skill endet, sollte die Ausgabe kurz sein. „OK: 3 Dateien gepusht", eine Zeile. Detaillierte Logs nur auf Anfrage, hinter einer Option. Lange Ausgabe zwingt den Kollaborateur, sie jedes Mal zusammenzufassen, und den Betreiber, sie neu zu lesen.

4.4 Nebeneffekte deklarieren

Wenn der Skill externen Zustand ändert — Dateien schreibt, Netzwerkaufrufe macht, pusht — wird diese Tatsache am Anfang der Skill-Definition deklariert. „Dieser Skill pusht nach origin." Der Betreiber sollte das vor dem Aufrufen wissen.

4.5 Einzelverantwortung

Ein Skill macht eine Sache. „Und auch Abhängigkeiten installieren" nicht in /start einschmuggeln. Das ist ein separater Skill. Wenn Einzelverantwortung bricht, beschreibt der Name die Aktion nicht mehr.

5. Wenn Skills akkumulieren — der Netzwerkeffekt

Der Wert eines einzelnen Skills ist eingesparte Zeit. Aber wenn 30 Skills akkumulieren, passiert etwas Größeres. Skills beginnen, sich gegenseitig aufzurufen.

Zum Beispiel:

• /session-end ruft intern /verify auf — unverifizierte Änderungen werden nicht gepusht
• /start aktualisiert den Gedächtnis-Index automatisch
• /council schlägt nach einer Entscheidung vor, /btw (Entscheidungswarteschlangen-Verarbeitung) aufzurufen

Wenn jeder Skill andere durch eine klar definierte Schnittstelle aufrufen kann, operiert der Geist des Betreibers auf einer größeren Einheit. Eine einzige „heutigen Tag abschließen"-Entscheidung entrollt sich intern in 7 oder 8 Skill-Aufrufe. Der Betreiber muss sich dieser 7 oder 8 nicht bewusst sein.

Das ist der echte Wert eines akkumulierten Skill-Sets. Eingesparte Zeit ist ein Nebeneffekt; der Geist kann in einer größeren Einheit operieren — das ist das Wesentliche.

6. Was nicht zu Skills werden sollte — Fallen

Die Kehrseite der Promotionskriterien. Folgendes verliert als Skill Wert.

6.1 Verfahren, die wahrscheinlich nur einmal laufen

„Diese Migration läuft einmal, ich schreibe ein Skript." Das sollte kein Skill werden. Einmalige Verfahren laufen einmal und verschwinden. Als Skill werden sie zur Wartungslast, und sechs Monate später versucht man sich zu erinnern, was sie überhaupt waren.

6.2 Dinge mit starker Kontextabhängigkeit

„Überprüfe diesen Code" kann kein Skill sein, weil jede Invokation anderen Kontext benötigt. Nimmt man den Kontext als Argumente, buchstabiert man ihn jedes Mal aus — der Vorteil verschwindet.

6.3 Den Geist selbst auslagern

„Sag mir, was ich entscheiden soll" ist kein Skill. Das lagert den Geist des Betreibers aus, und der Betreiber hört auf, Eigentümer der Entscheidung zu sein.

Ein Skill unterstützt den Geist des Betreibers; er ersetzt ihn nicht.

6.4 Verfahren, die sich zu oft ändern

Ein Skill, einmal definiert, sollte tagelang Bestand haben. Verfahren, die sich wöchentlich ändern, verfestigen sich nicht. Wer sie verfestigt, sieht sie nächste Woche brechen.

7. Evolutionsmuster — wie Skills poliert werden

Der natürliche Lebenszyklus, den ich für einen Skill beobachtet habe.

1. Wiederholung erkannt: Dasselbe Verfahren zweimal oder öfter buchstabiert → Kandidat
2. Manuelles Aufschreiben: Die Schritte in einem README oder Notiz auflisten → per Hand befolgbar
3. Zu Skill machen: Sobald die Schritte stabil sind, in einen Slash-Befehl oder eine Skill-Definition verdichten
4. Im Betrieb polieren: Im echten Einsatz gefundene Grenzfälle beheben
5. Extern aufrufbar: Die Schnittstelle bereinigen, damit andere Skills sie aufrufen können
6. Promovieren oder demovieren: Stark genutzt → einen Auto-Fire-Auslöser in der Persona hinzufügen (nächster Beitrag über Hooks) / ungenutzt → nach extern demovieren oder löschen

Skills, die diesen Zyklus nicht durchlaufen, halten nicht. Sie sind einfach zu erstellen und schwer zu warten, daher ist natürliche Selektion erforderlich.

Download — der /verify-Skill

Der siebenstufige Verifikationsloop aus Teil 7 als einzelne Slash-Befehl-Skill-Datei. Ein Beispiel dafür, wie ein wiederkehrendes Verfahren in eine einzeilige Invokation verdichtet wird — einfach die eigenen Build/Test-Befehle einsetzen.

shasum -a 256 verify.md
# expected: 8cabf33a2711a0501ee3f65f630bc49868a710cfa973910b7c33e253091dea12

8. Auf ein Prinzip verdichtet

Der Kern von Skill- und Slash-Befehl-Design kollabiert auf einen Satz.

„Nur den wiederkehrenden Geistbewegungen einen einzeiligen Namen geben. Alles andere buchstabieren."

Wenn das gilt, wird das Skill-Set zu einem Beschleuniger für den Geist des Betreibers. Wenn es bricht — Skills zu früh erstellt oder zu komplex — werden sie zu einem Overhead, über den der Betreiber jedes Mal nachdenken muss.

Der nächste Beitrag behandelt die andere Hälfte, die mit Skills gepaart wird — Hooks und Automatisierung, d.h. Verfahren, die das System automatisch feuert, ohne dass der Betreiber sie aufrufen muss.