Dein Claude Code Stack ist wichtiger als deine Modellwahl. Diese Behauptung verteidige ich den ganzen Tag: Der Abstand zwischen einem gut ausgestatteten Setup und einem Standard-Setup – echte Code-Intelligenz, Live-Dokumentation, Hände im Browser, ein zweites Modell, das das erste prüft – ist in der Praxis größer als der Abstand zwischen zwei beliebigen Frontier-Modellen in diesem Jahr. Ein klügeres Modell kann einen blinden Agent nicht retten.
Die Grundlage für genau diese Top 10 ist, dass es überlebende zehn sind, keine kuratierten zehn. Ich habe einen Marktplatz mit 53 Skills gebaut und pflege ihn, und habe deshalb mehr von diesem Ökosystem getestet als fast jeder, dessen Job nicht buchstäblich genau das ist. Was folgt, ist das, was noch steht – ehrlich gruppiert in Skills, Plugins und CLIs, denn die drei Kategorien lösen unterschiedliche Probleme, und die meisten Listen verwischen sie.

Die Skills (kodiertes Urteilsvermögen)
1. Superpowers. Die Familie für Workflow-Disziplin: Brainstorming vor dem Bauen, Test-Driven Development, systematisches Debugging, verifizieren, bevor man etwas für erledigt erklärt. Das ist die eine Installation, die das Verhalten einer Session am stärksten verändert – der Agent beginnt, seine eigene Arbeit abzusichern. Jeder andere Eintrag auf dieser Liste macht Claude leistungsfähiger; dieser macht es vertrauenswürdiger. Wenn du heute nur eine Sache installierst, dann diese.
2. skill-creator. Der Meta-Skill, der neue Skills aufsetzt, testet und paketiert. Er ist wichtig, weil das Endziel des ganzen Ökosystems nicht darin besteht, die Skills anderer Leute zu installieren – sondern darin, dein eigenes Urteilsvermögen günstig zu kodieren. Alles Eigene in meinem Stack hat mit diesem Gerüst angefangen. Meine ausführlichere Begründung, mit welchen Basis-Skills man anfangen sollte, steht in den Skills, die sich gerade zu installieren lohnen.
3. caveman. Komprimiert ausschweifende Agent-Ausgaben, um den Token-Verbrauch in langen Sessions zu senken. Er liest sich wie ein Witz und rechnet sich wie ein Versorgungswerk – bei mehrstündigen Sessions sind die Einsparungen strukturell, nicht marginal.
4. handoff. Paketiert den Session-Zustand – Entscheidungen, angefasste Dateien, offene Fäden –, damit die Session von morgen warm startet. Die Amnesie zwischen Sessions ist die am meisten unterschätzte Steuer bei agentengestützter Arbeit, und das ist die günstigste Behandlung dagegen, die tatsächlich funktioniert.
Die Plugins (eingebundene Fähigkeiten)
5. Codex – die gegnerische Zweitmeinung. Das Modell von OpenAI, als Reviewer in Claude Code laufend, in einem separaten Prozess. Der Wert liegt in der Uneinigkeit: Befunde, die beide Modelle melden, sind fast immer echte Bugs; Befunde, bei denen sie sich uneinig sind, zeigen dir, wo dein Code wirklich mehrdeutig ist. Ein Konkurrenzmodell als Reviewer laufen zu lassen, klang absurd, bis ich es ausprobiert habe; jetzt ist es mein Standardschritt vor dem Merge. Das vollständige Muster steht in Codex als gegnerischer Reviewer.
6. Language-Server-Plugins (PHP LSP / TypeScript LSP). Echte Code-Intelligenz – Definitionen, Referenzen, Diagnosen – statt Navigation per grep und Raten. Das sind die leisesten Tools auf dieser Liste und möglicherweise die ertragreichsten: Sie erzeugen keine sichtbare Ausgabe, nur weniger falsche Änderungen. In einer Laravel-Codebasis bezahlt sich der PHP LSP täglich; setz den Server deiner Sprache ein.
7. Context7. Versionsgenaue Bibliotheksdokumentation, die bei Bedarf in den Kontext geholt wird, damit der Agent mit der API arbeitet, die existiert, statt mit der aus seinen Trainingsdaten. Wo es sich seinen Platz verdient: schnelllebige Pakete, Major-Versionen von Frameworks, alles, was du sonst von Hand prüfen würdest.
8. Playwright + Chrome DevTools MCP. Hände und Augen im Browser. Der Agent navigiert echte Seiten, füllt Formulare aus, liest Konsolen und Netzwerkanfragen und macht Screenshots der Ergebnisse – was aus „ich habe die UI geändert“ ein „ich habe die UI geändert und verifiziert, dass sie rendert“ macht. Bei Frontend-Arbeit schließt das die Schleife, die reine Codegenerierung offen lässt. Mein Beitrag zur Browser-Automatisierung mit der Playwright CLI behandelt die Skalierungsmuster.
Die CLIs (Hebelwirkung, die der Agent erbt)
9. gh (GitHub CLI). Überhaupt kein KI-Tool und nach Nutzung unter den Top drei in meinem Stack. Claude Code steuert jede CLI, die du installiert hast, also gibt gh ihm PRs, Issues, Checks und Releases ohne Browser oder API-Integration. Das allgemeine Prinzip ist wichtiger als dieses konkrete Tool: Jede skriptfähige CLI auf deinem Rechner ist bereits eine Fähigkeit des Agents. Prüfe deinen PATH, bevor du den Marktplatz prüfst.
10. Laravel Boost (Projekt-MCP). Mein Beispiel auf Projektebene für dasselbe Prinzip: ein MCP-Server in der .mcp.json dieses Repos, der Routen, Schema, Konfiguration, Logs und eine Tinker-Oberfläche bereitstellt. Jede Session in dieser Codebasis startet und kennt die Anwendung bereits. Was auch immer dein Stack ist, das Muster lässt sich verallgemeinern – das beste zehnte Tool auf deiner Liste ist das, das dem Agent die Grundwahrheit deines Projekts beibringt. Setz das Gegenstück deines Frameworks ein.
Was es nicht unter die zehn geschafft hat
Das Muster hinter den meisten Ausfällen ist Überschneidung – zwei Tools, die dieselbe Aufgabe beanspruchen, bedeuten, dass der Agent unvorhersehbar wählt, also muss eines davon gehen. Ein Stack ist ein System, keine Sammlung; jede Ergänzung belastet jede Session, ob sie genutzt wird oder nicht.
Der Entscheidungsrahmen: Welche davon brauchst du tatsächlich?
Installiere nicht zehn Tools. Bestimme zuerst deine Reibungspunkte:
- Der Agent macht plausible, aber falsche Änderungen in deiner Codebasis → LSP-Plugin für deine Sprache (#6), dann ein Projekt-MCP (#10).
- Der Agent nutzt selbstbewusst APIs, die es nicht mehr gibt → Context7 (#7).
- Du traust dem „fertig“ des Agents nicht → Superpowers (#1), dann Codex-Review (#5).
- Lange Sessions verlieren Tokens und Kohärenz → caveman (#3) und handoff (#4).
- Frontend-Änderungen, die du ohne Fensterwechsel nicht verifizieren kannst → Playwright/DevTools (#8).
- Du tippst immer wieder dieselben Anweisungen → das ist ein eigener Skill, und mit skill-creator (#2) wird er gebaut.
- Du lebst in GitHub →
gh(#9) ist eine Fünf-Minuten-Installation ohne jeden Nachteil.
Zwei Tools aus dieser Zuordnung, zwei Wochen lang genutzt, schlagen alle zehn an einem Nachmittag installiert. Disziplin beim Behalten – das zu entfernen, was seine Kontextkosten nicht sichtbar verdient hat – ist wichtiger als die Auswahl, und das ist die These meiner vollständigen Übersicht der Plugins, die ich tatsächlich nutze, falls du die Plugin-Ebene für sich betrachtet haben willst.
Wohin das führt
Die Entwicklung, die ich von der Marktplatzseite aus sehe: Die Skill-Ebene professionalisiert sich am schnellsten – Familien schmaler, gut getriggerter Skills schlagen Mega-Skills –, während sich die Plugin-Ebene um einige tragende Kategorien konsolidiert (LSPs, Dokumentation, Review, Browser). Die CLI-Ebene musste sich nie professionalisieren, weil sie schon da war; Agents haben vierzig Jahre Unix-Tooling nur neu relevant gemacht. Wenn sich deine Grundlagen stabilisiert haben, sind die fortgeschrittenen Skill-Techniken – Context Forking, Ausführung im Hintergrund, dynamische Injektion – die nächste Stufe, und ich halte das Playbook für fortgeschrittene Agent Skills genau für diesen Aufstieg aktuell.
Der Stack in diesem Beitrag wird sich bis nächstes Jahr wieder verschieben. Was sich nicht verschieben wird, ist die Methode: zuerst die Reibung, ein Tool nach dem anderen, rücksichtsloses Entfernen. Diese Methode ist die eigentliche Top 10.
Neben den Tools ist die andere Hälfte meiner täglichen Hebelwirkung eine Bibliothek praxiserprobter Prompts für genau diese Workflows – Review-Durchgänge, Refactorings, Audits –, die du dir alle kostenlos aus meiner Prompt-Bibliothek holen kannst.