Everything Claude Code im Audit: 286 Skills und ein Index mit 21K Tokens

Spät am Abend taucht ein kurzes Video auf: Ein Hackathon-Gewinner habe sein komplettes Claude-Code-Setup verschenkt. Dann folgt ein Thread mit derselben Behauptung, dann noch einer, dann mehrere. Alle sehen gleich aus: ein paar große Zahlen, ein Screenshot vom Sternezähler und ein Link. Einer nennt 163K Sterne, ein anderer 214K, wieder ein anderer 228K.

Die Zahlen passen nicht einmal zueinander – der erste Hinweis darauf, dass keiner der Posts das Repo je geöffnet hat.

Hier also, was passiert, wenn man es doch tut. Nicht die README, sondern das Repo selbst. Wer es klont, wc und ein kurzes Python-Skript darüber laufen lässt und die Teile liest, die für einen iOS-Entwickler zählen, bekommt ein klares Bild: was drin ist, was sich zu behalten lohnt und eine Messung, die verändert, wie man es installieren sollte.

Was ECC ist

ECC steht für Everything Claude Code, ein Projekt von Affaan Mustafa unter MIT-Lizenz. Zum Zeitpunkt der Prüfung hatte das Repo rund 247.000 Sterne, 37.200 Forks, 2.631 Commits und stand bei Version 2.2.1.

Das Versprechen: Claude Code ist ab Werk ein einzelner Assistent, und ECC macht daraus einen Workflow aus Planen, Testen, Implementieren, Reviewen, Verifizieren, Erinnern und Verbessern. Drumherum gibt es einen Memory Vault, „Instincts“ (Muster, die über Sitzungen hinweg erhalten bleiben) und einen Sicherheitsscanner namens AgentShield.

Die Installation ist ein einziger Befehl:

npx ecc-universal setup

Vorausgesetzt werden Node 18+, Git und Claude Code 2.1+. Adapter gibt es für Codex, Cursor, OpenCode, Gemini, Zed und etwa ein Dutzend weitere.

So weit das Marketing. Jetzt zum Inhalt.

Nachgezählt

Lässt man die Zahlen aus den Threads weg und zählt selbst, ergibt sich Folgendes:

ls -1 skills | wc -l     # 286
ls -1 agents | wc -l     # 68
du -sh --exclude=.git .  # 94M

• 286 Skills, ein SKILL.md pro Ordner
• 68 Agenten, Markdown-Dateien, deren Frontmatter das Modell und die erlaubten Tools nennt
• 94 Legacy-Command-Shims, Teil von insgesamt 426 Command-Dateien
• 23 Hook-Einträge für sieben Lifecycle-Events. Acht hängen an PreToolUse und sieben an Stop. PostToolUse, PostToolUseFailure und SessionStart bekommen je zwei, PreCompact und SessionEnd je einen
• 94 MB auf der Platte, davon 23 MB Assets und 18 MB Doku

Ein Detail überrascht. Die CLAUDE.md im Root dieses 94 MB großen Konfigurationsdenkmals ist 82 Zeilen lang, 531 Wörter. Wer 286 Skills veröffentlicht, hält die eigene Anweisungsdatei kürzer als viele private Repos. Das ist kein Zufall, und am Ende wird es noch einmal wichtig.

Die Zahl, die die Threads auslassen

Bevor ein Skill laufen kann, muss Claude Code wissen, dass es ihn gibt. Beim Start liest es Name und Kurzbeschreibung jedes Skills als Katalog ein, und der vollständige Inhalt eines Skills wird erst geladen, wenn er auslöst. Dieses Lazy Loading heißt Progressive Disclosure, und das Design ist gut.

Die Ankündigungen kosten trotzdem etwas, also lohnt es sich, sie zu messen:

# name + description from every SKILL.md frontmatter
skills: 286  name+desc chars: 86,311  ~tokens: 21,577

Das sind etwa 21.500 Tokens Skill-Index, ausgegeben, bevor auch nur ein Wort des eigentlichen Problems getippt ist.

