Der komplette Builder-Guide für Claude Code 2.0: Von Nebenfragen bis zum Multi-Agent-Review

Claude Code 2.0 versteht man am besten als ein funktionierendes System, nicht als eine größere Autovervollständigungs-Box. Das wirklich nützliche Upgrade ist das Betriebsmodell rund um den Agenten: Nebenfragen, die den Haupt-Thread nicht verunreinigen, wiederholte Prüfungen, die im Hintergrund laufen, während Sie arbeiten, Aufwandssteuerungen zur Anpassung der Denkprozesse an das Risiko, Skills, die Prozeduren nur bei Bedarf laden, ein Gedächtnis (Memory), das neue Sitzungen überdauert, und Review-Agenten, die einen Pull Request aus verschiedenen Blickwinkeln prüfen können.

Stand 11. August 2026 ist die lokale Installation von Claude Code, die für diesen Leitfaden geprüft wurde, 2.1.227. Das offizielle Claude Code Changelog führt v2.1.227 in der Dokumentation als aktuelles Release auf, mit Zuverlässigkeits-Fixes rund um Feature-Flags, GitHub Action Bash-Ausführung, /tui, das Verhalten des Slash-Befehlsmenüs und Performance. Das Produkt entwickelt sich schnell weiter, betrachten Sie dies also als einen Implementierungsleitfaden für die aktuelle 2.1.x-Linie und nicht als ein in Stein gemeißeltes Handbuch.

Wenn Sie noch evaluieren, ob ein Agenten-gesteuerter Coding-Workflow (Agentic Coding Workflow) in Ihr Team passt, beginnen Sie mit der Basis: Claude Code kann ein Repo lesen, Befehle ausführen, Dateien bearbeiten und Ergebnisse innerhalb eines Agenten-Loops verifizieren. Die Frage lautet nicht mehr: "Kann es Code schreiben?" Die Frage ist, ob Sie genügend Prozesse darum herum haben, um diese Schleife nützlich zu halten. Das ist derselbe Grund, warum wir die Agenten-Implementierung von Prompt-Experimenten in unserem KI-Agenten-Implementierungs-Guide und unserer Arbeit an Agentic Coding Workflows trennen.

Das mentale Modell: Schützen Sie den Haupt-Thread

Der zentrale Fehler bei Coding-Agenten ist es, die Unterhaltung wie einen endlosen Notizblock zu behandeln. Jede Nebenfrage, eingefügte Logs, fehlgeschlagene Vermutungen, halbfertige Pläne und "Wenn du schon mal hier bist"-Anfragen konkurrieren um den Kontext. Claude Code 2.0 gibt Buildern mehr Möglichkeiten, diese Arbeit aufzuteilen:

• Nutzen Sie /btw, wenn die Antwort nicht Teil des Hauptprotokolls (Transcript) werden soll.
• Nutzen Sie einen Subagenten, wenn etwas Tools, Dateizugriffe oder Exploration in einem separaten Kontext benötigt.
• Nutzen Sie /loop, wenn eine Prüfung wiederholt werden soll, ohne dass Sie sie manuell anstoßen müssen.
• Nutzen Sie Skills, wenn ein Workflow so wiederholbar ist, dass er eine lokale Prozedur verdient.
• Nutzen Sie das Gedächtnis (Memory), wenn eine Regel oder Korrektur die nächste frische Sitzung überdauern soll.

Das ist der praktische Paradigmenwechsel. Ein gutes Claude-Code-Setup ist nicht "eine riesige CLAUDE.md". Es ist eine Reihe von kleinen, fokussierten Kanälen für die jeweils richtige Art von Kontext.

/btw: Fragen ohne den Verlauf zu verunreinigen

Die offizielle Befehlsreferenz (Commands reference) beschreibt /btw [Frage] als eine schnelle Nebenfrage, die der Konversation nicht hinzugefügt wird. Die Interaktive Modus-Dokumentation macht die Unterscheidung noch schärfer: /btw sieht die gesamte Konversation, hat aber keine Tools, während ein Subagent über Tools verfügt, aber mit einem leeren Kontext startet.

