Claude Code /simplify und /batch

Problem: Du hast ein Feature in Claude Code fertiggestellt. Die Tests laufen durch. Du weißt aber auch, dass sich ein paar Funktionen wiederholen, ein Helper neu erfunden wurde, und es mindestens eine Schleife gibt, die mehr Arbeit macht als nötig. Alles von Hand zu reparieren bedeutet, jede angefasste Datei neu zu lesen, die rauen Stellen selbst zu finden und sie eine nach der anderen zu patchen. So verschicken und der Tech-Debt frisst dich im nächsten Sprint. Keine der Optionen fühlt sich gut an.

Schnelle Lösung: Direkt nachdem ein Feature fertig ist, tipp /simplify. Es startet drei Review-Agenten auf einmal. Einer beobachtet Code-Wiederverwendung. Einer beobachtet Qualität. Einer beobachtet Effizienz. Sie bündeln ihre Notizen, wenden die Fixes an, und übergeben dir einen sauberen Diff. Kein Prompt zum Schreiben. Nur der Befehl.

# After implementing a feature
/simplify
 
# Focus on a specific concern
/simplify focus on memory efficiency

Neu bei Claude Code? Der Getting-Started-Guide deckt die Grundlagen ab. Hast du etwas Größeres vor, wie die Migration einer ganzen Codebasis von einem Framework zum anderen oder das Rollout einer Änderung über Dutzende von Dateien? Dafür ist /batch da. Beide Befehle kamen in Claude Code v2.1.63 raus, und zusammen decken sie zwei Workflows ab, die früher sorgfältiges mehrstufiges Prompten erforderten.

Was Claude Code /simplify macht

/simplify ist ein Post-Implementierungs-Cleanup-Befehl. Sobald der Code funktioniert, liest /simplify den Diff nochmal und macht ihn besser.

Der erste Schritt ist ein Aufruf von git diff (oder git diff HEAD), um zu sehen, was sich bewegt hat. Keine Git-Änderungen? Es greift auf die zuletzt geänderten Dateien zurück. Von da aus gehen drei Review-Agenten breit parallel los. Jeder sieht den vollständigen Diff:

Die drei laufen nebeneinander. Wenn sie fertig sind, fasst /simplify ihre Notizen zusammen, patcht jedes echte Problem direkt, und lässt alles, was wie ein False Positive aussieht, still fallen. Du bekommst eine kurze Zusammenfassung der Fixes, oder eine Bestätigung, dass der Code schon in Form war.

Boris Cherny, Claude Codes PM, hat es gut formuliert: Diese gebündelten Befehle "automate much of the work it used to take to shepherd a pull request to production." /simplify ist der automatisierte Review-Durchlauf zwischen "es funktioniert" und "es ist bereit zum Mergen."

Wann /simplify einsetzen

Der Sweet Spot ist direkt nach der Implementierung, bevor du einen PR öffnest:

• Nach einem Feature -- aufräumen vor dem Review
• Nach einem Bug-Fix -- sicherstellen, dass der Fix keine Abkürzungen eingeführt hat
• Nach einem Prototyp -- experimentellen Code straffen, den du behalten willst
• Vor einem PR -- Probleme finden, die ein Reviewer flaggen würde

Willst du den Fokus einengen? Du kannst optionalen Text übergeben:

/simplify focus on error handling
/simplify check for unnecessary dependencies
/simplify look at the database query patterns

Das ist praktisch, wenn du weißt, dass ein Bereich rau ist, aber keinen vollständigen Prompt schreiben willst, um die Codebasis zu beschreiben. Der Befehl weiß bereits, welche Dateien sich bewegt haben.

Was /simplify nicht ist

/simplify ist kein Linter. Auch kein Formatter. Es arbeitet auf einer höheren Ebene, schaut auf Architekturentscheidungen, Code-Struktur und Algorithmus-Auswahl. ESLint und Biome bleiben im Loop. /simplify kümmert sich um die Dinge, die diese Tools nicht erkennen können. Für validierungsartige Durchsetzung gibt es bereits Hooks.

