Claude Code Plan Mode: wann reicht er im Team?

Der Plan Mode von Claude Code lässt Claude den Code erkunden und einen Plan vorschlagen, bevor es irgendetwas ändert. Sie geben den Plan frei, und erst dann beginnen die Änderungen. Für einen Entwickler in einer Session reicht das oft. Im Team nicht, denn der Plan lebt in einer Session auf einem Laptop, und niemand sonst kann ihn reviewen oder später prüfen.

Deshalb nutzen wir den Plan Mode für den Entwurf und halten den Plan dort, wo das Team arbeitet: im GitHub-Issue, mit Akzeptanzkriterien, die ein Reviewer mit Ja oder Nein beantworten kann. Bevor unser Agent etwas baut, prüft ein Read-only-Check die Prämisse des Issues gegen den Code.

Wie funktioniert der Plan Mode von Claude Code?

Der Plan Mode ist einer der Permission-Modi. Laut Dokumentation der Permission-Modi liest Claude Dateien, führt Shell-Befehle zum Erkunden aus und schreibt einen Plan, ändert Ihren Quellcode aber erst nach Ihrer Freigabe. Der Ablauf:

Die Freigabe schaltet die Session aus dem Plan Mode, und Claude beginnt zu ändern. Die Plandatei wird in ~/.claude/plans/ gespeichert, sofern Sie kein plansDirectory setzen.

Der Kostenleitfaden von Anthropic empfiehlt den Plan Mode für komplexe Aufgaben, weil eine falsche Richtung vor den Änderungen billiger ist als danach.

Wo reicht der Plan Mode im Team nicht?

Der Plan Mode beantwortet "versteht Claude gerade, was ich will". Ein Team braucht Antworten auf drei weitere Fragen:

• Wer hat den Plan noch gesehen? Er lebt in einer Session. Eine Kollegin, die die Arbeit morgen übernimmt, oder der Reviewer des Pull Requests sieht nie, was vereinbart war.
• Stimmte die Prämisse? Der Plan baut auf dem, was der Entwickler getippt hat. Steht im Issue "der Export verliert leere Zeilen" und der Code behandelt sie längst, behebt der Plan einen Fehler, den es nicht gibt.
• Woran erkennen wir, dass es fertig ist? Ein Plan listet Schritte. Ein Reviewer braucht Kriterien, idealerweise jedes mit einem Test belegt.

Das sind keine Rivalen. Der Plan Mode ist ein guter Weg, das Issue zu schreiben.

Wie planen wir stattdessen?

Jede Aufgabe ist ein GitHub-Issue mit einem Typ und einem geforderten Ergebnis:

Das Issue sagt, was zu liefern ist. Wer es übernimmt, ein Mensch oder unser KI-Agent, ergänzt ein fehlendes Ergebnis oder Akzeptanzkriterium als ausdrückliche Annahme, statt still zu raten.

Wie sieht der READY-Check aus?

Bevor unsere Agenten-Schleife etwas baut, läuft ein READY-Schritt. Das ist nicht der Plan Mode. Es ist ein eigener Read-only-Aufruf mit typisierter Antwort:

claude -p "$(cat ready.md; cat issue.md)" \
  --permission-mode default --permission-prompts none \
  --tools "Read,Grep,Glob,WebFetch" \
  --json-schema "$(cat ready.schema.json)" --output-format json --max-turns 40

Das Schema zwingt die Antwort in Felder: ready, done_when (Kriterien, die ein Reviewer mit Ja oder Nein beantworten kann), verify (wie jedes belegt wird), understood, premise und verifiable, das test oder human ist. Kommt kein gültiges Objekt zurück, zählt das als Fehler, nie als Standardwert.

Die Build-Session bekommt diese Kriterien dann als Auftrag. Sie läuft mit --disallowedTools AskUserQuestion ExitPlanMode: Zu diesem Zeitpunkt steht der Plan, der Agent kann also weder anhalten, um zu fragen, noch zurück ins Planen fallen. Die ganze Schleife, von READY bis zum Pull Request, steht in Harness Engineering in der Praxis.

Was findet ein Prämissen-Check, was der Plan Mode nicht findet?

Einen Plan, der in gutem Glauben auf einer falschen Prämisse gebaut ist. Der READY-Prompt verlangt vom Modell, jede Aussage des Issues über das aktuelle Verhalten gegen das Repository zu prüfen und file:line zu zitieren. Hält eine Aussage nicht, beginnt die Antwort mit REFUTED: und listet, was nicht mehr stimmt und was noch stimmt.

Was danach passiert, hängt davon ab, wie viel übrig bleibt:

• Nichts mehr zu tun. Das Issue geht mit den Belegen und dem Vorschlag, es zu schließen, an einen Menschen zurück.
• Ein Teil ist widerlegt. Die Schleife schlägt den korrigierten Umfang im Issue vor und wartet, bis ein Mensch mit OK antwortet, bevor gebaut wird.
• Nur ein Mensch kann es prüfen. Ist verifiable gleich human, sagt der Agent vor dem Start, was sich jemand ansehen muss.

Genau diese Lücke schließt ein Prämissen-Check. Planen ist billig. Das Falsche zu planen ist der teure Teil, und bis zum Review sieht es genau wie Fortschritt aus.

Wann reicht der Plan Mode?

Ziemlich oft. Damit entscheiden Sie, ob der Plan die Session verlassen muss:

Der Plan Mode passt zu kurzen, lokalen Änderungen, bei denen Sie der einzige Leser sind. Alles andere verdient einen Plan, den das Team lesen kann. Wie eine geschriebene Spezifikation zum Vertrag zwischen Menschen und Agenten wird, steht in Spec-Driven Development mit KI-Agenten.

Möchten Sie Pläne, die die Session überleben?

Wir richten Issue-Verträge, READY-Checks und die Agenten-Schleife direkt in den Repositorys eines Teams ein, im Rahmen von AI-native SDLC für Entwicklerteams. KI schreibt heute unseren gesamten Code, und ein Senior steht für das Ergebnis gerade. Seit 2023 haben wir 15+ Produktionsprojekte geliefert.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Wer in Ihrem Team fände den Plan von gestern heute wieder?

Häufige Fragen

Was ist der Plan Mode in Claude Code?

Ein Permission-Modus, in dem Claude Dateien liest und erkundende Befehle ausführt und dann einen Plan vorschlägt, ohne Ihren Quellcode zu ändern. Änderungen bleiben gesperrt, bis Sie den Plan freigeben.

Wie schaltet man den Plan Mode in Claude Code ein?

Mit Shift+Tab hindurchschalten, einen einzelnen Prompt mit /plan beginnen oder die Session mit claude --permission-mode plan starten.

Kann ich den Plan bearbeiten, bevor Claude loslegt?

Ja. Ctrl+G öffnet den vorgeschlagenen Plan in Ihrem Editor, oder Sie planen weiter und sagen Claude, was es ändern soll.

Wo speichert Claude Code Pläne?

Standardmäßig in ~/.claude/plans/ oder in dem Verzeichnis, das die Einstellung plansDirectory festlegt. So oder so liegt er auf einer Maschine, deshalb gehört ein Teamplan zusätzlich ins Issue.

Ist der Plan Mode dasselbe wie Spec-Driven Development?

Nein. Der Plan Mode ist eine Funktion einer Session. Spec-Driven Development hält den Plan als schriftliches Artefakt fest, das das ganze Team reviewt und die Checks prüfen können. Der Plan Mode kann den Entwurf dafür liefern.