Claude Code /goal: Kann Claude jetzt autonom entwickeln?

Mit dem Befehl /goal gibst du Claude Code ein Ziel mit einer klaren Abschlussbedingung. Claude arbeitet dann Schritt für Schritt weiter, bis diese Bedingung erfüllt ist. Du musst nicht mehr zwischendurch freigeben oder „mach weiter“ schreiben.

Ich habe mit /goal eine komplette Web-App entwickeln lassen, inklusive Backend, Login und KI-Bildgenerierung. In diesem Artikel zeige ich dir, wie /goal im Hintergrund funktioniert, warum vage Ziele teuer werden, wie ich meine Zielvorgaben mit Spezifikationen aufbaue und auf welchen Haken ich gestoßen bin.

Was ist /goal in Claude Code?

/goal ist ein eingebauter Befehl in Claude Code. Du rufst ihn wie alle Slash Commands mit einem Schrägstrich auf und beschreibst danach dein Ziel als Bedingung.

Wichtig ist die Formulierung. Schreib nicht „Bau mir X“, sondern „X ist fertig, wenn folgende Bedingung erfüllt ist“. Sobald du den Befehl abschickst, legt Claude los, und in der Statuszeile siehst du, dass ein Goal aktiv ist.

Zwei Befehle helfen dir während eines Durchlaufs:

• /goal ohne weitere Angaben zeigt dir den aktuellen Stand: Laufzeit, Zielbedingung und verbrauchte Token.
• /goal clear bricht den Durchlauf ab.

Einen kurzen Überblick über /goal und andere Befehle, die ich täglich nutze, findest du in meinem Artikel über Claude Code Befehle.

So funktioniert /goal im Hintergrund: Worker und Evaluator

Hinter /goal arbeiten zwei Rollen zusammen.

Der Worker ist das Modell, mit dem du ohnehin arbeitest, etwa Sonnet oder Opus. Er schreibt Code, bearbeitet Dateien, führt Befehle aus und erledigt die eigentliche Arbeit.

Der Evaluator ist der Prüfer. Nach jedem Arbeitsschritt, einem sogenannten Turn, prüft er den Stand und entscheidet, ob das Ziel erreicht ist. Dafür nutzt Claude Code ein kleines, schnelles Modell, standardmäßig Haiku.

Der Evaluator kann selbst keine Dateien öffnen und keine Befehle ausführen. Er sieht nur, was der Worker im Verlauf sichtbar macht. Ist das Ziel nicht erreicht, gibt er dem Worker die Begründung zurück. Der Worker weiß dann, was noch fehlt, und startet den nächsten Durchlauf. Das geht so lange, bis der Evaluator das Ziel als erfüllt ansieht.

Daraus folgt eine wichtige Regel: Formuliere dein Ziel so, dass Claudes eigene Ausgabe es belegen kann. „Alle Tests laufen durch“ funktioniert, weil Claude die Tests ausführt und das Ergebnis im Verlauf steht.

Frisst /goal alle deine Token?

Die Sorge ist verständlich, aber meist unbegründet. Der Evaluator auf dem kleinen Modell kostet fast nichts. Die eigentlichen Kosten entstehen beim Worker, und die hättest du beim manuellen Prompting genauso.

Wenn du dasselbe Feature einmal mit /goal und einmal per Hand entwickelst, verbrauchst du mit /goal nur unwesentlich mehr Token. Vorausgesetzt, deine Zielvorgabe ist präzise. Was wirklich Token verbrennt, sind schlechte Zielvorgaben.

/goal und Auto Mode kombinieren

Für wirklich autonomes Arbeiten brauchst du eine zweite Funktion: Auto Mode. Die beiden sind unterschiedliche Dinge, ergänzen sich aber gut.

Normalerweise fragt Claude vor jeder Dateiänderung oder jedem Befehl, ob du zustimmst. Mit Auto Mode entscheidet Claude bei normalen Aktionen selbst. Ein Hintergrund-Klassifikator prüft dabei, ob die Aktion zu deinem Auftrag passt, und blockiert riskante Schritte.

Auto Mode heißt nicht, dass Claude unkontrollierbar wird. In der .claude/settings.json deines Projekts legst du fest, welche Aktionen erlaubt sind und welche nicht. Willst du, dass jede Session im Auto Mode startet, setzt du den Standardmodus so:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Zum Zeitpunkt meines Tests im Mai 2026 war Auto Mode nur in den Max-, Team- und Enterprise-Plänen verfügbar. Inzwischen ist er breiter verfügbar. Welche Optionen du hast, siehst du im Modus-Auswahlmenü von Claude Code.

