Claude Code Plan Mode: Aktivierung und 4 Arbeitsphasen

Weitere Anweisungen findest du in der Ailoot-Dokumentation.

Was ist Plan Mode, und warum reicht er allein nicht aus?#

Im normalen Modus schreibt Claude Code sofort Code, und wenn du nicht aufpasst, bekommst du unvermittelt einen Diff über viele Dateien. Plan Mode kehrt die Reihenfolge um: erst Recherche und Planung, dann Freigabe, dann Änderungen.

Anthropic beschreibt Plan Mode in der offiziellen Dokumentation so:

Das klingt einfach, verbirgt aber den entscheidenden Wandel. Plan Mode verändert den Arbeitsrhythmus: erst abstimmen, dann handeln. Es ist ein Moduswechsel, keine kosmetische Anpassung. Für Vibe-Coder liegt das Problem darin, dass KI-Agenten dazu neigen, zu überstürzen. Wenn du im normalen Modus „Füge Google-Authentifizierung hinzu“ sagst, schreibt Claude in einer Minute den Code, aber die Hälfte der Dateien sind die falschen. In Plan Mode wird dieselbe Anfrage zu einem Textplan, den du in zwei Minuten lesen und korrigieren kannst, bevor irgendein Code angefasst wird.

Hier ist eine Falle, über die in internationalen Anleitungen niemand schreibt. Plan Mode allein ist ein schwaches Werkzeug: Der Plan existiert nur im aktuellen Gespräch. Schließt du das Fenster, ist der Plan verloren. Du kannst ihn keinem anderen Agenten übergeben. Es gibt weder Versionen noch Verlauf. Ist die Aufgabe groß (Refactoring eines 30-Dateien-Moduls, Migration auf eine neue Datenbank), stößt der Plan schnell an die Grenze des Kontextfensters und beginnt sich zu verschlechtern.

Deshalb funktioniert Plan Mode gut zusammen mit einem plans/-Ordner im Repository. Der Plan wird als plans/2026-05-21-google-oauth.md gespeichert, in Phasen mit Kontrollkästchen unterteilt und kann von jedem nächsten Agenten übernommen werden. So funktioniert Context Engineering: den Kontext vor dem Prompt verwalten, nicht währenddessen.

Wie aktivierst du Plan Mode in Claude Code?#

Am schnellsten geht es während einer Sitzung über die Tastatur:

Shift+Tab           # schaltet zwischen den Modi um: default → acceptEdits → plan

Nach zweimaligem Drücken erscheint unten im Terminal die Anzeige ⏸ plan mode on. Ein drittes Drücken kehrt zum normalen Modus zurück. Das ist die bequemste Methode: Du schaltest spontan um, sobald die Aufgabe größer wird.

Die zweite Methode ist, einem einzelnen Prompt ein Präfix voranzustellen:

/plan Schreibe einen Plan für die Migration der Datenbank von MySQL zu Postgres

Diese Option ist nützlich, wenn du im Auto-Accept-Modus bist und ihn nicht für die ganze Sitzung ändern möchtest. Eine Anfrage in Plan Mode, danach geht die Arbeit weiter wie zuvor.

Die dritte Methode ist beim Start der Sitzung:

claude --permission-mode plan

Verwende das, wenn du schon im Voraus weißt, dass eine Aufgabe Planung erfordert, etwa vor einem größeren Refactoring oder einer Migration.

Die vierte Methode ist, den Standardwert in .claude/settings.json im Projekt festzulegen:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Wann ist das nützlich? Wenn ein Team an einem komplexen System arbeitet, in dem jede Änderung angrenzende Module beeinflussen könnte. Dann schützt der standardmäßige Plan Mode alle vor versehentlichen Änderungen.

Ein fünfter, oft übersehener Trick: Mit Ctrl+G öffnest du den Plan in einem Texteditor. Nutze das, wenn der Plan fast stimmt, du aber 2-3 Punkte umformulieren oder eine Bedingung ergänzen musst. Bearbeite ihn manuell, speichere, und Claude arbeitet mit deiner Version weiter.

Was sind Anthropic's kanonische 4 Phasen in Plan Mode: Explore, Plan, Implement, Commit?#

