Claude Code Must-Haves 2026

Oktober 2025 stand ein Wechsel bevor. Meine Anthropic API-Kosten waren zu hoch geworden – unter anderem durch mein „RooCode Agile Software Development Team Framework“. Das sagt dir jetzt noch nichts, aber keine Sorge: auf diese Reise nehme ich dich ab nächster Woche hier im Blog mit …

Doch zurück zum Thema. Mein Chef schlug eine Alternative vor: Claude Code mit Team-Subscription. Innerhalb weniger Tage hatte ich Zugang – und stand vor einem Ökosystem, das sich gerade erst zu entfalten begann.

Die ersten Wochen waren überwältigend. Claude Code war ein Moving Target: Das Plugin-System kam im Oktober, während ich bereits produktiv damit arbeitete. Skills, MCPs, Hooks – überall neue Möglichkeiten, aber auch Entscheidungen. Was braucht man wirklich? Was ist nice-to-have? Und wie verhindert man, dass das Context-Window mit unnötigen Tools vollläuft?

Nach drei Monaten intensiver Exploration – von Oktober 2025 bis heute, Januar 2026 – habe ich Klarheit gewonnen. Nicht durch perfekte Planung, sondern durch Iteration. Durch ausprobieren, verwerfen, neu konfigurieren. Durch die Entdeckung von Game-Changern wie dem Superpowers-Plugin Ende November, das meine Arbeitsweise fundamental verändert hat.

Dieser Artikel ist keine vollständige Feature-Liste und kein Grundlagen-Tutorial. Es ist eine kuratierte Sammlung meiner persönlichen Must-Haves. Getestet in echten Projekten, optimiert für Context-Effizienz, bewährt im täglichen Einsatz. Stand Januar 2026, mit dem Wissen, dass Claude Code sich weiterentwickeln wird. Aber diese Basis funktioniert. Für mich. Und vielleicht ist sie ein guter Startpunkt für deinen eigenen Workflow.

Quick Setup: Die absoluten Essentials

Bevor wir in die Details gehen, sind hier meine Empfehlungen, mit denen du starten solltest.

Zunächst die 2 absoluten Must-Haves für jeden:

• Language Server für deine Hauptsprache: Code Intelligence ist nicht optional. Ohne Echtzeit-Typinformationen arbeitet Claude im Dunkeln. Mit Language Server sieht Claude Typfehler sofort nach Edits, versteht semantische Zusammenhänge und kann „Go to Definition“ und „Find References“ nutzen. Das ist der größte einzelne Produktivitätsgewinn.
• Superpowers Plugin: Transformiert Claude von Helfer zu Senior Developer. 20+ production-proven Skills für strukturierte Workflows: Test-Driven Development, Systematic Debugging, Structured Planning. Seit meiner Entdeckung Ende November nutze ich es täglich. Game-Changer.

Außerdem empfehle ich dir folgende Dinge:

• Context7 MCP: Up-to-date Dokumentation ohne Token-Overhead. Real-time docs, version-spezifisch, aus offiziellen Quellen. Für jede neue Library unverzichtbar. (API-Key optional, aber empfohlen)
• Sequential Thinking MCP: Strukturiertes Problem-Solving für komplexe Aufgaben. LLM-basiertes methodisches Denken, wie ein Senior Architect der erst denkt, dann codet. Am besten zusammen mit Context7.

 # Language Server (Beispiele für gängige Sprachen)
 # Hinweis: Benötigt claude-code-lsps Marketplace
 /plugin marketplace add boostvolt/claude-code-lsps
 /plugin install pyright@claude-code-lsps        # Python
 /plugin install vtsls@claude-code-lsps          # TypeScript/JavaScript
 /plugin install rust-analyzer@claude-code-lsps  # Rust
 /plugin install gopls@claude-code-lsps          # Go
 ​
 # Superpowers Plugin
 /plugin marketplace add obra@superpowers-marketplace
 /plugin install superpowers
 ​
 # Context7 MCP (API-Key optional, aber empfohlen für höhere Rate Limits)
 claude mcp add context7 -- npx -y @upstash/context7-mcp@latest
 ​
 # Sequential Thinking MCP
 claude mcp add @modelcontextprotocol/server-sequential-thinking