Das macht /btw perfekt für Fragen wie:

/btw was haben wir über die Migrationsreihenfolge entschieden?
/btw kommt dieser Fehler wahrscheinlich vom Test-Runner oder der Datenbank?
/btw fasse die riskanten Teile des bisherigen Diffs in einem Absatz zusammen

Nutzen Sie /btw, wenn Sie eine Antwort basierend auf dem benötigen, was Claude bereits weiß. Nutzen Sie es nicht, um eine Datei zu untersuchen, Logs zu prüfen, eine API aufzurufen oder eine Behauptung zu verifizieren. Das ist die Aufgabe eines Subagenten. Die saubere Regel ist einfach: Wenn die Nebenbemerkung den Plan nicht ändern sollte und keine Tools benötigt, verwenden Sie /btw. Wenn die Antwort die Implementierung beeinflussen könnte, holen Sie sie in den Haupt-Thread zurück oder weisen Sie einen Subagenten zu.

Das ist bei langen Sitzungen wichtig. Claude Code kann das letzte /btw-Overlay nun ohne eine neue Frage erneut öffnen, sodass der Nebenkanal zu einem leichtgewichtigen Notizbuch für flüchtige Gedankengänge wird. Es ist kein Ersatz für das Projektgedächtnis. Es ist eine Möglichkeit, Ihr Arbeitsprotokoll davor zu bewahren, zu einer Rumpelkammer zu verkommen.

/loop: Machen Sie das Warten explizit

Dieselbe Befehlsreferenz definiert /loop [Intervall] [Prompt] als einen Skill, der einen Prompt wiederholt ausführt, während die Sitzung offen bleibt. Das Intervall ist optional; Claude kann das Tempo selbst bestimmen. Der Prompt ist optional, wo autonome Wartung oder .claude/loop.md verfügbar ist. Der Alias lautet /proactive.

Nützliche Loops sind langweilig:

/loop 5m prüfe ob das Preview-Deploy abgeschlossen ist und melde dich nur, wenn sich der Status ändert
/loop 10m führe den instabilen Test erneut aus und stoppe nach einem fehlerfreien Durchlauf
/loop prüfe das Repo auf offensichtlich unfertige Arbeiten, bevor ich zurückkehre

Schlechte Loops sind vage:

/loop mache das Projekt besser
/loop optimiere das weiter

Ein Loop braucht eine Abbruchbedingung. Sonst haben Sie einen unermüdlichen Praktikanten ohne Definition of Done geschaffen. Die Version des "faulen Senior-Engineers" besteht darin, nach der kleinstmöglichen wiederholten Prüfung zu fragen, die Ihnen das eigene Polling (Abfragen) erspart. Einen Deploy überwachen. Einen einzelnen Test neu ausführen. Prüfen, ob eine lange Migration abgeschlossen ist. Machen Sie /loop nicht zu einem Produktmanager im Hintergrund.

Für produktive Agenten-Systeme ist dies dasselbe Muster, das wir in KI-Automatisierungsdiensten verwenden: Wiederholbare Prüfungen sind nützlich, wenn der Zustand beobachtbar (observable) und die Aktion eingeschränkt ist. Sie sind gefährlich, wenn das Ziel unscharf ist.

/effort: Passen Sie das Denken (Reasoning) an das Risiko an

Mit /effort [level|auto] können Sie den Aufwand des Modells festlegen. Die Dokumentation listet low, medium, high, xhigh, max und ultracode auf, wobei die Verfügbarkeit vom Modell abhängt. Dies kann über einen interaktiven Schieberegler geändert werden und wird sofort wirksam.

Nutzen Sie die Effort-Level wie Gänge beim Autofahren:

Belassen Sie nicht jede Aufgabe auf maximalem Aufwand. Das ist keine Gründlichkeit; es ist ein teurer Standard. Die bessere Angewohnheit ist es, den Aufwand nur zu erhöhen, wenn die Entscheidungsfläche größer wird. Wenn eine Aufgabe Geld, Authentifizierung, Datenverlust, Deployment oder mehrere Pakete betrifft, erhöhen Sie den Aufwand. Wenn die Aufgabe mechanisch ist und die Tests schnell sind, bleiben Sie niedriger und verifizieren Sie.