Viele Anleitungen beschreiben 3 Phasen (Explore-Plan-Execute) oder nur 2 (Plan-Implement). Das sind Vereinfachungen. In seinem offiziellen Best-Practices-Leitfaden beschreibt Anthropic genau 4 Phasen. Der Unterschied ist wichtig: Eine separate Commit-Phase sorgt dafür, dass du das Ergebnis festhältst, statt es bei „Ich habe hier noch ein paar Änderungen gemacht, ich committe später“ zu belassen – der häufigste Grund für verlorene Arbeit.

Je präziser der Plan, desto weniger Iterationen braucht die Umsetzung. Wenn du 10 Minuten in den Plan investierst, reicht für die Umsetzung ein Prompt. Skizzierst du den Plan in einer Minute, kostet dich die Umsetzung eine Stunde an Korrekturen.

So sehen die 4 Phasen beim Hinzufügen von Google OAuth aus (ein Beispiel aus Anthropic Docs):

Auch die Prompts unterscheiden sich je Phase. In Explore: „Lies /src/auth und finde heraus, wie wir Sitzungen und Anmeldungen behandeln.“ In Plan: „Ich möchte Google OAuth hinzufügen. Welche Dateien müssen geändert werden? Erstelle einen Plan.“ In Implement: „Setze den OAuth-Ablauf aus deinem Plan um, schreibe Tests, führe die Testsuite aus und behebe Fehler.“ In Commit: „Erstelle einen Commit mit aussagekräftiger Nachricht und öffne einen PR.“

Eine wichtige Nuance: Plan Mode hindert Claude nicht daran, Recherchebefehle auszuführen. Read, LS, Glob, Grep, Web Fetch und Shell-Befehle zur Erkundung sind erlaubt. Nur Edit, Write und alle verändernden Dateisystemoperationen sind verboten. Das bedeutet, Claude kann die Projektstruktur lesen, git log ausführen und sich Tests ansehen – aber nichts versehentlich ändern.

Wie liest du Claudes Plan und entscheidest, ob du ihn freigibst?#

Wenn Claude einen Plan erstellt hat, zeigt es Optionen für das weitere Vorgehen an:

• Freigeben und im Auto-Modus starten
• Freigeben und Änderungen akzeptieren
• Freigeben und jede Änderung manuell prüfen
• Mit Feedback weiterplanen
• Mit Ultraplan verfeinern (Browserprüfung)

Zu wissen, ob man einen Plan freigeben sollte, ist die entscheidende Fähigkeit in Plan Mode. Man drückt leicht automatisch auf „Freigeben“ und muss dann Commits rückgängig machen. Der KI-Schmeichler will schnell antworten, und du willst schneller zum Code kommen. Ihr liegt beide falsch.

Ein guter Plan erfüllt 7 Kriterien:

1. Konkrete Dateinamen. Nicht „Ich aktualisiere Auth“, sondern „Ich ändere src/auth/login.ts:42-58, erstelle src/auth/oauth-callback.ts und aktualisiere src/auth/session.ts:103.“
2. Die Abfolge ist festgelegt. Der Plan ist in Phasen oder Schritte unterteilt, statt „Ich erledige das irgendwie alles“ zu sagen.
3. Externe Abhängigkeiten sind benannt. Erfordert die Aufgabe eine neue Bibliothek, wird sie aufgeführt. Werden Umgebungsvariablen benötigt, werden sie genannt.
4. Risiken sind aufgelistet. Ein guter Plan sagt: „Die Migration könnte bestehende Sitzungen beeinträchtigen; X muss geprüft werden.“ Ein schlechter schweigt zu Nebenwirkungen.
5. Es gibt Erfolgskriterien. „Die Tests in test/auth bestehen, der Linter ist sauber und der Dev-Server startet fehlerfrei.“
6. Es gibt keine aus der Luft gegriffenen Annahmen. Wenn Claude sagt „Ich verwende Bibliothek Z“, prüfe: Ist sie überhaupt im Projekt installiert? Hat sich die KI etwas ausgedacht, wirst du sehen, dass sie nicht in package.json erwähnt wird.
7. Der Plan passt auf den Bildschirm. Umfasst der Plan für ein einfaches Feature 200 Zeilen, ist die Aufgabe wahrscheinlich zu groß für einen einzigen Plan. Teile sie auf.