Es ist auch kein pauschales Refactoring-Tool. Die Aufmerksamkeit bleibt auf dem, was sich zuletzt geändert hat, nicht auf dem gesamten Projekt. Für eine codebase-weite Änderung willst du /batch.

Was Claude Code /batch macht

Claude Codes /batch-Befehl koordiniert große Änderungen über dein Projekt hinweg, parallel. Die benutzerorientierte Oberfläche ist bewusst schlicht. Nichts als eine Beschreibung und ein paar Verwendungsbeispiele:

/batch migrate from react to vue
/batch replace all uses of lodash with native equivalents
/batch add type annotations to all untyped function parameters

Du sagst, was sich ändern muss. /batch übergibt es einem tieferen Orchestrierungs-Agenten, der die Recherche, die Zerlegung, die Ausführung und die PR-Erstellung übernimmt. Unter der Haube führt der Orchestrator eine dreiphasige Schleife durch.

Phase 1 -- Recherche und Plan. Der Orchestrator wechselt in den Planungsmodus. Er spawnt Explore-Agenten, um jede Datei, jedes Muster und jede Call-Site zu verfolgen, die die Anweisung berührt. Daraus bricht er die Arbeit in 5 bis 30 eigenständige Einheiten herunter, dimensioniert an der Codebasis und der Änderung. Jede Einheit muss eigenständig in einem Worktree implementierbar und eigenständig merge-bar sein, ohne auf eine andere Einheit warten zu müssen. Der Orchestrator arbeitet auch ein End-to-End-Verifizierungsrezept aus, ob das Browser-Automatisierung, ein CLI-Test oder deine bestehende Test-Suite ist. Wenn er nicht herausfinden kann, wie er die Arbeit verifizieren soll, hält er an und fragt dich.

Phase 2 -- Worker spawnen. Sobald du den Plan genehmigst, feuert der Orchestrator einen Hintergrundagenten pro Einheit ab. Alle gehen in einem einzigen Nachrichtenblock raus, sodass die Parallelisierung echt ist. Jeder Agent läuft mit isolation: "worktree" für einen sauberen Git-Worktree. Der Prompt jedes Agenten ist eigenständig: das Gesamtziel, die spezifische Aufgabe und die während der Recherche aufgegriffenen Codebasis-Konventionen. Er trägt auch das End-to-End-Test-Rezept und die Worker-Anweisungen. Nach dem Schreiben des Codes führt jeder Worker /simplify auf seinem eigenen Diff aus, lässt die Test-Suite laufen, committet, pusht und öffnet einen PR mit gh pr create.

Phase 3 -- Fortschritt verfolgen. Der Orchestrator rendert eine Status-Tabelle und aktualisiert sie ständig, wenn Agenten fertig werden, und zieht PR-URLs aus dem Output jedes Workers. Am Ende bekommst du eine Zusammenfassungszeile wie "22/24 units landed as PRs."

Worktree-Isolation ist das Stück, das das alles möglich macht. Jeder Agent hat seinen eigenen Branch und seine eigene Arbeitskopie, was bedeutet, dass kein Agent einen anderen stören kann. Merge-Konflikte tauchen nie auf. Jede Einheit bleibt unabhängig testbar und überprüfbar.

# Large-scale migration
/batch migrate src/ from Solid to React
 
# Pattern application
/batch add input validation to all API endpoints
 
# Convention enforcement
/batch rename all database columns from camelCase to snake_case
 
# Dependency update
/batch update all axios calls to use the new fetch wrapper

Der Plan-Schritt

Bevor eine einzige Datei geändert wird, legt /batch den Plan vor. Du siehst jede Arbeitseinheit, welche Dateien es anfassen plant, und was die Änderung beinhaltet. Nichts läuft, bis du es genehmigst.

Das macht /batch vorhersehbar. Du übergibst dein Projekt nicht einem autonomen Prozess und drückst die Daumen. Die Zerlegung ist sichtbar. Du prüfst, ob sie Sinn ergibt. Dann lässt du es los.