Zum Vergleich, was hinter dem Index steckt:

• alle 286 Skill-Inhalte: etwa 641.000 Tokens
• alle 68 Agentendefinitionen: etwa 110.000 Tokens

Niemand wird je 641K Tokens laden – genau dafür gibt es Progressive Disclosure, und es funktioniert. Aber der Index mit ~21,5K ist der Eintrittspreis einer Vollinstallation, bezahlt in jeder Sitzung. Bei einem 200K-Fenster gehen über 10 % für eine Speisekarte drauf.

Nichts davon ist Kritik an ECC. Es ist ein Argument für das minimal-Profil, das das Repo selbst anbietet:

./install.sh --profile minimal --target claude

Die README sagt es sogar klar: Beginnen Sie mit rules/common plus einem Sprachpaket, das Sie wirklich nutzen. Die lautesten Verbreiter des Repos haben diese Zeile übersprungen.

Sechs Dinge, die ein iOS-Entwickler behalten würde

Die Suche nach allem, was nach Swift aussieht, liefert zuerst cisco-ios-patterns. Das ist ein Netzwerk-Skill und eine schöne Erinnerung daran, dass „ios“ ein schlechter Suchbegriff ist. Danach tauchen sechs echte Einträge auf.

Typ	Name
Agent	swift-reviewer.md
Agent	swift-build-resolver.md
Skill	swiftui-patterns
Skill	swift-concurrency-6-2
Skill	swift-actor-persistence
Skill	swift-protocol-di-testing

Wer in einer gemischten MVVM-Codebasis aus UIKit und SwiftUI lebt, sollte die letzte Gruppe lesen, auch wenn der Installer nie läuft.

Ein Blick in swift-reviewer

Man erwartet einen generischen Prompt à la „Du bist ein hilfreicher Swift-Reviewer“. Weit gefehlt. Das Frontmatter legt den Agenten auf sonnet fest und beschränkt seine Tools auf Read, Grep, Glob, Bash. Nichts davon kann Dateien ändern, was für einen Reviewer genau richtig ist.

Dann folgt das Vorgehen:

1. Zuerst bauen und testen mit swift build, swiftlint lint --quiet (falls installiert) und swift test. Schlägt einer davon fehl, hält der Agent an und meldet es, statt weiterzumachen.
2. Die Änderungen mit git diff HEAD~1 -- '*.swift' einsammeln, beim Review eines PR mit git diff main...HEAD.
3. Nur geänderte .swift-Dateien ansehen, sonst nichts.
4. Das eigentliche Review beginnen.

Die Regel „wenn etwas fehlschlägt, anhalten und melden“ ist der Teil, den man sich abschauen sollte. Die meisten Review-Prompts kritisieren fröhlich Code, der nicht einmal kompiliert. Dieser weigert sich, Tokens an einem kaputten Stand zu verbrennen.

Die Stufe CRITICAL liest sich wie eine Liste von Dingen, die erfahrene Entwickler schon ausgeliefert und bereut haben:

• Force Unwrapping in Produktionspfaden
• try! ohne Begründung und as! ohne vorherige Typprüfung
• hartcodierte Secrets, auch solche in UserDefaults statt im Keychain
• ATS-Ausnahmen ohne Begründung
• leere catch {}-Blöcke und try?, das relevante Fehler verschluckt
• fatalError() für Zustände, von denen sich der Aufrufer erholen könnte
• assert als Schutz einer Invariante, die in Release-Builds gelten muss. Release-Builds entfernen es, das richtige Werkzeug ist precondition

Der Hinweis zu assert und precondition ist eine echte Senior-Beobachtung. In realen Pull Requests wird er übersehen, und in einem Wertpapierunternehmen ist „im Release entfernt“ keine akademische Sorge.