Wenn ein Plan die Prüfung nicht besteht, gibt es drei Möglichkeiten:

• Mit Feedback weiterplanen – Claude einen konkreten Kommentar dazu geben, was dir nicht gefällt; es überarbeitet den Plan.
• Ctrl+G – den Plan in einem Editor öffnen, manuell bearbeiten und speichern. Claude arbeitet mit deiner Version weiter.
• Mit Ultraplan verfeinern – der Plan wird in den Browsermodus von Claude Code im Web übertragen; dort prüfst du Abschnitte und kommentierst sie, dann führst du ihn lokal oder in der Cloud aus.

Wenn während der Umsetzung etwas schiefgeht, erzwinge nichts. Kehre zu Plan Mode zurück und schreibe den Plan neu. Das ist 10-mal günstiger, als später 40 Commits rückgängig zu machen.

Plan Mode + ein plans/-Ordner: eine Kombination für langen Kontext#

Plan Mode ist ein Modus von Claude Code. Der Ordner plans/ ist eine darauf aufbauende Methode. Wenn du Plan Mode ohne einen solchen Ordner verwendest, stößt du nach einer Stunde Arbeit an die Grenze.

Die Logik ist folgende: Claudes Kontextfenster ist das Gedächtnis der Sitzung. In Opus 4.7 passen 1 Million Tokens, aber das ist das Volumen des gesamten Gesprächs. Planst du eine komplexe Aufgabe in einem Gespräch, bittest dann um die Umsetzung, besprichst anschließend einen Fehler und danach etwas anderes, wird das Fenster „aufgebläht“. Claude beginnt, frühe Entscheidungen zu vergessen, Kontexte zu verwechseln und Fragen erneut zu stellen.

Die Lösung ist die goldene Regel: eine Aufgabe – ein Gespräch.

So gehst du vor:

1. Gespräch 1 – den Plan erstellen. Aktiviere Plan Mode, beschreibe die Aufgabe, und Claude erstellt einen Plan. Speichere ihn unter plans/2026-05-21-feature-name.md. Schließe das Fenster.
2. Gespräch 2 – in Phasen unterteilen. Öffne einen neuen Chat. Bitte: „Nimm plans/2026-05-21-feature-name.md und unterteile es in Phasen.“ Speichere die aktualisierte Datei.
3. Gespräch 3 – Phase 1 umsetzen. Öffne einen neuen Chat. Bitte: „Setze Phase 1 aus plans/2026-05-21-feature-name.md um und hake die Punkte ab, sobald du sie erledigt hast.“ Schließe das Fenster.
4. Gespräch 4 – Phase 2 umsetzen. Gehe genauso vor.

Was bringt dir das? Das Kontextfenster jedes Gesprächs bleibt frisch. Claude kennt in Phase 3 nicht die Details von Phase 1, aber den Plan, weil die Datei plans/ im Repository liegt. Jeder nächste Agent (ob Subagent, neue Sitzung oder ein Lauf über /goal) kann den Plan übernehmen und fortsetzen.

Vergleich der Ansätze:

Jedes Feature hat seine eigene Plan-Datei. Wenn du dich drei Monate später daran erinnern musst, warum du einen Zahlungsanbieter gegenüber einer Alternative gewählt hast, kannst du den entsprechenden Plan öffnen und den Entscheidungsverlauf nachlesen: was besprochen wurde, welche Optionen erwogen wurden und warum genau dieser Weg gewählt wurde.

Das sind lebendige Arbeitspläne; statische Dokumentation veraltet innerhalb weniger Monate.

Wie lässt sich Claude mit Plan Mode und /goal im Schlaf arbeiten lassen?#

Die größte Einschränkung langer KI-Sitzungen ist nicht das Modell selbst, sondern die Person, die Enter drückt. Jedes Mal, wenn Claude das Ende eines Zuges erreicht, wartet es auf deine Antwort. /goal beseitigt diese Wartezeit.

Die Syntax ist einfach:

/goal alle Tests in test/auth bestehen und lint ist sauber, oder nach 20 Zügen stoppen

Die Bedingung darf bis zu 4000 Zeichen lang sein. Pro Sitzung ist ein Ziel möglich. Nach jedem Zug sieht sich das Haiku-Minimodell das Transkript an und entscheidet: „Bedingung erfüllt – beenden“ oder „nicht erfüllt – nächster Zug“. Der Evaluator führt keine Tools aus, sondern liest nur.

Aliase zum Löschen des Ziels: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Die Kombination mit Plan Mode sieht so aus:

1. Aktiviere Plan Mode (drücke zweimal Shift+Tab).
2. Bitte: „Erstelle einen Plan für die Migration der Datenbank von MySQL zu Postgres und speichere ihn mit Phasen und Kriterien unter plans/2026-05-21-postgres-migration.md.“
3. Prüfe den Plan, bearbeite ihn und gib ihn frei.
4. Verlasse Plan Mode (drücke noch einmal Shift+Tab).
5. Setze ein Ziel: „Schließe alle Phasen in plans/2026-05-21-postgres-migration.md ab, hake die Kästchen ab, alle Tests bestehen, oder nach 50 Zügen stoppen.“
6. Schließe deinen Laptop und geh schlafen.

Prüfe morgens das Ergebnis: entweder „✓ Ziel erreicht“ oder „◎ nach 50 Zügen gestoppt“, zusammen mit einem Verlauf der erledigten Arbeit.

Für /goal gibt es drei wesentliche Regeln, sonst verschwendest du Tokens:

Regel 1: Ein messbarer Endzustand. „Sorge dafür, dass es gut aussieht“ ist schlecht. „npm test gibt 0 zurück, npm run lint gibt 0 zurück und ein Eintrag wurde zu CHANGELOG.md hinzugefügt“ ist gut.

Regel 2: Explizite Überprüfung. Die Bedingung sollte sich auf etwas Überprüfbares beziehen: einen Befehl, eine Datei oder einen Endpunkt. Nicht „Alles funktioniert“, sondern „curl localhost:3000/api/users gibt 200 zurück“.

Regel 3: Die Anzahl der Züge begrenzen. Füge immer „oder nach N Zügen stoppen“ hinzu. Anthropic empfiehlt ausdrücklich in der Dokumentation:

Wenn du /goal ohne „oder nach ... stoppen“ aktivierst, kann dein Budget über Nacht verschwinden.

Welcher 4-Schritte-Zyklus macht Plan Mode zu einem Entwicklungsprozess?#

Ein häufiger Fehler ist die Frage „Wie behebe ich das?“: Claude liefert eine Lösung, du setzt sie um, aber nichts funktioniert oder es wird schlimmer. Das ist der „KI-Schmeichler“: Er ist darauf trainiert, schnell zu antworten, und du willst schneller zum Code kommen. Ein 4-Schritte-Zyklus schafft hier Abhilfe.

Der 4-Schritte-Zyklus verhindert dieses Muster. Er wird nacheinander in einer einzigen Plan-Mode-Sitzung angewendet:

Schritt 1. Fakten ohne Lösung feststellen.

Prompt: „Ich erlebe Folgendes: [Symptombeschreibung]. Deine Aufgabe ist jetzt, die Fakten festzustellen. Lösungen, Ideen und Ratschläge sind verboten. Nur: Was beobachte ich, welche Schritte lassen sich reproduzieren, welche Daten sind verfügbar und welche fehlen? Harte Abbruchbedingung: Schlage KEINE Lösungen vor; halte nur die Diagnose fest.“

Damit wird der erste Impuls der KI unterbunden: „Hier ist die Lösung.“ Claude muss bei „Was ist bekannt und was ist unbekannt?“ stehen bleiben.

Schritt 2. Optionen mit Präzedenzfällen entwickeln.

Prompt: „Da die Diagnose nun feststeht, finde online Präzedenzfälle für die Lösung ähnlicher Probleme. Mindestens 3 verschiedene Ansätze. Für jeden: einen Link zur Primärquelle, eine kurze Beschreibung sowie Vor- und Nachteile für unsere Situation.“

