Claude Code Must-Haves März ’26

Wir sind schon fast im zweiten Quartal des nicht mehr ganz so jungen Jahres – Zeit, sich die aktuellen Must-Haves für Claude Code anzusehen. Quasi die März-2026-Edition. Und das ist mein aktueller Stack …

Nach intensiver täglicher Nutzung hat sich einiges verändert: Browser DevTools MCPs gehören jetzt zum festen Setup, ContextMine ergänzt Context7 für interne Dokumentation, Session-Mining ersetzt fehlende Cross-Session-Memory, und statt einer Claude-Code-Instanz laufen bei mir mindestens zwei parallel. Die Basis aus dem Januar ist geblieben – aber der Stack hat sich vertieft.

Dieser Artikel ist ein frischer Snapshot: Was nutze ich heute wirklich, warum, und wie hängt es zusammen. Kein Grundlagen-Tutorial, kein vollständiger Feature-Guide – eine kuratierte Bestandsaufnahme aus der täglichen Praxis.

Kurze Unterbrechung: KI, die sich rechnet – und nicht nur beeindruckt.

Entwicklung von AI-Lösungen

Wir unterstützen Unternehmen dabei, KI sinnvoll und sicher in bestehende IT-Landschaften zu integrieren.

Entdecke klare Use Cases mit echtem Business Impact

---

Quick Setup: Der aktuelle Kern-Stack

Bevor es in die Details geht – hier die Übersicht.

# Browser DevTools MCPs (seit Januar im Einsatz, hier erstmals erwähnt)
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
claude mcp add firefox-devtools -- npx -y firefox-devtools-mcp@latest

# ContextMine: Docker Compose Setup (Anleitung → github.com/mayflower/contextmine)
# MCP-Verbindung nach dem Start:
# "contextmine": { "url": "http://localhost:8000/mcp" }

Plugins: Was sich bewährt hat

Was bisher geschah …

Vier Plugins haben sich seit dem Januar-Setup gehalten. Kein Plugin ist dazugekommen, keines rausgeflogen.

Language Server bleibt der größte einzelne Produktivitätsgewinn. Claude sieht Typfehler nach Edits, findet Referenzen, versteht Code als Struktur statt als Text. Ohne LSP würde ich nicht mehr arbeiten wollen.

Superpowers liefert das Skill-Framework für strukturierte Workflows – von Test-Driven Development über Systematic Debugging bis zu Brainstorming und Planning. Die operative Praxis des Skill-Schreibens behandle ich in einem eigenen Abschnitt weiter unten.

commit-commands automatisiert Git-Workflows: Commit-Messages aus tatsächlichen Änderungen, kontextbewusste PRs. pr-review-toolkit liefert Multi-Agent Code Reviews mit Confidence-Scoring vor jedem Merge.

Die vier zusammen bilden den stabilen Plugin-Kern. Kein Plugin ist dazugekommen, weil keines gefehlt hat. Marketplace hat dutzende Optionen – aber jedes Plugin kostet Context-Tokens bei Startup. Die Frage bleibt: „Löst das ein echtes Problem?“ Wenn nein, bleibt es draußen.

MCP-Server: Das erweiterte Trio

Context7 (bekannt)

Cloud-Dokumentation, versionsspezifisch, aus offiziellen Quellen. Für jede externe Library unverzichtbar. Die Nutzung hat sich nicht verändert – Context7 funktioniert einfach. Ein Prompt mit Library-Name und Version reicht, den Rest erledigt Context7: aktuelle Docs abrufen, relevante Abschnitte liefern, ohne Token-Overhead durch manuelles Copy-Paste.

ContextMine (neu)

ContextMine ist eine selbst-gehostete Applikation von Mayflower. Sie macht für interne Dokumentation, was Context7 für öffentliche Libraries macht: Indexieren und durchsuchbar machen. Der Stack läuft komplett lokal per Docker Compose – API, Worker und Admin-UI inklusive.

