KI-News · Werkzeuge
/bro: die letzte Antwort nochmal,
aber verständlich.
EN Read in English
/bro löst genau ein Problem: Die letzte Antwort des Agenten war zu dicht, zu
fachbegriffslastig oder zu formell, und man will sie nicht neu stellen, sondern nur
verständlicher hören. Die gesamte Skill besteht aus einer einzigen Markdown-Datei mit sieben
Regeln. Kein Server, kein Modell, keine Konfiguration. Ich habe die Regeln wörtlich genommen
und an zwei echten, dichten Erklärungen angewendet, um zu sehen, was davon tatsächlich hält.
/bro stammt aus
Lucas Sariés
öffentlichem Repository (MIT-Lizenz, Stand dieses Beitrags 357 Sterne). Die komplette Skill
ist SKILL.md,
eine 30-Zeilen-Textdatei ohne Programmlogik. Ein Test besteht hier deshalb daraus, die Regeln
wörtlich zu befolgen, statt Kommandozeilen-Output zu sammeln wie bei einem CLI-Tool:
Ich habe zwei dichte, fachbegriffslastige Absätze geschrieben, wie sie in echten
Claude-Code-Sitzungen vorkommen, und sie exakt nach den sieben Regeln aus SKILL.md
umformuliert, nicht anders, als es die installierte Skill mit dem echten Vorgängertext einer
Sitzung tun würde.
Was die Skill-Datei genau vorschreibt
Sieben Regeln, alle in einer einzigen Datei. Die ersten drei sind die, an denen ein Test sich am ehesten aufhängen lässt:
- Re-explain, don't re-answer: nur die letzte eigene Nachricht umformulieren, nie eine neue Frage beantworten, nie ein Werkzeug aufrufen.
- Einfacher, nicht kürzer: Ziel ist „unmöglich misszuverstehen", nicht „möglichst wenig Wörter". Präambeln, Absicherungen und Beraterjargon fallen weg, echte Erklärung darf so viel Platz einnehmen, wie sie braucht.
- Fakten überleben wörtlich: jeder Pfad, jeder Befehl, jede Zahl, jede URL bleibt exakt erhalten. Nur die Erklärung drumherum wird einfacher, nie die Fakten selbst.
- Leichter Bro-Ton: locker und direkt, „also im Grunde …", „der Punkt ist …", aber ausdrücklich keine Meme-Sprache.
- Gleiche Sprache: Deutsch bleibt Deutsch, Portugiesisch bleibt Portugiesisch.
- Struktur einebnen: Überschriften und Tabellen werden zu normalen Sätzen, eine Liste bleibt nur, wenn das Original wirklich mehrere eigenständige Teile hatte.
- Randfall: gibt es noch keine vorherige Antwort, sagt die Skill das offen, statt sich etwas auszudenken.
Test eins: eine Selbstbeschreibung, dichter geschrieben als nötig
Der naheliegendste Test für eine Erklär-Skill ist, sie auf eine Erklärung ihrer selbst anzuwenden. Der folgende „Vorher"-Absatz ist bewusst so geschrieben, wie eine technische Antwort tatsächlich manchmal ausfällt, mit genau den Eigenschaften, die laut Regel 1 und 2 verschwinden sollen:
Technisch betrachtet handelt es sich bei /bro um keine eigenständige
Ausführungslogik, sondern um eine deklarative Skill-Definition im Agent-Skills-Format, die
beim Aufruf lediglich die sieben in SKILL.md kodifizierten Regeln in den
Kontext lädt und dadurch die Reformulierungsstrategie des zugrundeliegenden
Sprachmodells konditioniert, ohne dass dabei neue Informationen generiert oder externe
Werkzeuge aufgerufen werden.
Ok, also im Grunde: /bro macht selbst gar nichts. Es ist nur eine Textdatei
mit sieben Regeln (SKILL.md), die dem Modell sagt, wie es die letzte Antwort
nochmal aufschreiben soll. Kein neues Wissen kommt dazu, kein Werkzeug wird aufgerufen, es
ist nur eine andere Formulierung von dem, was eh schon gesagt wurde.
SKILL.md blieb als Dateiname stehen, „sieben Regeln" als Zahl ebenso, genau das,
was Regel 3 verlangt. Was verschwand, war die Verschachtelung: „deklarative Skill-Definition im
Agent-Skills-Format, die … die Reformulierungsstrategie … konditioniert" wurde zu zwei kurzen
Sätzen mit Subjekt und Verb vorne.
Test zwei: ein Befehl mit Pfad, als Stresstest für Regel 3
Der zweite Test prüft gezielt, ob ein technischer Fakt einen Umformulierungsdurchgang unbeschadet übersteht, absichtlich mit einem Befehl und einem Dateipfad in einem einzigen, verschachtelten Satz:
Um die Rewrite-Schicht zu deaktivieren, muss die Umgebungsvariable
RTK_DISABLE=1 vor dem Start der Shell gesetzt werden, wodurch der Hook in
~/.claude/hooks/pretool.sh die Kommandosubstitution überspringt und
stattdessen den unveränderten Originalbefehl an die Shell durchreicht.
Willst du das Kürzen abschalten? Setz einfach RTK_DISABLE=1, bevor du die
Shell startest. Dann überspringt der Hook in ~/.claude/hooks/pretool.sh das
Ersetzen und lässt deinen Befehl einfach so durch, wie du ihn geschrieben hast.
RTK_DISABLE=1 und ~/.claude/hooks/pretool.sh stehen in beiden
Versionen buchstabengleich. Genau das ist der Unterschied zu einem einfachen „erklär das
nochmal einfacher": Ohne die Regel „Fakten überleben wörtlich" ist ein Umgebungsvariablenname
oder ein Pfad kein geschützter Bestandteil des Satzes, ein Modell könnte ihn beim Umformulieren
unbeabsichtigt leicht verändern, etwa RTK_DISABLE zu RTK_DISABLED
oder den Pfad zu ~/.claude/hooks/ verkürzen. Die Skill macht daraus eine
ausdrückliche Regel statt einer Hoffnung.
Der Unterschied zu „erklär das nochmal einfacher"
Man könnte dasselbe Ergebnis ohne Skill erreichen, indem man einfach nachfragt. Der Unterschied zeigt sich über mehrere Durchgänge: Eine Skill-Datei erzwingt bei jedem Aufruf dieselben Regeln, ein spontaner Prompt überlässt sie dem Zufall des jeweiligen Wortlauts:
| /bro | „Erklär das nochmal einfacher" | |
|---|---|---|
| Neue Information | ausdrücklich ausgeschlossen (Regel 1) | nicht ausgeschlossen, ein Modell ergänzt gerne beiläufig etwas Neues |
| Fakten wie Pfade, Zahlen, Befehle | müssen wörtlich erhalten bleiben (Regel 3) | keine Garantie, hängt vom Zufall des jeweiligen Durchgangs ab |
| Sprache | bleibt an der Originalsprache der letzten Antwort (Regel 5) | kann unbeabsichtigt kippen, vor allem bei mehrsprachigen Sitzungen |
| Werkzeugaufrufe | ausdrücklich verboten | ein Agent kann bei „erklär das nochmal" auf die Idee kommen, nachzurecherchieren |
| Reproduzierbarkeit | gleiche sieben Regeln bei jedem Aufruf | hängt vom genauen Wortlaut der Nachfrage ab |
/bro keine Zahlen
produziert, keine Byte- oder Tokenmengen komprimiert und keinen Prozess im Hintergrund betreibt,
lässt sich hier keine Kennzahl wie bei RTK oder Headroom messen. Was sich prüfen lässt, ist
ausschließlich Regeltreue: Bleiben Fakten wörtlich erhalten, verschwindet Struktur, kommt keine
neue Information hinzu. Genau das habe ich oben getan, an selbst geschriebenen, aber realistisch
dichten Beispielen, nicht an den Beispielen aus dem Repository selbst.
Wann sich das lohnt
Eine Antwort mit zu viel Fachbegriff auf einmal
Wenn ein Satz wie im ersten Testfall oben steht, drei Substantivketten tief, und die eigentliche Aussage sich dahinter versteckt statt vorne zu stehen.
Eine Antwort mit Befehlen oder Pfaden, die stimmen müssen
Genau hier zeigt sich der Unterschied zu einem spontanen „einfacher bitte": Regel 3 macht die Worttreue bei Fakten zur Vorgabe statt zur Hoffnung.
Eine neue Frage, keine unklare Antwort
Dann /bro weglassen und normal weiterfragen. Die Skill lehnt genau das
laut Regel 1 ab, sie beantwortet nichts Neues, sie erklärt nur das bereits Gesagte
nochmal.
/bro ist eine 30-Zeilen-Textdatei, kein
ausführbares Werkzeug, deshalb gibt es hier keine Prozentzahl zu berichten. An zwei selbst
geschriebenen, aber realistisch dichten Testabsätzen hielten die entscheidenden Regeln: Fakten
wie RTK_DISABLE=1 und Dateipfade blieben wörtlich stehen, verschachtelte
Substantivketten wurden zu geraden Sätzen, ohne dass dabei etwas Neues hinzuerfunden wurde.
Genau das unterscheidet die Skill von einem spontanen „erklär das nochmal einfacher": eine
geschriebene Regel statt eines Zufallstreffers.
Welche Skills für Ihr Team wirklich etwas bringen?
Ich richte Claude Code in Entwicklerteams ein, inklusive der Frage, welche Skills echten Nutzen stiften und welche nur Tokens kosten. 30 Minuten Erstgespräch, kostenlos.