Claude Code: Machen allein reicht nicht

Der Einstieg in Claude Code ist verführerisch einfach. Man beschreibt, was man will, der Assistent baut es. Läuft etwas wiederholt gleich ab, lässt man sich einen Skill dafür schreiben, eine Anleitung, die der Assistent bei passender Gelegenheit selbst zieht. Nach ein paar Wochen hat man zwanzig davon, installiert noch ein Paket aus der Community dazu und freut sich, wie viel der Assistent inzwischen weiß.

Wir haben genau das gemacht. Und dann nachgezählt: 17 eigene Skills, 34 aus installierten Paketen, darunter vier des FriendsOfREDAXO-Marketplace, dazu die Skills des Herstellers. Über 50 Anleitungen, deren Kurzbeschreibungen der Assistent bei jeder einzelnen Anfrage mitliest, um zu entscheiden, welche er braucht.

Das Problem: Für diese Kurzbeschreibungen gibt es ein Budget. Ist es aufgebraucht, verliert ein Teil der Skills seine Beschreibung und behält nur den Namen. Ohne Fehlermeldung, ohne Hinweis. Der Skill für die Zwei-Faktor-Anmeldung liegt dann zwar auf der Platte, aber der Assistent weiß nicht mehr, wofür er da ist. Wir haben das lange nicht bemerkt.

Dieser Text ist der Versuch, das System zu verstehen, in das wir da hineinarbeiten. Was Kontext ist, woraus er besteht, wo die Budgets liegen, welche Befehle zeigen, was gerade passiert, und was wir an unserer Arbeitsweise ändern. Die Zahlen sind Stand September 2026 und einige davon stammen aus Beobachtung, weil der Hersteller sie nicht dokumentiert. Wo das so ist, steht es dabei.

Kontext ist ein Budget

Alles, was der Assistent bei einer Anfrage berücksichtigt, muss in sein Kontextfenster passen: die Anweisungen des Herstellers, unsere Projektregeln, die Liste der verfügbaren Skills, das bisherige Gespräch, gelesene Dateien, Werkzeugausgaben. Das Fenster ist groß, bei den aktuellen Modellen eine Million Token, beim kleinsten Modell 200.000. Aber es ist endlich, und es kostet.

Zu viel Kontext hat zwei Folgen. Die eine ist Geld und Strom: Jede Anfrage liest den gesamten Kontext neu ein, und in unserer Stromrechnung waren 98 Prozent aller Token genau dieses Wiederlesen. Die andere ist Aufmerksamkeit: Je mehr Anweisungen im Fenster stehen, desto weniger Gewicht bekommt jede einzelne. Anthropic hat für die aktuelle Modellgeneration über 80 Prozent des eigenen System-Prompts von Claude Code gestrichen, ohne messbaren Verlust in den Programmier-Tests. Der Hersteller selbst hält also weniger Anweisungen für besser.

Zu wenig Kontext ist genauso schlecht. Fehlt dem Assistenten die Information, wie ein Projekt tickt, füllt er die Lücke mit dem, was er für üblich hält. Das Ergebnis läuft, ist aber nicht das, was man wollte.

Die Kunst liegt dazwischen, und sie hat einen Namen: Kontext-Hygiene. Das Richtige zur richtigen Zeit im Fenster haben, und sonst nichts.

Woraus der Kontext besteht

Claude Code kennt sechs Ebenen, auf denen man ihm etwas mitgeben kann. Sie unterscheiden sich darin, wann sie geladen werden und wie verbindlich sie sind. Wer sie verwechselt, legt wichtige Regeln dort ab, wo sie als Erstes gekürzt werden.

CLAUDE.md ist die Grundlage. Es gibt sie global im Benutzerordner und im Projekt, beide werden in jeder Sitzung geladen. Die Projektdatei gehört ins Repository, damit alle im Team dieselben Regeln haben. Für Dinge, die nicht ins Repository sollen, etwa Zugangswege oder persönliche Vorlieben, gibt es CLAUDE.local.md, die ebenfalls automatisch gelesen wird. Sie landet aber nicht von selbst in der .gitignore, das muss man tun. Die Dokumentation empfiehlt, unter 200 Zeilen zu bleiben. Eine harte Grenze ist das nicht, die Datei wird auch bei 400 Zeilen geladen. Aber jede Zeile verdünnt die anderen, und die eigene Datei wird schnell länger, als man denkt. Unsere globale liegt bei 446 Zeilen, die dieses Blog-Projekts bei 462.

Rules sind CLAUDE.md in Scheiben. Eine Datei pro Thema, und über ein Feld im Kopf lässt sich festlegen, dass sie nur gilt, wenn bestimmte Dateipfade im Spiel sind. Die Regel für Stylesheets belastet dann keine Sitzung, in der es um die Datenbank geht.