Der Unterschied: Context7 greift auf öffentliche Quellen zu – GitHub-Repos, offizielle Docs. ContextMine läuft lokal und indexiert alles, was du ihm gibst: interne Codebases, private Dokumentation, Confluence-Exports, proprietäre APIs. Beides ergänzt sich, ohne sich zu überschneiden.

# ContextMine ist eine vollständige selbst-gehostete Applikation (API + Worker + UI)
# Setup: https://github.com/mayflower/contextmine
git clone https://github.com/mayflower/contextmine.git
cd contextmine && cp .env.example .env  # GitHub OAuth + OpenAI API Key konfigurieren
docker compose up -d

# MCP-Verbindung in Claude Desktop / claude_desktop_config.json:
# "contextmine": { "url": "http://localhost:8000/mcp" }

In meinem Alltag nutze ich Context7 für Framework-Docs und ContextMine für projektspezifische Dokumentation. Die Trennung ist sauber: öffentlich vs. intern. Kein Tool versucht, das andere zu ersetzen – sie bedienen verschiedene Quellen mit demselben Ziel: Claude den richtigen Kontext geben, ohne dass ich ihn manuell zusammensuchen muss.

Browser DevTools MCPs (endlich erwähnt)

Im Januar-Artikel schlicht vergessen – dabei damals schon täglich im Einsatz. Die Browser DevTools MCPs geben Claude direkten Zugang zum Browser: Console, Network, DOM, Screenshots.

chrome-devtools MCP verbindet Claude Code mit Chrome DevTools Protocol. Claude sieht Console-Fehler, analysiert Network-Requests, inspiziert den DOM und kann Screenshots aufnehmen. Für Frontend-Debugging bedeutet das: Kein manuelles Copy-Paste von Fehlermeldungen mehr. Claude sieht direkt, was im Browser passiert.

firefox-devtools MCP bietet die gleiche Funktionalität für Firefox. Gleiche Use Cases, anderer Browser.

Konkrete Use Cases:

• Console-Fehler analysieren: Claude liest Console-Output und debuggt direkt
• Network-Requests prüfen: API-Responses inspizieren, Timing analysieren
• DOM-Inspektion: Elemente finden, Styles prüfen, Layout-Probleme identifizieren
• Visual Regression: Screenshots aufnehmen und vergleichen

# Chrome DevTools MCP
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

# Firefox DevTools MCP
claude mcp add firefox-devtools -- npx -y firefox-devtools-mcp@latest

Beide MCPs starten den Browser selbst — kein manuelles Öffnen, keine zusätzlichen Flags nötig.

Skills & Commands: Von Prompts zu Skills

Superpowers als Plugin ist eine Sache. Die operative Praxis des Skill-Schreibens eine andere. Hier geht es um Letzteres.

Die 3x-Regel: Wenn ich etwas dreimal manuell mache, wird ein Skill daraus. superpowers:writing-skills ist das Werkzeug dafür – ein Skill, der Skills schreibt. Das klingt meta, funktioniert aber: Ich beschreibe den Workflow, der Skill generiert die Struktur.

Das mayflow:update-Beispiel zeigt den natürlichen Entwicklungspfad. Es begann als einfaches Command – ein paar Zeilen, die CLAUDE.md aktualisieren. Dann wurde es ein globaler Skill unter ~/.claude/skills/, weil die Logik komplexer wurde. Heute ist es ein Skill in einem eigenen Plugin, massiv ausgebaut: Analyse von Conversation und Codebase, intelligente Verteilung von Insights auf verschiedene Dateien, Hierarchie-Management.

Dieser Pfad – Command → globaler Skill → Plugin-Skill – war nicht geplant. Er hat sich durch Iteration ergeben. Und genau das ist das Pattern: Nicht am Anfang die perfekte Abstraktion suchen, sondern organisch wachsen lassen.

Was das Wrapper-Pattern bedeutet: Superpowers trennt Commands und Skills. Commands sind dünne Entry Points – minimaler Code, der an einen Skill delegiert. Skills sind die volle Implementierung. Dieses Prinzip hat meine eigene Skill-Entwicklung geprägt: Keine monolithischen Prompts, sondern klare Verantwortlichkeiten.