Damit wird der zweite Impuls der KI unterbunden: „Denk dir spontan eine Lösung aus.“ Wir lassen sie hinaus in die Welt gehen und Ansätze zurückbringen, die sich überprüfen lassen.

Schritt 3. Detaillierter Plan mit Risiken.

Prompt: „Nimm die beste Option aus Schritt 2 und erstelle einen detaillierten Plan: Welche konkreten Dateien sind anzufassen, was ist hinzuzufügen, was zu entfernen, welche Tests sind zu schreiben, was könnte kaputtgehen und welche Risiken liegen 2-3 Schritte voraus?“

Das ist die bekannte Plan-Phase, aber mit einem Unterschied: Sie beruht auf den überprüften Optionen aus Schritt 2, nicht auf Claudes Vermutungen.

Schritt 4. Den Plan selbst prüfen.

Prompt: „Führe jetzt eine verpflichtende Selbstprüfung durch. Prüfe deinen Plan ehrlich noch einmal: Gibt es Stellen, an denen du dir etwas aus den Fingern gesogen und nicht anhand des Codes, der Dokumentation oder eines Präzedenzfalls aus Schritt 2 überprüft hast? Falls ja, markiere sie und überarbeite den Plan.“

Das ist der letzte Filter. Claude muss seine eigene Begründung prüfen und einräumen, wo es halluziniert hat. In diesem Schritt werden gewöhnlich mindestens 2 Planpunkte überarbeitet.

Nach den 4 Schritten kann der Plan freigegeben werden. Du gehst mit der Gewissheit in die Umsetzung, dass die Aufgabe verstanden, die Optionen abgewogen und die Risiken berücksichtigt wurden.

Diese Methode ist für die Diagnose schwieriger Fehler und für Architekturentscheidungen gedacht, bei denen ein Fehler teuer ist. Auf Plan Mode angewendet, beseitigt sie den größten Schmerz der Vibe-Coder: „Die KI gab mir eine Lösung, ich setzte sie um und alles ging kaputt.“

Welche 5 sofort einsetzbaren Prompts funktionieren bei häufigen Aufgaben in Plan Mode?#

Vorlage 1. Ein Modul refaktorisieren.

Ich aktiviere Plan Mode. Aufgabe: Refaktorisieren des Moduls {module-name}.

Schritt 1: Untersuche die aktuelle Struktur des Moduls {module-path}. Beschreibe:
- welche Dateien zum Modul gehören
- welche externen Abhängigkeiten es hat
- welche Teile doppelt vorhanden sind
- welche Funktionen überkompliziert sind

Schritt 2: Finde online 2-3 Beispiele für das Refactoring ähnlicher Module.
Mindestens 1 Quelle muss offizielle Anthropic- oder Framework-Dokumentation sein.

Schritt 3: Erstelle einen Refactoring-Plan in plans/YYYY-MM-DD-refactor-{module}.md:
- welche Dateien umzubenennen sind
- welche Funktionen in separate Module ausgelagert werden sollen
- welche Tests bleiben und welche neu geschrieben werden sollen
- Risiken: Was könnte für Nutzer kaputtgehen?

Schritt 4: Selbstprüfung. Gibt es im Plan Annahmen, die „aus der Luft gegriffen“ sind?
Überarbeite oder entferne sie.

Vorlage 2. Datenbankmigration.

Ich aktiviere Plan Mode. Aufgabe: Migriere die Datenbank von {old} nach {new}.

Schritt 1: Untersuche das aktuelle Datenbankschema mit {schema-reading-command}. Beschreibe:
- welche Tabellen es gibt und wie groß sie sind
- welche Beziehungen, Indizes und Einschränkungen bestehen
- wo Migrationen gespeichert sind
- welche Daten kritisch sind

Schritt 2: Finde Präzedenzfälle für Migrationen von {old → new} in Produktionsprojekten.
Mindestens 3 verschiedene Ansätze: pg_dump, dual-write, blue-green.
Liste für jeden die Vor- und Risiken für unsere Datenmenge auf.