/dataviz: Diagramme brauchen Designregeln, nicht nur SVG

Die Befehlsdokumentation beschreibt /dataviz [Anfrage] als einen Skill für Diagramme, Graphen und Dashboards. Er wählt die Diagrammform, weist Farben nach Rolle zu, validiert Paletten auf Farbenblindheits-Sicherheit sowie Kontrast und wendet Markierungs-, Interaktions- und Barrierefreiheitsregeln an.

Das wichtigste Wort ist "Skill". /dataviz ist kein magischer Diagramm-Geschmack. Es ist eine verpackte Prozedur, die Claude hilft, bessere Entscheidungen über Diagrammtyp, Farbe und Barrierefreiheit zu treffen. Nutzen Sie es für Engineering-Berichte, Release-Dashboards, Regressionszusammenfassungen, Kostenkurven, Benchmark-Vergleiche und Vorfall-Zeitpläne (Incident Timelines).

Eine gute Anfrage sieht so aus:

/dataviz verwandle dieses Latenz-CSV in ein Vorher-/Nachher-Diagramm für ein Engineering-Review. Zeige p50, p95 und p99. Mache die Regression offensichtlich, ohne nur Rot/Grün zu verwenden.

Eine schlechte Anfrage ist "mache ein cooles Diagramm". Die nützliche Einschränkung ist die Entscheidung, die das Diagramm unterstützen soll. Wenn eine Visualisierung nicht ändert, was ein Leser versteht oder als Nächstes tut, erstellen Sie keine.

Agent Skills: Verlagern Sie wiederholbare Arbeit aus dem Chat

Die Skills-Dokumentation erklärt den Kernmechanismus: Ein Skill ist eine SKILL.md-Datei mit Anweisungen, die Claude laden kann, wenn sie relevant sind oder direkt aufgerufen werden. Im Gegensatz zum immer geladenen Gedächtnis (Memory) wird der Hauptteil eines Skills nur bei Verwendung geladen. Benutzerdefinierte Befehle und Skills sind praktisch verschmolzen: Eine Befehlsdatei und ein Skill können beide ein Slash-Befehl-Verhalten erzeugen.

Das ist ein großer Fortschritt für Teams. Es bedeutet, dass Sie aufhören können, dieselbe Checkliste in jede Sitzung einzufügen:

• "Wie wir Migrationen überprüfen" wird zu einem Migrations-Review-Skill.
• "Wie wir Release Notes vorbereiten" wird zu einem Release-Note-Skill.
• "Wie wir Zahlungs-Webhooks debuggen" wird zu einem Payments-Debug-Skill.
• "Wie wir visuelle Regressionsprüfungen durchführen" wird zu einem Verifizierungs-Skill.

Halten Sie Skills am Anfang kurz und packen Sie umfangreiche Beispiele, Vorlagen und Skripte in unterstützende Dateien. Die Dokumentation unterstützt explizit Vorlagen, Beispiele, Skripte und Referenzdokumentationen neben der SKILL.md. Das gibt Ihnen ein sauberes Muster: Der Skill entscheidet, was geladen wird, nicht Ihr System-Prompt.

Für eine tiefgreifendere Strategie dazu, lesen Sie unseren Artikel Context Engineering for AI Agents. Das Prinzip ist dasselbe: Kontext ist ein Budget. Geben Sie es nur aus, wenn es die nächste Aktion verändert.

Memory: CLAUDE.md ist keine Müllhalde

Die Memory-Dokumentation besagt, dass jede Claude-Code-Sitzung mit einem frischen Kontextfenster beginnt. Kontinuität entsteht durch zwei Mechanismen: CLAUDE.md-Dateien und Auto-Memory. CLAUDE.md enthält vom Benutzer geschriebene Anweisungen und Regeln auf Projekt-, Benutzer- oder Organisationsebene. Auto-Memory enthält von Claude geschriebene Erkenntnisse und Muster, die pro Repository gespeichert und über Worktrees hinweg geteilt werden, wobei die ersten 200 Zeilen oder 25 KB in jede Sitzung geladen werden.