Wie du dabei verhinderst, dass Claude an deine API-Keys kommt, zeige ich in meiner Anleitung zum Schutz deiner .env-Datei.

Gute Zielvorgaben für /goal formulieren

Nimm an, du startest mit diesem Ziel:

/goal Baue mir ein detailliertes Dashboard mit Kennzahlen für mein Projekt.

Der Worker baut ein Dashboard. Der Evaluator muss dann entscheiden: Was heißt eigentlich „detailliert“? Er trifft Annahmen und lenkt den Worker womöglich in die falsche Richtung. Das kostet zusätzliche Schleifen, nur weil das Ziel unklar war.

Anthropic nennt in der Dokumentation drei Dinge, die eine gute Zielvorgabe enthält:

1. Einen messbaren Endzustand: ein Testergebnis, eine Datei, die existieren soll, oder eine abgearbeitete Aufgabenliste.
2. Eine Prüfmethode: Wie soll Claude beweisen, dass er fertig ist?
3. Einschränkungen: Was darf sich auf dem Weg zum Ziel auf keinen Fall ändern?

Die Bedingung darf bis zu 4.000 Zeichen lang sein. Du hast also reichlich Platz.

Sicherheitsnetz gegen Endlosschleifen

Damit sich Claude nicht in einer Dauerschleife verfängt, hängst du eine Begrenzung an, zum Beispiel „oder stoppe nach 30 Turns“. Ist das Ziel bis dahin nicht erreicht, hört Claude spätestens dann auf.

Schlechtes und gutes Ziel im Vergleich

Schlecht:

/goal Baue das Dashboard fertig und mach es richtig gut.

Besser:

/goal Alle Punkte in der Aufgabenliste unter features/PROJ-3-Dashboard.md sind abgearbeitet und als erledigt markiert. Oder stoppe nach 30 Turns.

Im zweiten Fall gibt es eine Spezifikation in einer Markdown-Datei mit einer konkreten Aufgabenliste. Claude kann selbst nachvollziehen, wann alles erledigt ist, und der Evaluator kann es prüfen. Claude braucht also echte Akzeptanz- oder Testkriterien.

Spezifikationen als Zielvorgabe: Mein Vorgehen

Bei jedem Softwareprojekt, früher mit meiner Agentur und heute mit Claude Code, nehme ich zuerst Anforderungen auf und erstelle daraus Spezifikationen. Damit weiß der Agent genau, was eine Funktion leisten soll. Die Spezifikationen enthalten testbare Akzeptanzkriterien, und genau die sind die perfekten Zielvorgaben für /goal.

Aufbau einer Feature-Spezifikation

Eine Spezifikation besteht bei mir immer aus diesen Teilen:

„Out of Scope“ ist wichtiger, als es aussieht. Es verhindert, dass Claude Dinge baut, die niemand bestellt hat, und hilft allen, die später mit den Dokumenten arbeiten.

Praxistest: Ein Thumbnail-Generator mit /goal

Um /goal unter echten Bedingungen zu testen, habe ich einen Thumbnail-Generator für YouTube bauen lassen. Die Idee habe ich mir von Robin Illas abgeschaut, der ebenfalls über AI Coding auf YouTube berichtet.

Die App arbeitet in zwei Schritten. Zuerst lädst du Fotos von dir hoch. Dann lädst du bestehende YouTube-Thumbnails hoch, aus denen die App Vorlagen erzeugt, also eine Art Dummy mit Gesichtsausdruck und Bildelementen. Auf Basis dieser Vorlagen und deiner Fotos generiert die Bild-API von OpenAI neue Bilder im gewünschten Stil. Dieser Zwischenschritt liefert deutlich konsistentere Ergebnisse, als direkt dein Gesicht mit einem bestimmten Ausdruck generieren zu lassen.

Vorbereitung

Bevor es losging, habe ich drei Dinge vorbereitet:

• ein Projekt-Briefing als Datei mit allem, was Claude zum Start wissen muss,
• eine Verbindung zum Supabase MCP Server, damit Claude das Backend direkt mit einrichten kann,
• eine .env-Datei mit den API-Keys für Supabase und die OpenAI-Bildgenerierung.

Auto Mode hatte ich schon beim Start der Session aktiviert.

Schritt 1: Projekt initialisieren