Schritt 3: Erstelle einen Migrationsplan in plans/YYYY-MM-DD-db-migration.md:
- Phasen (Sicherung, Migration, Überprüfung, Umschaltung)
- Erfolgskriterien für jede Phase
- Rollback-Plan für den Fehlerfall
- mit oder ohne Ausfallzeit

Schritt 4: Selbstprüfung. Sind alle Angaben durch Dokumentation belegt?
Wurden alle Schritte gedanklich mit der Entwicklungsumgebung abgeglichen?

Vorlage 3. Ein neues Feature hinzufügen.

Ich aktiviere Plan Mode. Aufgabe: Füge dem Projekt das Feature {description} hinzu.

Schritt 1: Untersuche, wie ähnliche Features derzeit im Projekt funktionieren.
Sieh dir insbesondere Folgendes an:
- {file-1}
- {file-2}
- welche Architekturpatterns verwendet werden
- welche Tests für ähnliche Features geschrieben wurden

Schritt 2: Finde heraus, wie dieses Feature in Open-Source-Projekten
mit einer ähnlichen Architektur umgesetzt ist. Mindestens 2 verschiedene Ansätze.

Schritt 3: Erstelle einen Plan in plans/YYYY-MM-DD-feature-{name}.md:
- Liste neuer Dateien
- Liste geänderter Dateien mit konkreten Zeilen
- Reihenfolge der Umsetzung
- welche Tests hinzukommen sollen
- was als Regel für zukünftige Sitzungen in CLAUDE.md ergänzt werden soll

Schritt 4: Selbstprüfung. Entspricht der Plan der Architektur des Projekts?
Setzt er Bibliotheken voraus, die noch nicht installiert wurden?

Vorlage 4. Tests schreiben.

Ich aktiviere Plan Mode. Aufgabe: Decke das Modul {name} mit Tests ab.

Schritt 1: Untersuche das Modul {path}. Ermittle:
- öffentliche Funktionen und ihre Signaturen
- interne Funktionen, die wir NICHT testen (Implementierungsdetails)
- Grenzfälle: leere Eingabe, Fehler, gleichzeitiger Zugriff

Schritt 2: Finde Testbeispiele für eine ähnliche Aufgabenklasse
in beliebten Open-Source-Projekten mit demselben Framework.

Schritt 3: Erstelle einen Testplan in plans/YYYY-MM-DD-tests-{module}.md:
- für jede öffentliche Funktion eine Liste von Tests
- welche Mocks benötigt werden
- welche Fixtures
- welcher Prüfungsansatz verwendet wird (Assertion-Stil)

Schritt 4: Selbstprüfung. Prüfen alle Tests das Verhalten statt der Implementierung?
Deckt die Testabdeckung Grenzfälle ab?

Vorlage 5. Einen komplexen Fehler untersuchen.

Ich aktiviere Plan Mode. Aufgabe: Finde die Ursache des Fehlers {symptom-description} heraus.

Schritt 1: STELLE DIE FAKTEN FEST. Lösungen und Ideen sind verboten. Nur:
- was ich beobachte (genauer Wortlaut des Fehlers)
- reproduzierbare Schritte
- welche Daten verfügbar sind (Logs, Traces, Bibliotheksversionen)
- welche Daten fehlen (was zusätzlich erfasst werden muss)

Schritt 2: Finde Präzedenzfälle für diesen Fehler.
Mindestens 3 Quellen: GitHub-Issues, Dokumentation und weitere geeignete Quellen.
Gib zu jeder einen Link und eine kurze Zusammenfassung der Lösung an.

Schritt 3: Erstelle einen Diagnoseplan in plans/YYYY-MM-DD-bug-{name}.md:
- welche Hypothesen zu prüfen sind (nach Wahrscheinlichkeit sortiert)
- welche Befehle/Skripte auszuführen sind, um jede zu prüfen
- das erwartete Ergebnis jeder Prüfung

Schritt 4: Selbstprüfung. Gibt es im Plan Hypothesen, die „aus der Luft gegriffen“ sind?
Sind alle Hypothesen an Fakten aus Schritt 1 gebunden?

Kopiere jede Vorlage, ersetze {parameters} durch deine Angaben und füge sie in Claude Code in Plan Mode ein. Das Ergebnis ist ein Arbeitsplan in plans/, den du freigibst und zur Umsetzung verwendest.