Die praktische Gedächtnishierarchie sollte so aussehen:

1. Harte Regeln: Schreiben Sie diese in die CLAUDE.md oder in Hooks.
2. Wiederholbare Prozeduren: Packen Sie diese in Skills.
3. Entdeckte Präferenzen: Lassen Sie das Auto-Memory diese erfassen und kuratieren Sie sie dann, falls sie wichtig werden.
4. Temporäre Sitzungsfakten: Behalten Sie diese in der Konversation oder unter /btw, nicht im Memory.

Schreiben Sie keine Architektur-Touren ins Memory, wenn Claude das Repo inspizieren kann. Schreiben Sie jedoch Regeln, die aus dem Code nicht offensichtlich sind: "Führe das destruktive Reset-Skript niemals in Produktion aus", "Angebote nutzen Cent, nicht Euro", "LinkedIn-Posts müssen auf die Unternehmensseite gehen". Das sind die Details, die teure Fehler verhindern.

Multi-Agent-Code-Review: Zweite Verteidigungslinie, nicht die letzte Instanz

Die Code Review-Dokumentation beschreibt das Managed-Review-Feature als eine Research-Preview für Team- und Enterprise-Kunden. Es überprüft GitHub-Pull-Requests, postet Inline-Kommentare und verwendet eine Flotte spezialisierter Agenten, um den gesamten Codebasis-Kontext auf Logikfehler, Sicherheitslücken, fehlerhafte Edge-Cases und Regressionen zu untersuchen. Die Ergebnisse werden nach Schweregrad markiert und genehmigen oder blockieren den PR nicht. Bei anderen Plänen ist das lokale /code-review weiterhin im Terminal verfügbar.

Diese letzte Einschränkung ist gesund. Multi-Agent-Review sollte keine Ownership (Verantwortung) ersetzen. Es soll das abfangen, was Menschen übersehen, wenn der Diff groß ist, der Reviewer müde ist oder der Edge-Case in einer anderen Datei vergraben liegt.

Nutzen Sie es vor einem menschlichen Review, wenn:

• die Änderung Paketgrenzen überschreitet,
• der Branch Authentifizierung, Zahlungen, Berechtigungen oder Datenlöschung betrifft,
• der Diff generierten Code enthält,
• die Implementierung größtenteils von Agenten geschrieben wurde,
• der Reviewer eine Risikokarte (Risk Map) benötigt, bevor er jede Zeile liest.

Nutzen Sie es nicht als reinen Abnick-Prozess (Rubber Stamp). Ein Review-Agent kann Risiken aufdecken, aber Ihr Team trägt immer noch die Verantwortung für den Merge.

Ein praktisches Setup für ein Team

Wenn Sie Claude Code 2.0 in einem Team einführen, fangen Sie klein an:

1. Installieren und bestätigen Sie die Version mit claude --version.
2. Fügen Sie eine minimale CLAUDE.md mit ausschließlich nicht-offensichtlichen Regeln hinzu.
3. Erstellen Sie einen Skill für den am häufigsten wiederholten Workflow.
4. Schulen Sie die Entwickler darin, wann /btw anstelle eines Subagenten zu verwenden ist.
5. Definieren Sie Aufwands-Standards nach Risikokategorie.
6. Fügen Sie bei großen Branches /code-review vor dem menschlichen Review hinzu.
7. Verwenden Sie /loop nur für beobachtbare Prüfungen mit klaren Abbruchbedingungen.

Das reicht aus. Sie brauchen am ersten Tag keine vollständige Plattform. Der erste Gewinn ist ein sauberer Loop: Kontext sammeln, handeln, verifizieren und das Rauschen aus dem Haupt-Thread fernhalten.

Definition of Done für die Einführung von Claude Code 2.0