Plugins: Die 4 Must-Haves

Das Plugin-System kam im Oktober 2025. Nach drei Monaten intensiver Nutzung haben sich für mich diese vier Plugins als essentiell herausgestellt.

1. Language Server für deine Hauptsprache

Verfügbar: pyright (Python), vtsls (TypeScript/JavaScript), rust-analyzer (Rust), gopls (Go)

Language Server Protocol (LSP) gibt Claude Echtzeit-Typinformationen und semantisches Code-Verständnis. Das bedeutet: „Go to Definition“, „Find References“, Typfehler sind sofort nach Edits sichtbar. Ohne LSP arbeitet Claude mit Textfiles, mit LSP versteht Claude die Codebase als strukturiertes System.

Meine Erfahrung: Der größte einzelne Produktivitätsgewinn. Claude sieht Typfehler sofort nach Edits, bevor Tests laufen. Refactorings werden sicherer, weil Claude alle Verwendungen einer Funktion findet. Die Differenz ist so groß, dass ich ohne LSP nicht mehr arbeiten möchte.

 # Installation (Marketplace erst hinzufügen)
 /plugin marketplace add boostvolt/claude-code-lsps
 ​
 # Dann Plugin installieren (Beispiel Python)
 /plugin install pyright@claude-code-lsps
 ​
 # Oder TypeScript/JavaScript (vtsls statt typescript-lsp)
 /plugin install vtsls@claude-code-lsps

2. Superpowers

Superpowers sind 20+ production-proven Skills für strukturierte Workflows. Test-Driven Development, Systematic Debugging, Root Cause Tracing, Structured Planning. Entstanden aus realer Praxis, von der Community getestet und iteriert.

Superpowers transformiert Claude von reaktivem Helfer zu proaktivem Senior Developer. Statt nur auf Anfragen zu reagieren, folgt Claude strukturierten Workflows: Erst testen, dann implementieren. Erst Root Cause finden, dann fixen. Erst brainstormen, dann coden.

Die Skills codieren Best Practices, die sonst verloren gehen. Red-Green-Refactor nicht als Theorie, sondern als enforced Workflow. Debugging nicht als Trial-and-Error, sondern als vier-Phasen-Framework. Die Ergebnisse sind höhere Code-Qualität, weniger Rework, bessere Architektur-Entscheidungen.

Meine Nutzung: Täglich seit Entdeckung Ende November. Unverzichtbar. Das Wrapper-Pattern (Commands als Entry Points, Skills als Implementation) hat meine eigene Skill-Entwicklung beeinflusst. Mehr dazu im Abschnitt „Skills & Commands“.

 # Installation
 /plugin marketplace add obra@superpowers-marketplace
 /plugin install superpowers

3. commit-commands

Bei gcommit-commands handelt es sich um eine Git-Workflow-Automation. Intelligente Commit-Messages basierend auf tatsächlichen Änderungen, automatisierte Pull Requests mit kontextbewussten Beschreibungen.

commit-commands analysiert git diff und git log für Commit-Message-Vorschläge, erstellt PRs mit Summary und Test Plan, folgt Repository-spezifischen Commit-Konventionen.

Nutzen: Eliminiert manuelle Git-Workflows. Keine handgeschriebenen Commit-Messages mehr, die nach 20 Minuten Coding generisch klingen. Keine PRs, bei denen man vergisst, was eigentlich geändert wurde. Claude sieht alle Änderungen und fasst sie strukturiert zusammen.

 # Installation
 /plugin install commit-commands

4. pr-review-toolkit

Das pr-review-toolkit bietet Multi-Agent Code Reviews mit Confidence-Scoring. Mehrere spezialisierte Review-Agenten prüfen verschiedene Aspekte: Tests, Error Handling, Type Design, Code Quality.

Features: Jeder Agent gibt Feedback mit Confidence-Score (0-100 %). Filtert False Positives durch Multi-Agent-Konsens. Erstellt strukturierte Review-Reports mit kategorisierten Findings.