Wenn der Plan daneben liegt, vielleicht hat er einige Dateien übersehen oder Dinge schlecht gruppiert, sagst du ihm, es anzupassen, bevor die Ausführung startet. Das ist derselbe Geist wie Planungsmodi für einzelne Tasks, nur auf das gesamte Repo ausgedehnt.

Anforderungen

/batch braucht ein Git-Repository. Keine Ausnahmen. Jede Agent-Einheit läuft in ihrem eigenen Git-Worktree, und jede öffnet am Ende einen Pull Request. Außerhalb eines Git-Repos weigert sich /batch zu starten.

Die Worktree-Regel ist auch das, was deine Änderungen sicher hält. Die Arbeit jedes Agenten sitzt auf seinem eigenen Branch. Wenn eine Einheit schlecht läuft oder schlechten Code produziert, machen die anderen weiter. Gute PRs werden gemerged. Schlechte werden verworfen.

Wann /batch einsetzen

/batch ist für Arbeit gedacht, die sauber parallelisiert. Das heißt, Dutzende oder Hunderte von Dateien brauchen alle dieselbe Art von Bearbeitung, und keine einzelne Bearbeitung hängt von einer anderen ab.

Gute Kandidaten:

• Framework-Migrationen -- Komponenten von einem Framework zum anderen konvertieren
• API-Vertragsänderungen -- alle Aufrufer aktualisieren, wenn ein Interface sich ändert
• Konventionsdurchsetzung -- Namenskonventionen anwenden, Fehlerbehandlung hinzufügen oder Muster über die Codebasis standardisieren
• Abhängigkeits-Austausch -- eine Bibliothek durch eine andere an allen Verwendungsstellen ersetzen
• Test-Generierung -- Test-Coverage zu nicht getesteten Modulen hinzufügen

Schlechte Kandidaten:

• Eng gekoppelte Änderungen, bei denen Datei A von Datei Bs neuem Output abhängt (das sind keine unabhängigen Einheiten)
• Exploratives Refactoring, bei dem du den Endzustand noch nicht kennst
• Einzeldatei-Änderungen, die keine Zerlegung rechtfertigen

Wenn die Arbeit Agenten braucht, die miteinander koordinieren, sagen Agent A erstellt ein gemeinsames Utility und Agent B muss es importieren, ist /batch das falsche Tool. Reguläre Claude Code-Sessions oder Agenten-Teams übernehmen diese Art von Cross-Talk.

/simplify vs /batch: Wann welchen Befehl nutzen

Die beiden Befehle lösen verschiedene Probleme auf verschiedenen Skalen. Entscheidungsrahmen:

Ein nützliches mentales Bild: In Claude Code ist /simplify dein Code-Reviewer. /batch ist dein Migrations-Team.

Die beiden ergänzen sich auch by design. Jeder /batch-Worker führt /simplify auf seinen eigenen Änderungen aus, bevor er committet. Jeder PR, der aus /batch rauskommt, hat also bereits den Drei-Agenten-Durchlauf hinter sich. Kein manuelles Verketten. Die Integration ist bereits fest verdrahtet.

Praktische Workflow-Beispiele

Beispiel 1: Feature-Entwicklungszyklus

Du hast gerade einen neuen Authentifizierungsflow über 4 Dateien implementiert:

# 1. Implement the feature (normal Claude Code session)
"Add JWT authentication with refresh tokens to the API"
 
# 2. Clean up with /simplify
/simplify
 
# 3. Focus on specific concerns if needed
/simplify focus on security patterns in the auth flow

Die drei Review-Agenten durchkämmen den Auth-Code nach duplizierter Token-Validierungslogik, nach Qualitätsproblemen wie inkonsistenten Fehlerantworten, und nach Effizienzproblemen wie unnötigem Token-Dekodieren.

Beispiel 2: Framework-Migration

Dein Frontend hat 45 React-Klassen-Komponenten, die zu Funktionskomponenten mit Hooks werden müssen:

# 1. Describe the migration
/batch convert all React class components in src/components/ to functional components with hooks
 
# 2. Review the plan (batch shows 15 units of ~3 components each)
# 3. Approve
# 4. Each agent creates a PR with its batch of conversions
# 5. Review and merge PRs individually

Jeder PR steht für sich beim Review und Merge. Wenn eine Konvertierung knifflig wird und menschliche Aufmerksamkeit braucht, kommt dieser PR beiseite, während die anderen weiterlaufen.

Beispiel 3: API-Standardisierung

Deine API-Endpoints verwenden inkonsistente Fehlerantwort-Formate:

/batch standardize all API error responses to use { error: string, code: number, details?: object } format

/batch findet jeden Endpoint, bündelt sie in unabhängige Einheiten (meist nach Route-Datei oder Domain), und schickt jeden Agenten auf die ihm zugewiesenen Routen los. Jede Einheit lässt die bestehende Test-Suite nach den Änderungen laufen, sodass du schnell weißt, wenn etwas kaputt gegangen ist.

Gebündelte Befehle vs. Eigene Slash-Befehle

/simplify und /batch sind gebündelte Claude Code-Befehle. Sie kommen mit jeder Installation und funktionieren sofort. Eigene Slash-Befehle sind die andere Art: projektspezifische Prompts, die du selbst schreibst, entweder in deiner CLAUDE.md-Konfiguration oder unter .claude/commands/, ähnlich wie die Skills, die du für deinen eigenen Workflow definierst. Gebündelte Befehle werden von Anthropic gepflegt und erhalten Updates mit jedem Claude Code-Release.

Der Unterschied ist wichtig, weil gebündelte Befehle auf interne Fähigkeiten zugreifen können, die eigene Befehle nicht können. /batch kann Agenten in isolierten Worktrees spawnen und automatisch PRs öffnen. /simplify kann seine Drei-Agenten-Review-Pipeline starten, ohne dass du eine einzige Zeile Orchestrierungslogik schreiben musst.

Das heißt, die beiden Seiten ergänzen sich. Eigene Befehle gehören dem Projektspezifischen (dein Deploy-Prozess, deine Testing-Konventionen, deine Code-Generierungsmuster). Gebündelte Befehle gehören dem Universellen (Code-Review, codebasis-weite Änderungen), das auf jedes Projekt zutrifft.

Hast du eigene Sub-Agenten-Workflows gebaut, die einen Multi-Agenten-Review-Durchlauf von Hand aufbauen? /simplify könnte sie komplett ersetzen. Hast du Skripte geschrieben, um repetitive Änderungen über Dateien anzuwenden? /batch ist die Claude-native Version dieses Skripts.

Tipps für effektives /simplify und /batch

Führe /simplify vor jedem PR aus. Mach es zur Gewohnheit. Der Drei-Agenten-Durchlauf fängt Dinge auf, die du nach Stunden konzentrierter Implementierungsarbeit übersehen wirst. In der Praxis findet /simplify zuverlässig 3 bis 5 Probleme pro Feature-Branch, die sonst beim Code-Review auftauchen würden. Der Effizienz-Agent ist besonders stark darin, verschwendete Iterationen und verpasste Parallelisierungsmöglichkeiten zu finden.

Sei spezifisch mit /batch-Beschreibungen. "Update the codebase" ist zu vage. "Replace all moment.js imports with dayjs, updating the API calls to match dayjs's syntax" gibt dem Planer genug Kontext, um die Arbeit richtig zu zerlegen.

Überprüfe den /batch-Plan sorgfältig. Der Zerlegungsschritt ist, wo die meisten Probleme auftauchen. Wenn eine Einheit zu viele Dateien abdeckt oder unabhängige Änderungen vermischt, bitte um eine andere Aufteilung, bevor du genehmigst.

Nutze /simplifys optionalen Fokustext. Wenn du weißt, dass ein Bereich rau ist, vielleicht weil du beim Prototyping eine Abkürzung genommen hast, zeig /simplify direkt darauf. Ein gezielter Review bekommt bessere Ergebnisse als ein generischer Sweep.