• CLAUDE.md existiert und enthält nur aktuelle, nicht-offensichtliche Projektregeln.
• Mindestens ein Team-Workflow wurde von einem eingefügten Prompt zu einem Skill verschoben.
• Entwickler kennen die Regel "/btw vs. Subagent".
• Aufwands-Level (Effort) sind für Aufgaben mit geringem Risiko, normalen Risiko und hohem Risiko dokumentiert.
• /code-review ist Teil der PR-Checkliste für riskante oder stark von Agenten beeinflusste Diffs.
• Ein Loop-Prompt enthält ein konkretes Intervall, eine beobachtbare Bedingung und eine Abbruchregel.
• Das Memory wird monatlich überprüft, damit veraltete Regeln nicht zu versteckten Altlasten (Debt) werden.

FAQ

Ist Claude Code 2.0 dasselbe wie Claude Code v2.1.227?

Nicht ganz. "Claude Code 2.0" bezeichnet die Produktgeneration, über die gesprochen wird; v2.1.227 ist das aktuell überprüfte Release für diesen Guide am 11. August 2026. Die Versionsnummer steigt häufig – manchmal täglich – mit Zuverlässigkeits-Fixes, neuen Slash-Befehlen und Anpassungen an Feature-Flags. Überprüfen Sie immer Ihre installierte Version mit claude --version und gleichen Sie dies mit dem offiziellen Changelog ab, bevor Sie sich auf ein bestimmtes Feature verlassen. Wenn Sie Dokumentationen oder Team-Guides schreiben, pinnen Sie die Version, gegen die Sie getestet haben, und notieren Sie das Prüfdatum.

Wann sollte ich /btw anstelle eines Subagenten verwenden?

Nutzen Sie /btw, wenn die Antwort vom aktuellen Konversationskontext abhängt und keine Tools benötigt. Wenn Sie beispielsweise eine kurze Zusammenfassung dessen wünschen, was bisher entschieden wurde, oder einen Sanity-Check machen wollen, ob ein Fehlermuster zu etwas bereits Diskutiertem passt, ist /btw die richtige Wahl. Nutzen Sie einen Subagenten, wenn Claude Dateien inspizieren, Befehle ausführen, Logs durchsuchen oder etwas erforschen muss, ohne den Hauptkontext zu füllen. Ein Subagent startet mit einem leeren Kontextfenster, hat aber vollen Tool-Zugriff, was ihn ideal für investigative Arbeiten macht, die Ihr Arbeitsprotokoll nicht verunreinigen sollen. Als Faustregel gilt: Wenn die Nebenbemerkung den Plan nicht ändern sollte und keine Tools benötigt, verwenden Sie /btw. Wenn die Antwort die Implementierung beeinflussen könnte, holen Sie sie in den Haupt-Thread zurück oder weisen Sie einen Subagenten zu.

Wofür eignet sich /loop am besten?

/loop eignet sich am besten für wiederholte, beobachtbare Prüfungen: Deploy-Status, instabile Tests (Flaky Tests), Abschluss einer Queue (Warteschlange), Cleanup-Scans oder regelmäßige Wartung. Der Schlüssel ist, dass jede Iteration eine klare Abbruchbedingung haben sollte – "stoppe nach einem fehlerfreien Durchlauf" oder "melde dich nur, wenn sich der Status ändert". Vermeiden Sie vage Loops wie "optimiere das weiter", da sie Arbeit ohne Ziellinie erzeugen und endlos Token verbrauchen. Ein gut konzipierter Loop ersetzt manuelles Polling: Anstatt selbst alle 5 Minuten einen Deploy zu überprüfen, delegieren Sie das an Claude und werden nur benachrichtigt, wenn sich etwas ändert. Für produktive Agenten-Systeme ist dies dasselbe Muster, das wir für automatisiertes Monitoring verwenden – wiederholbare Prüfungen sind nützlich, wenn der Zustand beobachtbar und die Aktion eingeschränkt ist.

Welches /effort-Level sollte ich verwenden?