Nutzen: Erhöht Code-Qualität massiv vor jedem Merge. Nicht als Ersatz für Human Review, sondern als erster Filter. Findet Randfälle, die in manueller Review übersehen werden. Besonders wertvoll für Solo-Entwickler ohne Team-Review.

 # Installation
 /plugin install pr-review-toolkit

MCP-Server: Die Essentials

MCP-Server erweitern Claude Code mit externen Integrationen. Aber: Weniger ist mehr. Zu viele MCPs verbrauchen Context; manchmal über 40 % des 200k Context-Windows nur für MCP-Tools bei Startup. Die Kunst ist, die richtigen MCPs zu wählen.

1. Context7 – Up-to-date Documentation

Context7 liefert real-time, versionsspezifische Dokumentation direkt in Prompts. Keine veralteten Docs, kein manuelles Suchen, kein Token-Overhead durch Copy-Paste.

Features:

• Offizielle Quellen (GitHub, offizielle Docs)
• Version-spezifischer Content (z.B. Next.js 14.3.0-canary.87)
• Millisekunden Response-Zeit
• Resolve Library ID + Query Docs Workflow

Das ist vor allem deswegen essentiell, da Claude’s Knowledge Cutoff Januar 2025 ist. Frameworks ändern sich monatlich. Context7 löst das: Aktuelle Docs, ohne dass du sie manuell suchen und in Prompts kopieren musst. Das spart Token und verhindert Halluzinationen basierend auf veralteter Information.

Meine Nutzung: Für jede neue Library unverzichtbar. Gerade bei Framework-Updates (React 19, Next.js 15) ist Context7 der Unterschied zwischen funktionierendem Code und stundenlanger Debugging-Session wegen deprecated APIs.

 # Installation
 claude mcp add context7 -- npx -y @upstash/context7-mcp@latest
 ​
 # Optional: API-Key für höhere Rate Limits
 # Registriere dich auf context7.com/dashboard und füge Key in Config hinzu

Verwendung im Prompt:

 Ich nutze Next.js 15.1.0. Zeig mir, wie die neuen Server Actions funktionieren.

Context7 resolved automatisch /vercel/next.js/v15.1.0 und liefert aktuelle Docs.

2. Sequential Thinking – Strukturiertes Problem-Solving

Dabei handelt es sich um LLM-basiertes strukturiertes Denken für komplexe Probleme. Methodisches Durcharbeiten mit expliziten Reasoning-Chains, Revision von Ansätzen bei Bedarf.

Features:

• Erweiterte Reasoning-Chains (nicht nur erste Idee, sondern Alternativen)
• Explizite Thinking-Steps vor Code-Generierung
• Revision-Mechanismus wenn Ansatz nicht funktioniert
• Integration mit anderen MCPs (z.B. Context7)

Warum das nütlich ist? „Like having a senior architect who thinks before coding.“ Es ist besonders wertvoll bei architektonischen Entscheidungen, komplexen Refactorings, oder wenn mehrere Lösungswege möglich sind. Sequential Thinking macht das Reasoning explizit und nachvollziehbar.

Am besten sollte es mit Context7 zusammen verwendet werden. Sequential Thinking für strukturiertes Denken, Context7 für aktuelle Framework-Informationen.

 # Installation
 claude mcp add @modelcontextprotocol/server-sequential-thinking

3. Memory Bank / Serena – für große Codebases

Das wird eigentlich nur für Codebases >1000 Dateien oder hochkomplexe Architekturen benötigt.

Memory Bank: Cross-Session Memory – persistent über Sessions. Speichert Architektur-Entscheidungen, häufig genutzte Patterns, Projekt-Kontext.

Serena: Semantic code retrieval und editing tools. Versteht Code semantisch (nicht nur Text-Match), findet relevante Code-Stellen basierend auf Intent.

Trade-off: Setup-Aufwand (Indexing, Konfiguration) vs. Token-Einsparung. Für kleinere Projekte überwiegt der Overhead den Nutzen.

Meine Empfehlung ist klar: Nutze die beiden erst bei echtem Bedarf. Wenn du merkst, dass du regelmäßig mit Context-Overflow kämpfst und die Codebase mehr als 1000 Dateien hat, lohnt sich der Invest. Vorher solltest du native Tools nutzen (siehe nächster Abschnitt).

Native Tools First – die 80%-Lösung