Memory ist das Gedächtnis des Assistenten. Sagt man „merk dir das“, landet ein kurzer Eintrag in einem Ordner außerhalb des Repositories, global oder pro Projekt. Eine Indexdatei verweist auf die einzelnen Einträge; von ihr werden die ersten 200 Zeilen oder 25 Kilobyte geladen, die Einträge selbst nur, wenn der Assistent sie braucht. Das klingt nach Wissensdatenbank, ist aber die flüchtigste der sechs Ebenen. Was verbindlich gelten soll, gehört nicht hierhin.

Skills sind das Interessanteste, weil sie sich teilen lassen. Eine Anleitung mit Kurzbeschreibung, der Assistent zieht sie, wenn die Aufgabe passt. Für REDAXO gibt es sie über das FriendsOfREDAXO-Marketplace, und genau dort liegt das Budgetproblem, dazu gleich mehr.

Hooks laufen außerhalb des Modells. Sie feuern bei Ereignissen, etwa vor jedem Werkzeugaufruf oder am Sitzungsstart, und führen ein Programm aus. Ein Hook kann einen Befehl hart blockieren, indem er mit Fehlercode 2 endet. Der Assistent kann das nicht umgehen, weil der Riegel vor dem Werkzeug sitzt, außerhalb seiner Reichweite. Für alles, was nie passieren darf, ist das die richtige Ebene: Tabellen löschen, auf Produktion pushen, Geheimnisse committen.

Subagents bekommen ein eigenes, leeres Fenster. Sie sehen weder das Gespräch noch die bisher gelesenen Dateien, und zurück ins Hauptfenster kommt nur ihre Zusammenfassung. Das hält das Hauptfenster schlank, wenn eine Teilaufgabe viel lesen muss.

Der Fall Skills

Damit der Assistent entscheiden kann, welchen Skill er braucht, stehen die Kurzbeschreibungen aller installierten Skills in jeder Sitzung im Kontext. Diese Liste hat ein Budget. Seit Version 2.1.129 ist es einstellbar und liegt standardmäßig bei einem Prozent des Kontextfensters. Beim kleinsten Modell mit 200.000 Token sind das rund 2.000 Token, also grob 8.000 Zeichen. Bei den großen Modellen mit einer Million Token grob 40.000. Dokumentiert ist außerdem eine Obergrenze von 1.536 Zeichen pro Skill für Beschreibung und Einsatzhinweis zusammen.

Was passiert, wenn das Budget nicht reicht, steht nur in den Fehlerberichten. Ein bestätigter Bericht vom Juli 2026: 36 Skills im Projekt, 9 behielten ihre Beschreibung, 27 nur den Namen. Kein Hinweis in der Sitzung. Welche überleben, entscheidet die Software, je nach Version nach Nutzungshäufigkeit oder schlicht alphabetisch. Ein Skill, der selten gebraucht wird, verliert also als Erster genau die Beschreibung, die ihn auffindbar macht.

Wir haben das FriendsOfREDAXO-Marketplace nachgemessen, Stand Juni 2026:

Auf einem unserer Rechner sind davon vier Pakete installiert, dazu Pakete für PhpStorm und eigene Firmen-Skills: 34 Skills, 13.598 Zeichen. Plus die 17 eigenen mit 7.928 Zeichen. Zusammen 51 Skills und 21.500 Zeichen, plus der Verwaltungsaufwand pro Eintrag, plus die Skills des Herstellers. Bei einem 200k-Modell überlebt davon gut ein Drittel mit Beschreibung. Bei einem 1M-Modell passt es, aber nur, weil das Fenster so groß ist, und jede Sitzung schleppt rund 6.000 Token Skill-Liste mit, bevor die erste Frage gestellt ist.

Die Maintainer des Marketplace sehen das anders, und ihre Position steht in der Anleitung des Projekts: ein Skill pro Thema, keine Themen zusammenlegen, weil sonst die gezielte Aktivierung leidet. Das ist ein echtes Argument. Ein Skill, der acht Themen abdeckt, wird für jedes davon gezogen und lädt dann Inhalt, der gerade nicht gebraucht wird. Aber die Rechnung geht nur auf, wenn alle acht Beschreibungen den Assistenten auch erreichen. Sobald die Hälfte gekürzt ist, ist der granulare Skill schlechter als ein grober, der zumindest gefunden wird.

Unser Vorschlag, den wir dem Projekt auch machen werden: ein Skill pro AddOn, mit einer kurzen Beschreibung und innerhalb der Anleitung einer Verteilertabelle auf die Unterthemen. Der Assistent liest die Anleitung ohnehin erst, wenn er sie zieht. Progressive Offenlegung nennt der Hersteller das Prinzip: wenig vorne, alles Weitere bei Bedarf.

Für die Beschreibung selbst gilt: 150 bis 250 Zeichen. Zuerst die Aufgabe, dann Stichwörter, dann ein oder zwei Symptome, an denen man das Problem erkennt. Kein zusätzlicher Einsatzhinweis in einem zweiten Feld, weil er ins selbe Limit zählt und nichts hinzufügt, was nicht auch in die Beschreibung passt.