Verwenden Sie einen niedrigeren Aufwand (Effort) für mechanische Änderungen mit günstiger Verifizierung – Umbenennungen, Formatierungen, einfache Test-Fixes. Erhöhen Sie den Aufwand für Architekturentscheidungen, das Debugging komplexer Probleme, Sicherheitsüberprüfungen, Datenmigrationen und alles, bei dem eine falsche Antwort teuer ist. Beim Effort-Slider geht es nicht um Qualität; es geht darum, die Tiefe des Denkprozesses (Reasoning) an das Risiko anzupassen. Eine Umbenennung auf max-Effort verschwendet Token, ohne das Ergebnis zu verbessern. Eine Datenmigration auf low-Effort spart Token, birgt aber das Risiko eines subtilen Datenverlusts. Der praktische Ansatz besteht darin, Team-Standards nach Aufgabenkategorie zu definieren: low für mechanische Änderungen, medium für normale Feature-Arbeit, high für das Debugging und xhigh/max für alles, was Authentifizierung, Zahlungen oder Datenintegrität betrifft. Überprüfen Sie Ihre Standards monatlich, da sich Modell und Tools weiterentwickeln.

Ersetzen Agent Skills die CLAUDE.md?

Nein. Die CLAUDE.md ist für persistente Anweisungen und Regeln gedacht, die für jede Sitzung gelten – Coding-Standards, Projektkonventionen, Sicherheitsregeln. Skills sind für wiederholbare Prozeduren, die nur bei Relevanz geladen werden sollten – eine Migrations-Checkliste, eine Release-Note-Vorlage, ein Debug-Workflow. Wenn eine Checkliste lang oder aufgabenspezifisch ist, gehört sie wahrscheinlich in einen Skill, nicht ins Memory. Die beiden Mechanismen ergänzen sich: CLAUDE.md legt die grundlegenden Regeln fest, und Skills bieten Schritt-für-Schritt-Prozeduren, die bei Bedarf aktiviert werden. Stellen Sie sich die CLAUDE.md als das Team-Handbuch (Handbook) und Skills als die Runbooks vor. Das Auto-Memory erfasst entdeckte Präferenzen und Muster, die bisher weder das Handbuch noch die Runbooks abdecken.

Kann ein Multi-Agent-Code-Review menschliche Reviews ersetzen?

Nein. Es ist eine zweite Verteidigungslinie, kein Ersatz für menschliches Urteilsvermögen. Das Claude-Code-Review kann Bugs, Sicherheitsprobleme, Edge-Cases und Regressionen aufdecken, die ein müder Reviewer bei einem großen Diff vielleicht übersieht. Aber das Team trägt immer noch die Verantwortung für die Entscheidung zum Merge. Das Multi-Agent-Review ist am wertvollsten vor einem menschlichen Review, wenn die Änderung Paketgrenzen überschreitet, Auth- oder Zahlungs-Themen berührt, generierten Code enthält oder größtenteils von Agenten geschrieben wurde. In diesen Fällen erstellen die Review-Agenten eine Risikokarte, die dem menschlichen Reviewer hilft, sich zuerst auf die Bereiche mit dem höchsten Risiko zu konzentrieren. Betrachten Sie es als Kraftmultiplikator (Force Multiplier) – es fängt das ab, was Menschen übersehen, aber es hat nicht den Kontext, um zu entscheiden, was für Ihr Produkt geschäftlich akzeptabel ist.

Quellen

• Claude Code Changelog — Versionsverlauf und Release Notes für die 2.1.x-Linie
• Claude Code Commands Reference — Offizielle Dokumentation für /btw, /loop, /effort, /dataviz und weitere Slash-Befehle
• Claude Code Interactive Mode — Subagenten- und /btw-Verhalten, Regeln zur Kontextisolierung
• Claude Code Skills — SKILL.md-Format, unterstützende Dateien und Skill-Aufrufe
• Claude Code Memory — CLAUDE.md-Hierarchie, Auto-Memory und Sitzungskontinuität
• Claude Code Code Review — Multi-Agent-PR-Review, Schweregrad-Markierung und das Managed-Review-Feature