Wichtige Erkenntnis: Für die meisten Projekte (<1000 Dateien) reichen native Tools, wie beispielsweise:

• Glob (File Pattern Matching): **/*.js, src/**/*.ts – findet Files blitzschnell
• Grep (ripgrep-powered): Fulltext-Suche mit Regex-Support, extrem schnell
• Explore Subagent (Haiku-powered): Schnelle Reconnaissance für Codebase-Struktur

Sie benötigen kein Setup, produzieren keinen Context-Overhead und sind sofort verfügbar. Glob und Grep sind so schnell, dass Indexing oft unnötig ist.

Wann möchtest du also ein MCP nutzen? Nur bei >1000 Dateien, komplexer Architektur, oder wenn semantic Queries nötig sind (nicht nur Text-Match, sondern Intent-basiert).

Philosophie: „Search, Don’t Index.“ Moderne Suchtools sind so schnell, dass Vorab-Indexing oft Overkill ist. Erst wenn Suche zum Bottleneck wird, MCPs einführen.

Skills & Commands: Progressive Disclosure

Skills sind seit Oktober 2025 eines der mächtigsten Features in Claude Code. Sie erlauben es, strukturierte Workflows zu definieren, die Claude befolgen muss. Ich nutze das Wrapper-Pattern – gelernt von Superpowers.

Das Wrapper-Pattern

Konzept: Commands als dünne Entry Points (minimal Context) + Skills als volle Implementation (on-demand geladen, kein Startup-Cost).

Konkret: Ein Command ist 6 Zeilen YAML, ~200 Bytes. Weist nur auf den Skill hin. Der Skill enthält die volle Implementierung (1.000+ Zeilen). Der Skill wird nur geladen, wenn der Command aufgerufen wird.

Ein Beispiel aus meiner Praxis, der Command update (6 Zeilen, 189 Bytes):

 name: update
 description: Analyze conversation/codebase and intelligently distribute insights
 command: |
   Using the 'mayflow:updating-documentation' skill, analyze...

Skill: updating-documentation (1.326 Zeilen, volle Implementierung)

• Analysiert Conversation + Codebase
• Verteilt Insights auf CLAUDE.md, README.md, docs/
• Handhabt Hierarchien und Update-Strategien
• Volle Logik, nur geladen bei Nutzung

Context-Mathematik:

• Start: +93 Tokens für Command (+14% bei kleinem Projekt)
• Bei Growth: Ohne Wrapper wären 1.326 Zeilen Skill im System-Prompt → +2.087 Tokens
• Mit Wrapper: Nur 93 Tokens bei Startup, volle 2.087 nur wenn genutzt
• Einsparung bei Growth: -1.994 Tokens (-64%)
• Break-Even: 2-3 Wochen bei täglicher Nutzung

Warum ich es nutze? Wegen der Context-Effizienz bei Skalierung. Ich kann unbegrenzt Skills hinzufügen, ohne Startup-Context zu belasten. Klare Trennung zwischen Entry Point (was macht der Command?) und Implementierung (wie wird es gemacht?). Progressive Disclosure: Der Nutzer sieht zuerst einfache Command-Liste, Details nur bei Bedarf.

Meine Inspiration dafür ist Superpowers – bisher das einzige Plugin, das ich mit diesem Ansatz kenne. Die 20+ Skills von Superpowers wären ohne Wrapper-Pattern nicht praktikabel (und sie würden zehntausende Tokens bei Startup verbrauchen).

Eigene Skills entwickeln

Wann sinnvoll: Wiederkehrende Workflows, team-spezifische Prozesse, komplexe Multi-Step-Tasks.

Speicherorte:

• Personal Skills: ~/.claude/skills/ – verfügbar über alle Projekte hinweg
• Project Skills: .claude/skills/ – team-shared via Git, projekt-spezifisch
• Plugin Skills: Automatisch verfügbar wenn Plugin installiert (wie Superpowers)

Und so sieht der Workflow dazu aus:

1. Erst für eigene Nutzung entwickeln (Personal Skills)
2. Im Projekt testen und iterieren
3. Bei Team-Bedarf: In Project Skills verschieben (.claude/skills/)
4. Bei höherer Komplexität oder breiterer Nutzung: Als Plugin packen