Wann ein Prompt zum Skill wird: die Frequenz ist der offensichtlichste Trigger (3x-Regel). Aber auch Komplexität spielt eine Rolle: Wenn ein Workflow mehrere Schritte hat und die Reihenfolge wichtig ist, lohnt sich ein Skill – selbst bei geringerer Frequenz. Und dann gibt es die Team-Relevanz: Wenn andere denselben Workflow brauchen, ist ein Skill besser als eine Slack-Nachricht mit Anweisungen.

Der entscheidende Vorteil gegenüber Prompts: Ein Skill ist versioniert und iterierbar – und im Gegensatz zu Commands liegt beim Startup nur die Beschreibung im Context, nicht der vollständige Inhalt. Commands werden komplett geladen, Skills nur mit ihrer Beschreibung – der volle Inhalt kommt erst bei Aufruf. Die erste Version ist selten perfekt. Nach zwei bis drei Durchläufen wird sie typischerweise deutlich besser – weil die Praxis zeigt, was fehlt oder überflüssig ist.

Session-Mining: Claude liest seine eigenen Logs

Claude Code speichert jede Session als JSONL-Datei unter ~/.claude/projects/. Das ist kein Feature, das Anthropic bewirbt – es ist ein Nebenprodukt der Session-Verwaltung. Aber es ist nutzbar.

Wie es funktioniert: Jede Konversation wird als Folge von JSON-Objekten gespeichert – ein Objekt pro Message. Diese Dateien können direkt an Claude übergeben werden: „Lies diese Session und finde die Architektur-Entscheidung von letzter Woche.“ Claude durchsucht die Logs und extrahiert relevante Informationen.

Use Cases:

• Vergangene Entscheidungen rekonstruieren: „Was haben wir bei diesem Problem entschieden?“
• Erkenntnisse wiederfinden: „Welches Pattern haben wir für die API-Schicht gewählt?“
• Kontext zwischen Sessions überbrücken: Statt alles neu zu erklären, die relevante alte Session laden

Warum das wichtig ist: Cross-Session-Gedächtnis ist eines der größten offenen Probleme bei LLM-basierten Workflows. Jede neue Session startet bei null. Session-Mining überbrückt das ohne separates Memory-MCP, ohne Setup, ohne Konfiguration – nur die natürlich entstehenden Log-Dateien nutzen.

Grenzen: Session-Mining erfordert manuelle Anweisung – Claude durchsucht Logs nicht automatisch. Die JSONL-Dateien können groß werden. Und es ersetzt kein echtes Memory-MCP bei sehr großen Projekten mit hunderten Sessions. Es ist ein pragmatischer Workaround, kein vollwertiges Gedächtnis. Aber für die meisten meiner Projekte reicht es.

IDE-freies Arbeiten

Mein Hauptwerkzeug ist heute iTerm + Claude Code. Nicht als dogmatische Aussage, sondern als Beschreibung dessen, was sich eingependelt hat. PyCharm öffne ich kaum noch, VS Code gar nicht mehr. Was übrig bleibt: Fork für Git-Visualisierung und Merge-Konflikte, Sublime Text für schnelle Dateieinsicht ohne Kontext-Overhead.

Mehrere Instanzen parallel sind der eigentliche Produktivitätsgewinn. Nicht eine Claude Code Instanz, sondern mindestens zwei – oft mehr. Zwei Szenarien:

1. Parallele Tasks im selben Projekt. Eine Instanz arbeitet an Feature A, eine andere reviewed oder debuggt Feature B. Wie manuell gesteuerte Subagenten – jede Instanz hat ihren eigenen Kontext, ihre eigene Aufgabe.
2. Mehrere Projekte gleichzeitig. Blog-Artikel in einem Terminal, Code-Projekt in einem anderen, Dokumentation in einem dritten. Auch hier oft mehrere Instanzen pro Projekt.

Das ersetzt den IDE-Tabs-Workflow: Statt zwischen Dateien zu switchen, laufen unabhängige Kontexte parallel. Kein Context-Switch, weil jede Instanz ihren Zustand behält.