Mein Workflow arbeitet mit Skills, also gespeicherten Arbeitsanweisungen für Claude. Der erste ist ein Init-Skill. Ich habe Claude gebeten, eine App zu entwickeln und das Briefing aus der Datei zu übernehmen. Ich diktiere solche Prompts übrigens meistens per Spracheingabe, das ist deutlich schneller als Tippen.

Der Skill füllt das PRD aus, mit Produktvision, Zielgruppe, ersten Features und Erfolgskriterien. Je nachdem, wie viel Kontext du mitgibst, stellt Claude Rückfragen, um eine gemeinsame Wissensbasis aufzubauen. Am Ende hatte Claude das Projekt initialisiert, committet und die Features vorgeschlagen: Supabase-Infrastruktur mit Datenbankschema und Row Level Security, Authentifizierung, Layout und die Thumbnail-Generierung.

Schritt 2: Spezifikationen schreiben

Mit dem nächsten Skill schreibt Claude gemeinsam mit mir die Spezifikation für jedes Feature. Er prüft zuerst, was schon existiert, und fragt nach, wenn etwas unklar ist. An dieser Stelle bin ich bewusst als Mensch in der Schleife: Claude bittet mich, jede Spezifikation zu prüfen und freizugeben.

Ein Beispiel aus der Spezifikation zur Authentifizierung:

Als neuer Nutzer möchte ich mich mit E-Mail und Passwort registrieren können, damit ich Zugang zur App bekomme.

Out of Scope waren hier Social Logins über GitHub oder Google, weil sie im Briefing nicht vorkamen. Darunter folgen die testbaren Akzeptanzkriterien und Edge Cases.

Am Ende hatte ich sechs Spezifikationen. Wer will, kann sie mit einem weiteren Skill noch einmal verfeinern lassen. Der hinterfragt bestehende Spezifikationen, ergänzt oder streicht Punkte und stellt dabei möglichst viele Rückfragen.

Zusätzlich pflegt Claude eine Übersichtsdatei mit allen Features und ihrem aktuellen Status. Daran orientiert er sich beim Projektstand.

Schritt 3: Den Workflow in der CLAUDE.md festlegen

Damit /goal nicht einfach drauflos baut, steht in der CLAUDE.md des Projekts ein fester Entwicklungsworkflow. Nach Init und Spezifikation folgen vier Phasen:

1. Architektur: Technisches Design vor der Umsetzung. Welche Komponenten, Seiten und Logik braucht das Feature?
2. Frontend
3. Backend
4. QA: Tests schreiben und ausführen, Akzeptanzkriterien prüfen.

Jede Spezifikation hat Platzhalter für diese Phasen, etwa für das technische Design, die QA-Ergebnisse und das Deployment. So bleibt die Spezifikation die eine verlässliche Quelle für das Feature. Jede Phase hat außerdem einen eigenen Status in der Feature-Übersicht. Vor dem Start standen alle Features auf „Planned“.

Schritt 4: /goal starten

Mit frischer Session habe ich dann das Ziel gesetzt:

/goal Alle Features haben den Status "Approved". Bitte durchlaufe den Arbeitsworkflow, der in der CLAUDE.md dokumentiert ist.

Ein Turn-Limit habe ich bewusst weggelassen, weil ich den Lauf beobachten wollte. Claude hat das Ziel bestätigt: alle sechs Features von „Planned“ auf „Approved“ bringen, für jedes in der Reihenfolge der Abhängigkeiten Architektur, Frontend, Backend und QA durchlaufen. Dann ging es mit dem ersten Feature los, inklusive Verbindung zum Supabase MCP.

Nach 16 Minuten hatte Claude zwei Features abgeschlossen. Nach 56 Minuten war er fertig und hatte alle Features umgesetzt.

Das Ergebnis

In den Spezifikationen hatte Claude alles dokumentiert: Decision Log, technische Entscheidungen, das komplette technische Design und die Testergebnisse. Nach der Implementierung hatte er Unit Tests geschrieben, alle Akzeptanzkriterien geprüft und festgehalten, wo noch nachgebessert werden muss.

Die App lief: Startseite, Registrierung und Login, Upload der eigenen Fotos, Anlage von Vorlagen aus YouTube-Thumbnails und Generierung neuer Thumbnails. Die Daten landeten in Supabase, die Bilder im Storage, die Einträge in den Tabellen.