Plugin für Team-Sharing: Wenn Skills komplex werden (mehrere Files, Dependencies), oder wenn du sie über mehrere Teams/Projekte sharen willst, ist das Plugin-Format sinnvoll. Aber: Start simple! Personal Skill → Project Skill → Plugin ist der natürliche Entwicklungspfad.

Iteration wichtig: Keine Skill-Version ist beim ersten Mal perfekt. Erst schreiben, dann nutzen, dann iterieren. Nach 2-3 Iterationen sind Skills typischerweise viel besser als beim ersten Draft.

Fortgeschritten: Context Forking (v2.1.0)

Für token-intensive Skills gilt, dass du sie in isolierten Sub-Agent-Contexts laufen lassen solltest. Das ist relevant für große Codebase-Analysen (>1000 Dateien), Research-Tasks mit vielen External Resources oder Parallel Workflows.

 ---
 name: heavy-analysis
 context: fork          # Run in separate sub-agent
 agent: explore         # Optional: Use specific agent type
 ---

Damit bleibt der Main Context sauber, parallele Skill-Execution ist möglich und es gibt eine Token-Isolation für schwere Operationen. Das ist das Context-Management-Equivalent zum Wrapper-Pattern: Kosten nur bei Nutzung, nicht bei Startup.

Best Practices

• Skill-First für wiederkehrende Tasks: Wenn du etwas mehr als 3x machst, ist ein Skill sinnvoll
• Progressive Disclosure nutzen: Große Skills in separate Files aufteilen (Main-Skill + Helper-Files)
• Testing mit repräsentativen Queries: Nutze echte Use Cases zum Testen, nicht konstruierte Beispiele
• Wiederverwendbarkeit: Skills sind nutzbar von Commands, Agents, Hooks – einmal schreiben, mehrfach nutzen

Hooks: Event-basierte Automatisierung

Hooks automatisieren Workflows event-basiert. Neun Lifecycle-Events sind aktuell (Stand Januar 2026) verfügbar: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, und mehr. Mein Fokus liegt auf Auto-Formatierung und Security.

PostToolUse: Auto-Formatierung

Wann: Nach jedem Edit/Write automatisch formatieren.

Dateityp-spezifisch: Python (ruff), TypeScript (prettier), Go (goimports), Kotlin (ktlint), Markdown (prettier). Jede Sprache hat eigene Formatter, Hooks können sie alle orchestrieren.

Meine Empfehlung: ryanlewis/claude-format-hook

• Battle-tested, multi-language Support
• Unterstützt JS/TS (Biome mit Fallback zu Prettier), Python (ruff), Go (goimports), Kotlin (ktlint), Markdown (prettier)
• Graceful Degradation: Wenn Formatter fehlt, Hook schlägt nicht fehl (via || true). Nie Claude Code unterbrechen.

Installation:

 # Clone Repository
 git clone https://github.com/ryanlewis/claude-format-hook.git ~/.claude/hooks/format
 ​
 # Executable machen
 chmod +x ~/.claude/hooks/format/format_hook.sh
 ​
 # In Claude Code Settings.json hinzufügen (siehe unten)

Config-Beispiel (Settings.json):

 {
   "hooks": [
     {
       "trigger": "PostToolUse",
       "commandMatch": "Edit|Write|MultiEdit",
       "command": "~/.claude/hooks/format/format_hook.sh"
     }
   ]
 }

Wie es funktioniert: Nach jedem Edit/Write ruft Claude Code den Hook auf. Der Hook erkennt Dateityp, wählt passenden Formatter, formatiert die Datei. Falls Formatter fehlt oder fehlschlägt: || true verhindert Error. Claude Code arbeitet weiter.

PreToolUse: Security

Wann: Vor Tool-Ausführung – kann blockieren oder modifizieren.

Use Cases:

• Blockiert gefährliche Commands (rm -rf, dd, mkfs)
• Schützt sensitive Files (.env, package-lock.json, .git/)
• Exit Code 2 = Tool wird blockiert, Claude bekommt Error-Message

Neu seit v2.0.10: Input Modification