Kombiniere /batch mit deiner Test-Suite. Jeder /batch-Agent lässt Tests nach dem Ändern laufen. Stell sicher, dass diese Tests wirklich Regressionen erkennen. Schwache Tests bedeuten, dass /batch-Agenten kaputten Code "bestehen" lassen.

FAQ

Ändert /simplify Dateien automatisch?

Ja. /simplify schreibt Fixes direkt in deine Arbeitskopie. Überprüfe sie mit git diff, bevor du committest. Falscher Fix? git checkout die Datei, um ihn rückgängig zu machen.

Was passiert, wenn ein /batch-Worker scheitert?

Ein gescheiterter Worker reißt die anderen nicht mit. Jeder läuft in seinem eigenen Git-Worktree, auf seinem eigenen Branch. Der Fehler taucht in der Status-Tabelle auf, und du retryest diese Einheit entweder oder übernimmst sie von Hand. PRs, die bereits gelandet sind, bleiben unberührt.

Welche Version von Claude Code liefert diese Befehle?

/simplify und /batch kamen in Claude Code v2.1.63 raus. Führe claude --version zum Prüfen aus. Bei einem älteren Build holt claude update sie rein.

Kann /batch mit Monorepos umgehen?

Ja. /batch funktioniert in jedem Git-Repository. Innerhalb eines Monorepos sei spezifisch, welche Pakete oder Verzeichnisse du in deiner Beschreibung targetest, damit der Planer die Arbeit korrekt zerlegt.

Wie unterscheidet sich /simplify von einem Linter?

Linter fangen Syntax- und Stilprobleme auf. /simplify fängt Architekturprobleme auf: duplizierte Logik, verpasste Abstraktionen, Performance-Ineffizienzen und Muster, die ein menschlicher Reviewer flaggen würde. Sie decken verschiedene Schichten ab.

Nächste Schritte

• Lies über Git-Worktrees in Claude Code, um das Isolationsmodell zu verstehen, das /batch verwendet
• Sieh, wie /simplify und /batch in das vollständige Interactive-Mode-Slash-Befehl-System passen, einschließlich Session-Steuerung, Tastaturkürzeln und /btw-Seitenf fragen
• Lerne, wie Agenten-Teams für koordinierte Multi-Agenten-Tasks funktionieren, die /batch nicht übernehmen kann
• Erkunde eigene Slash-Befehle, um projektspezifische Workflows neben diesen gebündelten aufzubauen
• Überprüfe Sub-Agenten-Best-Practices für das Entwerfen eigener Multi-Agenten-Muster
• Lies den Feedback-Loops-Guide für das Einbauen von Review-Zyklen in deinen Entwicklungsprozess
• Sieh dir das vollständige v2.1.63-Changelog für alles andere an, was mit diesen Befehlen mitgekommen ist
• Musst du Claude Code installieren oder updaten? Der Installationsguide deckt das Setup auf jeder Plattform ab, einschließlich der Ein-Zeilen-Installationsbefehle

/simplify und /batch zeigen, wohin Claude Code sich entwickelt: gebündelte Multi-Agenten-Workflows, die gängige Engineering-Muster out of the box übernehmen. Du reviewst noch jeden Diff. Du genehmigst noch jeden Plan. Aber die Orchestrierungsarbeit, das parallele Agenten-Spawning, das Worktree-Management, die Ergebnisaggregation, ist nicht mehr etwas, das du selbst verdrahten musst. Erwarte mehr gebündelte Befehle dieser Art, wenn die Plattform reift.

Du willst ein Development-Framework mit vorgefertigter Agenten-Orchestrierung, eigenen Slash-Befehlen und Multi-Agenten-Mustern, die neben diesen gebündelten Befehlen sitzen? Das ClaudeFast Code Kit kommt mit 18 spezialisierten Agenten und einer Pipeline, die genau für diesen Workflow entworfen wurde.