Der Skill swiftui-patterns folgt demselben Muster. Er enthält eine Tabelle zur Wahl der Property Wrapper (@State, @Binding, @Observable, @Bindable, @Environment) und ein klares Argument für @Observable statt ObservableObject: Weil Änderungen pro Property verfolgt werden, zeichnet SwiftUI nur die Views neu, die das Geänderte tatsächlich lesen. Dasselbe Wissen steckt in WWDC-Sessions. Es in einer Datei zu haben, die man einem Agenten geben kann, ist etwas anderes.

Wo der Nutzen aufhört

Dasselbe ls, das die Swift-Skills gefunden hat, fand auch Einträge wie diese:

customs-trade-compliance
energy-procurement
production-scheduling
quality-nonconformance
healthcare-cdss-patterns
healthcare-emr-patterns
healthcare-phi-compliance

Wer nicht gerade eine Pipeline für Energiebeschaffung baut, kann damit nichts anfangen. Diese Skills sind echte Arbeit von jemandem, und es ist anständig vom Autor, sie zu veröffentlichen, aber jeder ist eine Zeile im Index, die bezahlt und nie genutzt wird.

Drei weitere Punkte verdienen eine ehrliche Erwähnung.

Das Plugin liefert die Regeln nicht mit. Wer ECC als Claude-Code-Plugin installiert, bekommt Agenten, Skills, Hooks und Commands automatisch, die Regeln aber muss man von Hand nach .claude/rules/ kopieren. Im Versprechen des einen Befehls steckt also eine Fleißaufgabe.

Installer lassen sich nicht stapeln. Die README wiederholt immer wieder: eine Methode pro Harness. Bug-Reports zu doppelten Hooks kommen meist von Leuten, die das Plugin mit ./install.sh --profile full kombiniert haben.

Dreiundzwanzig Hooks vergrößern die Angriffsfläche. Acht davon feuern bei PreToolUse, jeder ist also Code, der lokal läuft, bevor Claude irgendeine Datei bearbeitet. ECC verschweigt das nicht: Der Installer verlangt eine ausdrückliche Zustimmung, bevor Hooks aktiviert werden, und AgentShield ist dabei, um Prompts, Hooks und MCP-Konfigurationen zu scannen. Das ist die richtige Haltung. Vor der Zustimmung bleiben trotzdem 23 Dinge zu lesen.

Fazit

Die Sternezahl ist nicht die Geschichte. Niemand klickt bei einem Repo mit 247.000 Sternen auf den Stern, nachdem er 286 Skills geprüft hat. Man klickt, weil ein kurzes Video es so gesagt hat.

Was wirklich zählt: Das Repo ist hervorragendes Lernmaterial dazu, wie man Agentenarbeit organisiert, und ein mittelmäßiges Paket für die Vollinstallation. Ein vernünftiger Plan sieht so aus.

Klonen, aber noch nicht installieren.

git clone --depth 1 https://github.com/affaan-m/ECC.git

Danach lohnen sich vier Dateien: der Reviewer-Agent unter agents/swift-reviewer.md, der Skill unter skills/swiftui-patterns/SKILL.md, die Hook-Konfiguration in hooks/hooks.json und die kurze CLAUDE.md mit 82 Zeilen. Zwanzig Minuten Lektüre dort bringen mehr als jeder Thread über das Repo, wenn man lernen will, wie Agentendefinitionen geschrieben werden sollten.

Minimal statt full. Behalten Sie die zwei Swift-Agenten, die vier Swift-Skills und rules/common. Der Index schrumpft auf eine Handvoll Einträge, die man im Kopf behalten kann, und die Kontextkosten gehen gegen null.

Jeweils ein Teil hinzufügen, und nur dann, wenn ein echtes Problem es verlangt.

Der Hinweis lag von Anfang an im Repo. Der Autor, der 286 Skills veröffentlicht hat, hält seine eigene Anweisungsdatei bei 82 Zeilen, und auch er lädt nicht alles. Niemand braucht alles. Gebraucht wird die Handvoll, die zum tatsächlich geschriebenen Code passt.