Statt Tool zu blockieren, kann Hook Input transparent korrigieren. Beispiel: Claude will .env committen → Hook entfernt .env aus Staging → Command läuft weiter, ohne .env.

Beispiel: .env und .git/ Schutz

 #!/bin/bash
 # PreToolUse Hook: Block .env and .git/ modifications
 ​
 TOOL_NAME="$1"
 INPUT_JSON="$2"
 ​
 # Check if Edit/Write targets .env or .git/
 if echo "$INPUT_JSON" | jq -e '.file_path | test("\\.env$|\\.git/")' > /dev/null; then
   echo "BLOCKED: Cannot modify .env or .git/ files" >&2
   exit 2  # Exit Code 2 = Block Tool
 fi
 ​
 exit 0  # Allow Tool

Input Modification (neu):

 #!/bin/bash
 # PreToolUse Hook: Remove .env from git add
 ​
 TOOL_NAME="$1"
 INPUT_JSON="$2"
 ​
 # If Bash(git add) includes .env, modify input
 if [[ "$TOOL_NAME" == "Bash" ]]; then
   COMMAND=$(echo "$INPUT_JSON" | jq -r '.command')
   if [[ "$COMMAND" =~ "git add" ]] && [[ "$COMMAND" =~ ".env" ]]; then
     # Remove .env from command
     MODIFIED=$(echo "$COMMAND" | sed 's/\.env//g')
     # Return modified input
     jq -n --arg cmd "$MODIFIED" '{command: $cmd, updatedInput: true}'
     exit 0
   fi
 fi
 ​
 exit 0  # No modification

Best Practices 2026

„Block-at-Submit“ statt „Block-at-Write“

Alte Strategie: Block bei jedem Write → viele Unterbrechungen, Claude wird oft gestoppt.

Neue Strategie: Let agent finish plan → validate final result. Statt jeden Edit zu blocken, lasse Claude kompletten Plan durchführen. Am Ende (UserPromptSubmit Hook oder vor Commit) validieren.

Empfehlung vom Creator (Ryan Lewis): „Hooks am Ende der Arbeit laufen lassen, nicht während der Arbeit.“ Weniger Interrupts, flüssigere Workflows, bessere UX.

Input Modification over Blocking

Nutze updatedInput in PreToolUse Hooks. Korrigiere Inputs statt zu blockieren. Macht Korrekturen unsichtbar für Claude → keine Error-Messages, keine Unterbrechungen.

Beispiel: Claude will package-lock.json editieren → Hook ersetzt durch /dev/null → kein Edit, keine Error.

Neu in v2.1.0: updatedInput funktioniert jetzt auch mit ask Return (Hook kann Input modifizieren UND User-Bestätigung anfordern). Plus: once: true Option für Hooks – läuft nur einmal pro Event (Performance-Optimierung für teure Operationen wie Linting).

Graceful Degradation

Hooks sollten nie Claude Code unterbrechen. || true für optionale Formatierung. Error Handling einbauen (falls Formatter fehlt, nicht fehl schlagen).

Präzise scopen

Spezifische Commands matchen (Edit|Write|MultiEdit), nicht breite Tool-Kategorien. Reduces false positives.

Meine Erfahrung: Weniger Hooks = stabiler, weniger Überraschungen. Ich nutze nur Auto-Formatierung (PostToolUse) und .env-Schutz (PreToolUse). Mehr würde Context und Complexity erhöhen, ohne proportionalen Nutzen.

Best Practices: Learnings aus 3 Monaten

Nach drei Monaten intensiver Claude Code-Nutzung haben sich diese Practices bewährt.

Context-Management

Problem: MCP-Tools können 40%+ Context verbrauchen.

Beispiel aus meinen Tests: 81.986 Tokens nur für MCP-Tools bei Startup (41% des 200k Context-Windows!). Das ist fast die Hälfte des verfügbaren Context – bevor auch nur eine Zeile Code geladen wurde.

Lösung: Weniger ist mehr