Wann Ausnahmen: Komplexe Merge-Konflikte löse ich in Fork – die visuelle Darstellung von Drei-Wege-Merges ist im Terminal nicht ersetzbar. Und wenn ich schnell in eine Datei schauen will, ohne eine Claude-Session zu starten, greife ich zu Sublime Text. Aber das sind Ausnahmen, nicht die Regel.

Das ist keine Aussage gegen IDEs. Es ist die Beobachtung, dass Claude Code für mich die meisten IDE-Workflows ersetzt hat – nicht durch eine bewusste Entscheidung, sondern weil ich irgendwann aufgehört habe, die IDE zu öffnen.

SDD als täglicher Workflow

Spec-Driven Development – erst Spec, dann Code – ist für mich kein gelegentliches Tool mehr, sondern Standard-Workflow für jede nicht-triviale Aufgabe. Nicht als Methodik-Predigt, sondern als persönliche Praxis, die sich bewährt hat.

Der konkrete Ablauf: superpowers:brainstorming ist der Einstiegspunkt. Dieser Skill ruft automatisch superpowers:writing-plans auf (Spec schreiben) und dann superpowers:executing-plans (Spec umsetzen). Das ist der SDD-Workflow als enforced Skill-Chain: Brainstormen → Planen → Umsetzen, in dieser Reihenfolge, ohne Abkürzungen.

Wann SDD: Bei allem, was mehr als eine Datei betrifft oder architektonische Entscheidungen erfordert. Wann nicht: Bugfixes, kleine Refactorings, Konfigurationsänderungen.

Wie es sich einfügt: Writing-Skills dokumentieren SDD-Patterns. Session-Mining hilft beim Rekonstruieren von Spec-Entscheidungen aus vergangenen Sessions. Browser DevTools liefern Feedback zur implementierten Spec. Die Tools greifen ineinander – nicht weil sie so geplant wurden, sondern weil SDD als strukturierendes Prinzip sie verbindet.

Best Practices: Was März 2026 anders macht

• Session-Mining als Low-Overhead-Alternative: Kein Setup, keine Konfiguration. Die Logs existieren bereits – man muss sie nur nutzen. Für die meisten Projekte reicht das statt eines dedizierten Memory-MCP.
• Browser DevTools als Feedback-Schleife: Claude sieht, was im Browser passiert. Das verkürzt Debug-Zyklen und eliminiert manuelles Beschreiben von visuellem Output.
• Skills als Code: Versioniert, iteriert, verbessert. Kein Prompt, der in der Konversation verloren geht, sondern ein Artefakt, das wächst.
• Context-Disziplin: Weniger MCPs ist mehr. Native Tools (Glob, Grep) zuerst – MCP-Indexierung nur wenn wirklich nötig. Jedes Plugin kostet Context-Tokens beim Startup. Nur installieren, was ein echtes Problem löst.
• Mehrere Instanzen statt einer: Parallele Kontexte statt sequenzielles Arbeiten. Der größte Workflow-Unterschied zum Einzelinstanz-Setup.
• Iteration über Perfektion: Kein Skill, kein Workflow ist beim ersten Mal fertig. Schnell bauen, schnell testen, nach zwei bis drei Durchläufen wird es gut.

Fazit

Stand März 2026? Wir haben noch lange keinen abgeschlossenen Prozess. Der Stack hat sich vertieft, nicht nur erweitert. ContextMine ist dazugekommen, Browser DevTools waren schon da, sie wurden nur nie erwähnt. Die wichtigere Veränderung liegt in der Integration: Session-Mining, parallele Instanzen, SDD als Workflow-Standard – das sind keine neuen Tools, sondern neue Arbeitsweisen mit vorhandenen Mitteln.

Weniger Tools, aber tiefer integriert. Das ist der Stand. Kein dogmatischer Guide – ein Snapshot, der sich weiterentwickeln wird. Die Basis funktioniert. Was als Nächstes kommt, zeigt die Praxis.