Plan Mode oder normaler Modus: Welchen solltest du wählen?#

Anthropic sagt es direkt in der Dokumentation:

Verzichte nur bei einem kleinen, verstandenen Diff mit geringem Risiko auf einen eigenen Plan. Plane bei unklarem Ansatz oder koordinierten riskanten Komponentenänderungen. Bekannte Dateinamen oder eine knappe Zielbeschreibung beseitigen keine Risiken für Migration, Authentifizierung und Datenintegrität.

Entscheidungstabelle:

Prüfe vor der Moduswahl, ob Vorgehen, Nebenwirkungen und Verifikation verstanden sind. Arbeite direkt bei einer kleinen, örtlich begrenzten Änderung mit geringem Risiko und offensichtlicher Prüfung. Plane bei Unsicherheit, unbekanntem Code, Migration, Authentifizierung oder Komponentenabstimmung – auch wenn du alle 3–5 betroffenen Dateien bereits benennen kannst.

Wie kombinierst du Plan Mode + CLAUDE.md + Subagents für zuverlässige Arbeit?#

CLAUDE.md ist eine Datei, die Claude zu Beginn jeder Sitzung liest, auch in Plan Mode. Steht in CLAUDE.md „Datumsangaben niemals fest eintragen; immer aus der Datenbank beziehen“, wird der Plan niemals vorschlagen, ein Datum fest einzutragen. Fehlt eine solche Regel, kann der Plan alles Mögliche vorschlagen.

Die Kombination funktioniert so:

Ebene 1. CLAUDE.md legt die Regeln fest.

Die Datei nennt den Projekt-Stack, Architekturprinzipien, Verbote („keine veralteten APIs verwenden“) und Anforderungen („alle E-Mails laufen über ein gemeinsames Layout“). Ausführlicher Leitfaden: CLAUDE.md konfigurieren.

Ebene 2. Plan Mode wendet die Regeln auf die Aufgabe an.

Wenn du Plan Mode aktivierst und „OAuth hinzufügen“ sagst, liest Claude CLAUDE.md, sieht die Regeln („Tokens in Redis speichern, nicht in der Datenbank“) und berücksichtigt sie sofort im Plan. Der Plan entspricht der Projektarchitektur.

Ebene 3. Subagents teilen die Arbeit auf.

Ist der Plan in Phasen unterteilt, kann jede Phase einem eigenen Subagent zugewiesen werden. Jeder Subagent arbeitet in seinem eigenen Kontextfenster, ohne das Hauptfenster zu überladen. Der Plan in plans/ bleibt die zentrale Informationsquelle: Subagents lesen ihn, führen ihre Phase aus und aktualisieren die Kontrollkästchen.

Welche 7 Fehler bringen Plan Mode zum Scheitern?#

Fehler 1. Der Plan existiert nur im Chat.

Symptom: Du hast einen Plan geschrieben, das Fenster geschlossen und musst am nächsten Tag zurückkehren – aber nichts ist da; der Kontext ist weg. Lösung: Speichere den Plan immer im Repository unter plans/YYYY-MM-DD-feature-name.md. Der Chat ist ein Schreibtisch, die Datei ein Archiv.

Fehler 2. Alle Aufgaben sind in einem Chat.

Symptom: In einer Sitzung besprichst du erst Authentifizierung, dann eine Migration, dann UI-Design und danach einen Fehler. Das Kontextfenster wird „aufgebläht“ und Claude vergisst frühere Dinge. Lösung: eine Aufgabe – ein Gespräch. Plan fertig? Fenster schließen. Umsetzung beginnt? Ein neues öffnen.

Fehler 3. Ein 3000-Zeilen-Plan ohne Phasen.

Symptom: Es gibt einen Plan, aber keine Kontrollkästchen oder Unterteilungen. Es ist unmöglich zu erkennen, was erledigt ist und was nicht. Delegieren ist unmöglich. Lösung: Unterteile jeden Plan in 3-7 Phasen. Jede Phase besteht aus einer Liste von Kontrollkästchen mit konkreten Aktionen.

Fehler 4. Keine gründliche Recherche vor dem Plan.