• Starte mit 2-3 MCPs, nicht 10+. Ich nutze Context7 + Sequential Thinking. Das war’s. Alles andere on-demand aktivieren.
• /context Command nutzen für Usage-Breakdown. Zeigt: System prompt, System tools, MCP tools, Memory files, Messages, Free space. Damit siehst du, was Context frisst.
• Meine Erfahrung: 4 Plugins + 2 MCPs = sweet spot.
  • Language Server + Superpowers + commit-commands + pr-review-toolkit (Plugins)
  • Context7 + Sequential Thinking (MCPs)
  • Alles andere: on-demand aktivieren, nicht permanent laden

Native Tools First:

Für <1000 Dateien reichen Glob/Grep. Explore Subagent für schnelle Reconnaissance. Nur bei echtem Bedarf MCP-Indexing (Memory Bank/Serena).

Selektives Aktivieren:

Nicht alles auf einmal. McPick Tool für Toggle-Management (MCPs temporär aktivieren/deaktivieren). Per-Project unterschiedliche MCPs: Frontend-Projekt braucht andere Tools als Backend-Microservices.

Skalierung & Organisation

CLAUDE.md Hierarchie:

Claude Code lädt drei CLAUDE.md Files in dieser Reihenfolge:

1. User-global: ~/.claude/CLAUDE.md (persönliche Präferenzen, IDE-Settings, private API Keys)
2. Projekt-Root: CLAUDE.md (Git-committed, Team-shared, Projekt-Kontext)
3. Lokal: CLAUDE.local.md (Git-ignored, maschinenspezifisch, lokale Paths)

Tipp: Language Configuration (v2.1.0) – Für internationale Teams oder nicht-englische Dokumentation kannst du jetzt Claude’s Antwortsprache konfigurieren:

 // In .claude/settings.json oder ~/.claude/settings.json
 {
   "language": "german"  // oder "japanese", "spanish", "french", etc.
 }

Das ist nützlich für lokalisierte Commit-Messages, Dokumentation in Landessprache, oder Bildungsprojekte. Kombinierbar mit CLAUDE.md für hybride Setups (z.B. Code-Kommentare auf Englisch, Erklärungen auf Deutsch).

Was gehört in CLAUDE.md (Projekt-Root)?

• Common bash commands (Build, Test, Deploy)
• Code Style Guidelines (Prettier Config, Linting Rules)
• Key files/Architecture (Wo ist was? Welche Files sind zentral?)
• Testing instructions (Wie Tests laufen, was sie prüfen)
• Wichtige Befehle (Project-spezifische Scripts)

Beispiel:

 # CLAUDE.md
 ​
 ## Build & Test
 - npm run build - TypeScript compilation
 - npm test - Jest tests (must pass before commit)
 ​
 ## Architecture
 - src/core/ - Business Logic (pure functions)
 - src/api/ - Express routes (RESTful)
 - src/db/ - Database layer (Prisma)
 ​
 ## Code Style
 - Prettier enforced via pre-commit hook
 - ESLint for static analysis
 - No any types in TypeScript (use unknown instead)

Plugin-Strategie:

• Start minimal: Language Server + Superpowers
• Erweitere bei Bedarf: commit-commands, pr-review-toolkit
• Nicht „weil verfügbar“, sondern „weil benötigt“

Marketplace hat dutzende Plugins. Die Versuchung ist groß, alles auszuprobieren. Aber jedes Plugin kostet Context. Die Frage ist nicht „Ist das cool?“, sondern „Löst das ein echtes Problem, das ich gerade habe?“.

Permissions (v2.1.0: Wildcard-Support):

Seit v2.1.0 unterstützen Bash-Permissions Wildcards: Bash(npm *) erlaubt alle npm-Commands statt dutzende einzelne Rules. Das vereinfacht Permission-Management massiv:

 {
   "permissions": {
     "allow": [
       "Bash(npm *)",      // Alle npm-Befehle
       "Bash(git *)",      // Alle git-Befehle
       "Bash(pytest *)"    // Alle pytest-Befehle
     ]
   }
 }

Skills vs. Commands:

• Commands: User-Convenience (dünne Wrapper), Entry Points
• Skills: Implementation (volle Logik), on-demand geladen
• Progressive Disclosure: Unbegrenzte Skills ohne Context-Penalty (via Wrapper-Pattern)

Meine Empfehlung:

1. Practice First: Werkzeuge für eigenen Bedarf entwickeln. Nutze Claude Code, um mit Claude Code zu arbeiten (Dogfooding).
2. Dann dokumentieren: Was funktioniert, kommt in CLAUDE.md. Was nicht funktioniert, fliegt raus.
3. Dann teilen: Plugin erstellen bei Team-Bedarf. Erst wenn es bei dir funktioniert, macht Sharing Sinn.

Iteration & Lernen

Iteration ist normal: Die erste Version eines Skills oder Hooks ist gut. Nach 2-3 Iterationen ist sie typisch viel besser. Nicht Perfektion am ersten Tag erwarten. Stattdessen: Schnell bauen, schnell testen, schnell iterieren.

Moving Target: Claude Code entwickelt sich schnell. Plugin-System kam im Oktober (während ich es bereits nutzte). Hooks bekamen Input Modification in v2.0.10. Was heute Best Practice ist, kann morgen obsolet sein.

Flexibel bleiben statt an perfektem Plan festhalten: Neue Features nutzen, sobald sie kommen. Alte Workflows anpassen, wenn bessere Alternativen verfügbar sind.

Community-Learning: Von anderen Plugins lernen. Superpowers war mein Game-Changer; nicht nur wegen der Skills, sondern wegen des Wrapper-Patterns, das ich dann für eigene Skills adaptiert habe.

Marketplace explorieren: Best Practices adaptieren, nicht blind kopieren. Was für andere funktioniert, muss nicht für dich funktionieren (und umgekehrt).

Feedback-Loops: Claude Tools geben Feedback: Screenshots (visuelle Validierung), Tests (funktionale Validierung), Linting (Code-Quality). Nutze sie.

Claude selbst nutzen für Plugin-Entwicklung. Dogfooding: Was du baust, selbst nutzen. Wenn du es nicht nutzen würdest, warum sollte es jemand anderes nutzen?

Fazit: Von Überforderung zu Klarheit

Von Überforderung durch Optionen zu klaren Must-Haves – das war meine Reise in den letzten drei Monaten. Oktober 2025 hatte ich Zugang zu Claude Code. Anfang Januar 2026 habe ich ein Setup, das funktioniert.

Der Weg dorthin war nicht linear. Das Plugin-System kam im Oktober, mitten in meine Nutzung. Und während ich die finalen Versionen dieses Artikels schrieb, wurde Claude Code 2.1.0 released – mit Features wie Skill Hot-Reload und Context Forking, die genau die Herausforderungen addressieren, die ich in den letzten Monaten erlebt hatte. Statt Probleme waren das aber Chancen: Neue Möglichkeiten nutzen, Workflows anpassen. Flexibilität war wichtiger als vollständige Vorplanung.

Die wichtigste Erkenntnis: Weniger ist mehr.

Context-Effizienz schlägt Feature-Fülle. Vier gut gewählte Plugins sind besser 20 „interessante“ Plugins. Nutze native Tools statt sofort auf MCPs zu setzen. Nicht „weil verfügbar“, sondern „weil benötigt“.

Die Kern-Empfehlungen

Ausblick

Claude Code entwickelt sich weiter. Neue Features kommen kontinuierlich. Diese Empfehlungen sind Stand Januar 2026 – kein dogmatischer Guide, sondern ein Snapshot.

Das Community-Ökosystem wächst. Marketplaces, Plugins, Skills. Täglich kommen neue Möglichkeiten hinzu, spannende Entwicklungen sind zu erwarten.

Meine Nutzung und Learnings gehen weiter. Das ist kein abgeschlossener Prozess. Es heißt: Weiter experimentieren, weiter lernen, weiter iterieren.

Das Setup funktioniert für mich. Nimm es als Startpunkt für deinen eigenen Workflow.

Nicht als Blaupause, sondern als Inspiration. Nicht als vollständige Feature-Liste, sondern als kuratierte Sammlung. Nicht als perfekte Lösung, sondern als Ausgangspunkt für deine eigene Exploration.

Oktober 2025 stand ich vor einem Neuanfang. Anfang Januar 2026 habe ich Klarheit. In drei Monaten: von „Was brauche ich?“ zu „Das funktioniert“. Der nächste Abschnitt beginnt jetzt.