Die Befehle, die man regelmäßig aufrufen sollte

Das Problem an allem Obigen: Man sieht es nicht. Der Assistent arbeitet, das Ergebnis kommt, niemand meldet, dass ein Drittel der Skills blind ist oder dass die Hälfte des Fensters mit alten Werkzeugausgaben belegt ist. Dafür gibt es vier Befehle, die wir uns angewöhnt haben.

/context ist der wichtigste. Aufgerufen in einer frischen Sitzung zeigt er, was jede Anfrage kostet, bevor man ein Wort geschrieben hat. Und er zeigt in der Zeile für Skills, wie das Budget ausgelastet ist.

/skill-doctor gibt es seit Version 2.1.261 vom 4. September 2026. Er zeigt, welche Skills nie aufgerufen wurden und was sie trotzdem pro Runde kosten. Zwei Dinge dazu, die der Bericht nicht sagt: Ein Skill, der erst gestern angelegt wurde, steht auch auf null Aufrufen. Vor dem Löschen also das Erstelldatum ansehen. Und der Bericht bewertet nur, ob ein Skill lief, nicht, ob er geholfen hat.

/compact fasst das bisherige Gespräch zusammen und macht Platz, wenn eine Aufgabe noch nicht fertig ist. Claude Code macht das auch automatisch, kurz bevor das Fenster voll ist. Wir bevorzugen den harten Schnitt mit /clear, weil eine Zusammenfassung Details verliert, ohne dass man sieht, welche.

Wie wir inzwischen arbeiten

Aus all dem hat sich eine Routine ergeben. Sie ist nicht fertig, aber sie liefert bei uns gerade bessere Ergebnisse als das Draufloslegen vom Anfang.

Die Sitzung bleibt kurz. Eine Aufgabe, ein Gespräch, danach /clear. Was länger als eine Stunde dauert, war zu groß geschnitten.

Jede Aufgabe bekommt ein prüfbares Ziel, bevor gearbeitet wird. Wir lassen den Assistenten die Anfrage in Pakete zerlegen und so lange nachfragen, bis für jedes Paket klar ist, woran man erkennt, dass es fertig ist. Das kostet vorne fünf Minuten und spart hinten eine Stunde.

Pakete, die viel lesen müssen, gehen an einen Subagenten. Der durchsucht das Repository oder liest Dokumentation in seinem eigenen Fenster und liefert eine Zusammenfassung zurück. Das Hauptgespräch bleibt beim Wesentlichen. Am Ende prüft ein zweiter Agent das Ergebnis gegen die Ziele vom Anfang.

Nach jeder abgeschlossenen Aufgabe fragen wir: Gibt es etwas, das wir uns merken sollten? Ein Stolperstein, eine Konvention, ein Befehl, der anders heißt als gedacht. Das geht in Memory, in eine Rule oder, wenn es eine wiederkehrende Aufgabe ist, in einen Skill. Und zwar dorthin, wo es hingehört: Verbindliches in Rules oder Hooks, Wissen in Skills, Flüchtiges in Memory.

Ehrlich gesagt: Der Prüfer prüft bei uns gerade zu viel und zu hart. Die Ergebnisse sind gut und getestet, aber es dauert. Auch das ist Kontext-Arbeit: Ein Prüfer, der die ganze Anleitung liest, findet mehr, als nötig wäre.

Was wir jetzt ändern

Drei Dinge stehen an. Erstens kürzen wir unsere eigenen Skill-Beschreibungen auf 150 bis 250 Zeichen und legen thematisch verwandte Skills zusammen. Zweitens räumen wir die globale CLAUDE.md aus: Was Verfahren beschreibt, wird ein Skill, was hart gelten soll, ein Hook, was nur ein Projekt betrifft, wandert dorthin. Drittens schlagen wir dem FriendsOfREDAXO-Projekt vor, die Marketplace-Skills nach demselben Prinzip zu straffen, damit sie auf einem 200k-Modell überhaupt vollständig ankommen.

Die Erkenntnis dahinter ist banal und trotzdem unbequem: Ein Werkzeug, das so bereitwillig alles macht, was man sagt, verleitet dazu, nie nachzusehen, was es dabei liest. Wer Claude Code ernsthaft einsetzt, muss sich und das System regelmäßig hinterfragen. Greifen die Skills? Was steht im Fenster? Was davon braucht diese Aufgabe? Das ist Systempflege, und sie beginnt mit /context.

Quellen: Claude Code Dokumentation zu Skills, Memory, Hooks und Subagents (code.claude.com/docs) · anthropics/claude-code, Issues #13099 und #81081 (Skill-Budget und stille Kürzung) · Anthropic, The new rules of context engineering for Claude 5 generation models (Juli 2026) · FriendsOfREDAXO/claude-marketplace, Stand 13. Juni 2026, eigene Auszählung · Claude Code Changelog 2.1.129, 2.1.206, 2.1.261