Perfekt war es nicht. Ein Detail im eingeloggten Zustand musste nachgebessert werden. Und die Prompts an die Bild-API brauchten Iteration: Die erste Vorlage entsprach nicht meinen Erwartungen, und beim fertigen Thumbnail passten Ähnlichkeit, Kleidung und Gesichtsausdruck noch nicht. Das ist aber Feinschliff. Funktional stand nach knapp einer Stunde eine komplette Anwendung.

Der Haken: So autonom ist /goal nicht

So autonom, wie /goal wirkt, war es in meinem Test nicht. Dafür gab es zwei Gründe.

Problem 1: Der volle Kontext stoppt den Lauf

Wenn sich das Kontextfenster während der Arbeit füllt, verdichtet Claude Code den Verlauf normalerweise automatisch. Bei meinen Tests im Mai 2026 hat das im Goal-Modus nicht funktioniert. Der Lauf blieb stehen, und ich musste die Verdichtung mit /compact manuell auslösen.

Bei kleinen Aufgaben spielt das keine Rolle. Lässt du aber größere Funktionsblöcke entwickeln wie in meinem Beispiel, läuft das Kontextfenster nach etwa 45 Minuten voll. Danach musst du Claude außerdem sagen, dass er weitermachen soll. Dann arbeitet er im Goal-Modus weiter, bis das Ziel erreicht ist oder das Fenster wieder voll ist.

Wenn du damit leben kannst, alle 45 Minuten kurz einzugreifen, ist das in Ordnung. Laut aktueller Dokumentation verdichtet Claude Code den Kontext automatisch, bevor das Fenster voll ist. Ob das inzwischen auch im Goal-Modus zuverlässig greift, solltest du in deiner Version selbst testen.

Problem 2: Context Rot bei langen Sessions

Das größere Problem ist Context Rot. Je voller das Kontextfenster wird und je mehr Informationen Claude in einem Durchgang verarbeitet, desto stärker lässt die Leistung von Sprachmodellen nach. Die Modelle werden besser, und die Anbieter steuern dagegen, aber der Effekt ist nach wie vor messbar.

Beim manuellen Arbeiten starte ich deshalb regelmäßig neue Sessions, normalerweise eine pro Spezifikation, manchmal sogar eine pro Arbeitsschritt. So ist der Kontext frisch, und es liegen keine Randinformationen mehr im Speicher. Mein Eindruck ist, dass solche Reste Claude den Fokus kosten, weil er sie immer wieder zu berücksichtigen versucht.

Bei /goal läuft dagegen alles in einer langen Session. Wie groß der Qualitätsunterschied wirklich ist, lässt sich schwer beurteilen. Dafür müsste man dieselbe App einmal mit /goal über Stunden und einmal Phase für Phase mit frischen Sessions bauen und beide Codebases vergleichen. Das ist ein riesiger Aufwand.

Warum Spezifikationen den Schaden begrenzen

Was die Qualität trotz Context Rot absichert, sind die Spezifikationen. Claude gleicht den Code mit den Akzeptanzkriterien und den geschriebenen Tests ab. Das sichert eine gewisse Grundqualität.

Das funktioniert aber nur, wenn du diesen Rahmen vorgibst: Spezifikationen mit testbaren Kriterien, ein dokumentierter Workflow und die Bedingung, dass Claude seinen Code am Ende gegen die Kriterien prüft. Ohne diese Leitplanken wirst du merken, dass die Qualität deutlich schlechter ist.

Einordnung: /goal braucht ein System

/goal ist eine gute Möglichkeit, Claude Code weitgehend selbstständig Anwendungen entwickeln zu lassen. In meinem Test stand nach knapp einer Stunde eine funktionierende Web-App mit Backend, Login und KI-Bildgenerierung, ohne dass ich zwischendurch etwas freigeben musste.

Zwei Voraussetzungen gelten aber. Erstens muss die Zielvorgabe exakt beschrieben sein, sonst verbrennt Claude unnötig Token. Zweitens ist /goal nicht vollständig autonom: Bei langen Läufen musst du mit Eingriffen rechnen, und der wachsende Kontext kostet Qualität.

Mein Fazit: Nutze /goal nicht lose, sondern innerhalb eines Frameworks mit klaren Leitplanken. Spezifikationen mit testbaren Akzeptanzkriterien, ein fester Entwicklungsworkflow und eine Prüfung am Ende machen den Unterschied zwischen einer Demo und einer App, auf die du dich verlassen kannst. Gerade wenn du ein Produkt bauen willst, das wächst oder das du verkaufen möchtest, brauchst du genau diesen strukturierten Entwicklungsprozess.