Symptom: Claude schlägt spontan eine Lösung vor, weil du nicht darum gebeten hast, nach Präzedenzfällen zu suchen. Eine Woche später stellst du fest, dass es Open Source schon lange einen besseren Ansatz gibt. Lösung: Schritt 2 des 4-Schritte-Zyklus – Claude soll online 2-3 Präzedenzfälle finden, bevor es einen Plan erstellt.

Fehler 5. Der KI-Schmeichler bietet eine Lösung ohne Diagnose an.

Symptom: Du fragst „Wie behebe ich Fehler X?“, Claude schlägt eine Lösung vor, du setzt sie um, und nichts funktioniert oder es wird schlimmer. Lösung: Beginne immer mit „Stelle die Fakten fest; Lösungen sind verboten.“ Erst nach der Diagnose gehst du zu den Optionen über.

Fehler 6. Die Selbstprüfung auslassen.

Symptom: Der Plan klingt plausibel, enthält aber 2-3 aus der Luft gegriffene Annahmen (eine erfundene Bibliothek, eine nicht existierende API oder eine falsche Version). Bei der Umsetzung geht es an diesen Stellen schief. Lösung: Schritt 4 des 4-Schritte-Zyklus – Claude soll seinen Plan ehrlich erneut prüfen und Annahmen kennzeichnen.

Fehler 7. Vage Bedingungen in /goal.

Symptom: Du setzt /goal mach es schön fest, lässt es über Nacht laufen und stellst morgens fest, dass $200 deines Kontingents verbraucht sind. Lösung: Verwende nur messbare Bedingungen mit einem Prüfkommando und einem verpflichtenden „oder nach N Zügen stoppen“. Kein „mach es gut“ und kein „polier es auf“.

Der achte Fehler, den Vibe-Coder am häufigsten machen, besteht darin, das Konzept eines plans/-Ordners ganz zu ignorieren. Plan Mode ohne einen plans/-Ordner ist keine Methode, sondern ein Spielzeug. Wenn du Plan Mode nutzt, aber keine Dateien anlegst, erhältst du 10 % seiner Möglichkeiten.

Was solltest du nach deiner ersten Erfahrung mit Plan Mode als Nächstes tun?#

Drei konkrete Schritte, geordnet nach zunehmendem Schwierigkeitsgrad:

Schritt 1. CLAUDE.md konfigurieren, falls du noch keine hast.

Ohne CLAUDE.md arbeitet Plan Mode „im luftleeren Raum“ – Claude kennt die Projektregeln nicht und schlägt Pläne vor, die die Architektur beschädigen. Vollständiger Leitfaden: CLAUDE.md konfigurieren. Eine minimale CLAUDE.md umfasst 50-80 Zeilen und beschreibt den Stack, Regeln und Verbote. Die Länge ist zweitrangig. Entscheidend ist die Konkretheit.

Schritt 2. Einen plans/-Ordner im Repository erstellen.

Füge dem Projektstamm einen plans/-Ordner hinzu. Vereinbare ein Namensformat: YYYY-MM-DD-feature-name.md. Jeder Plan erhält eine eigene Datei. Nach einem Monat hast du 20-30 Dateien, nach sechs Monaten 100+. Das ist eine lebendige Entscheidungsgeschichte des Projekts.

Schritt 3. /goal für eine Aufgabe ausprobieren.

Wähle eine Aufgabe, die du normalerweise 30-40 Minuten lang von Hand erledigst. Aktiviere Plan Mode, erstelle einen Plan und speichere ihn unter plans/. Verlasse Plan Mode. Setze /goal alle Phasen in plans/file.md abschließen, alle Tests bestehen oder nach 30 Zügen stoppen. Schließe deinen Laptop für eine Stunde und mach etwas anderes. Komm zurück und prüfe das Ergebnis.

Diese drei Schritte sind das Minimum. Das baut sich allmählich auf; versuche nicht, alles an einem Abend zusammenzustellen. Beginne mit CLAUDE.md, füge nach einer Woche plans/ hinzu und probiere /goal nach einem Monat über Nacht aus.

Wenn du bereit bist, lerne Ailoot kennen.