Nicht bei jedem Schritt prompten. Gib Claude eine Ziellinie.

Es gibt eine ganz bestimmte Art von Müdigkeit, die entsteht, wenn du Claude Code gut nutzt. Du gibst ihm eine Aufgabe, es erledigt einen Teil, stoppt und gibt dir die Kontrolle zurück, du schaust dir das Ergebnis an, sagst «ja, weiter so» oder «nein, die Tests schlagen immer noch fehl, versuch’s nochmal». Dann macht es den nächsten Teil und stoppt wieder. Und wieder. Du machst die Arbeit nicht mehr selbst, aber du stehst immer noch daneben und stupst sie alle paar Minuten wieder an, wie an einer langsamen Selbstbedienungskasse.

Der Befehl /goal ist Anthropics Antwort genau darauf. Du legst die Ziellinie einmal fest. Claude arbeitet Runde für Runde selbstständig darauf hin und meldet sich erst wieder, wenn ein separates Modell bestätigt, dass die Linie überschritten ist. Du stellst es ein, dann gehst du Kaffee holen.

Ich bin gleich zu Beginn ehrlich, für wen das gedacht ist. /goal glänzt am meisten bei Arbeit mit einem klaren, prüfbaren Endzustand, und viel davon ist Entwicklerarbeit: Tests grün bekommen, den Build zum Laufen bringen, die Issue-Queue leeren. Betreust du als Nicht-Entwicklerin oder Nicht-Entwickler eine Website oder lässt Content über Claude Code laufen, gilt es trotzdem — du musst nur etwas genauer überlegen, was «fertig» für deine Art von Aufgabe überhaupt bedeutet. Dazu komme ich noch.

Was ein Goal eigentlich ist

Normalerweise läuft Claude Code Runde für Runde. Es arbeitet, stoppt, die Kontrolle geht an dich zurück, du promptest den nächsten Schritt. Dieses Hin und Her ist der Standardrhythmus.

Ein Goal ändert, was die nächste Runde auslöst. Statt dass du entscheidest, dass eine weitere Runde dran ist, entscheidet eine Abschlussbedingung. Du tippst /goal, gefolgt von einer Beschreibung in Alltagssprache, wie «fertig» aussieht, und von diesem Moment an startet Claude selbstständig neue Runden, bis die Bedingung erfüllt ist. Noch nicht erfüllt? Es startet die nächste Runde. Erfüllt? Das Goal wird abgeschlossen und du bekommst die Kontrolle zurück.

Das mentale Modell, zu dem ich immer wieder zurückkomme: Du beauftragst einen Maler, ein Zimmer zu streichen. Die Version Schritt für Schritt ist, dass du nach jeder Wand in der Tür stehst: «okay, nächste Wand». Die Goal-Version ist, dass du sagst «das Zimmer ist fertig, wenn jede Wand zwei Anstriche hat, kein Klebeband mehr an den Kanten klebt und die Abdeckplanen zusammengelegt sind» — und dann gehst du. Der Maler weiss genau, wann er fertig ist, und du auch, weil ihr euch auf die Ziellinie geeinigt habt, bevor jemand den Pinsel in die Hand genommen hat.

Diese Analogie zeigt auch, wo es schiefgeht — dazu kommen wir noch. Eine zu schwammige Ziellinie («mach das Zimmer schön») bedeutet, dass der Maler aufhört, wann immer er gerade will. Das im Hinterkopf behalten.

Wie es unter der Haube funktioniert

Was mich überrascht hat: Claude bewertet nicht seine eigenen Hausaufgaben. Es sind zwei Modelle im Spiel.

Das Hauptmodell — Sonnet, Opus, was auch immer du laufen lässt — macht die eigentliche Arbeit in jeder Runde. Jedes Mal, wenn es eine Runde beendet, geht die Bedingung, die du geschrieben hast, plus das gesamte bisherige Gespräch an ein zweites, kleineres, schnelleres Modell (standardmässig Haiku), das als Schiedsrichter fungiert. Der Schiedsrichter liest alles und liefert ein einfaches Ja oder Nein, mit einer Begründung in einem Satz. «Nein» sagt Claude, dass es weitermachen soll, und diese Begründung wird zum Hinweis für die nächste Runde. «Ja» schliesst das Goal ab und markiert es als erreicht.

Dass es zwei getrennte Modelle sind, ist wichtig. Dasjenige, das sich durch das Problem kämpft, ist oft der schlechteste Richter darüber, ob es wirklich fertig ist. Es ist involviert, starrt seit zehn Runden auf denselben Code, will fertig sein. Ein frischer Schiedsrichter, der die Arbeit nicht selbst gemacht hat, lässt sich schwerer täuschen. Es ist der Unterschied zwischen der eigenen Prüfung selbst korrigieren und sie von jemand anderem korrigieren lassen.

Eine Einschränkung bestimmt alles andere: Der Schiedsrichter sieht nur das Gespräch. Er kann deine Tests nicht ausführen, keine Dateien öffnen, keine Datenbank prüfen. Er urteilt einzig danach, was Claude im Chat sichtbar gemacht hat. «Alle Tests im Auth-Ordner sind grün» funktioniert also gut — aber nur, weil Claude diese Tests tatsächlich ausführt und die erfolgreiche Ausgabe im Transkript landet, wo der Schiedsrichter sie lesen kann. Taucht der Beweis nie im Gespräch auf, hat der Schiedsrichter nichts, worüber er entscheiden kann.

Noch ein mechanisches Detail, das sich zu wissen lohnt: Ein Goal zu setzen, startet sofort eine Runde, mit deiner Bedingung als Anweisung. Du tippst das Goal nicht ein und schickst dann einen separaten Prompt. Die Bedingung ist der Prompt. Während es läuft, siehst du eine kleine Anzeige ◎ /goal active, die zeigt, wie lange es schon läuft.

Wann sich der Einsatz lohnt

Greif zu einem Goal, wenn die Arbeit umfangreich, grösstenteils mechanisch ist und einen Endzustand hat, den du wirklich prüfen kannst. Die offiziellen Beispiele zeigen gut, wie das aussieht:

• Ein Modul auf eine neue API migrieren, bis jede Aufrufstelle kompiliert und die Tests bestehen
• Ein Design-Dokument umsetzen, bis alle Abnahmekriterien erfüllt sind
• Eine aufgeblähte Datei in kleinere Module aufteilen, bis jedes unter einem Grössenbudget liegt
• Einen Rückstand an gelabelten Issues abarbeiten, bis die Queue leer ist

Fällt dir auf, was die gemeinsam haben? Jedes ist eine Plage aus vielen ähnlichen Schritten, und bei jedem gibt es einen Moment, wo du auf etwas zeigen und sagen kannst: «da, das ist fertig» — eine grüne Testsuite, eine leere Queue, eine Datei unter 300 Zeilen. Diese Kombination, mühsam plus prüfbar, ist der Punkt, an dem sich ein Goal lohnt.

Für meine eigene Arbeit an dieser Website ist der Fall, bei dem es klick macht, der Content-Style-Durchgang. Ich gehe die Guides hier regelmässig durch und entferne die KI-Schreib-Tells — die steife Formulierung, die «nicht X, sondern Y»-Wendungen, die überstrapazierten Gedankenstriche. Das sind Dutzende fast identischer Änderungen über zwei Dutzend Dateien hinweg, mit einem prüfbaren Ende: Jeder Guide liest sich sauber gegen die Style-Checkliste. Das ist ein Goal. Etwa so: jeder Guide im Guides-Ordner wurde gegen protocols/content-style.md geprüft und seine Tells wurden behoben, ohne Links, Fakten oder Überschriften zu ändern — melde jede Datei, sobald du fertig bist. Mühsam, repetitiv, mit einer Ziellinie, die ich beschreiben kann. Genau die Aufgabe, die ich nicht Datei für Datei einzeln anstossen will.

Wann ergibt es keinen Sinn? Wenn die Arbeit kurz ist (dann frag einfach normal), wenn sie wirklich kreativ oder subjektiv ist (Text, der eine durchgehende menschliche Stimme braucht, hat keine Ziellinie, über die ein Schiedsrichter urteilen kann), oder wenn du «fertig» nicht so beschreiben kannst, dass es im Gespräch sichtbar wird. Kannst du den Satz «das ist fertig, wenn ______» nicht mit etwas Konkretem füllen, ist ein Goal das falsche Werkzeug.

Eine Bedingung schreiben, die wirklich funktioniert

Darum dreht sich alles. Ein Goal ist nur so gut wie seine Ziellinie, und die meisten Fehlschläge, die ich gesehen habe, kommen von einer lieblos formulierten Bedingung.

Eine Bedingung, die viele Runden übersteht, hat meist drei Teile:

Ein messbarer Endzustand. Ein Testergebnis, ein Build-Exit-Code, eine Dateianzahl, eine leere Queue. Etwas mit einem klaren Wert, kein Gefühl. «Der Code ist besser» hat keinen Endzustand. «Jede Datei im Components-Ordner ist unter 200 Zeilen» hat einen.

Eine festgelegte Prüfung, wie Claude es beweisen soll. Der Schiedsrichter liest nur das Transkript, das darfst du nicht vergessen. Sag Claude also, wie es Erfolg so zeigen soll, dass es im Chat landet: «führ die Testsuite aus und zeig, dass sie mit 0 endet», «führ git status aus und zeig, dass er sauber ist». Du benennst nicht nur das Goal, du benennst auch den Beweis.

Die Einschränkungen, die zählen, was sich nicht ändern darf. Das ist der Teil, den die Leute vergessen, und er ist der wichtigste. Nenn alles, was auf dem Weg zur Ziellinie unverändert bleiben muss: «keine andere Testdatei verändern», «die öffentliche API nicht anfassen», «nichts löschen, um die Prüfung zu bestehen».

Das Letzte ist keine Paranoia. Es ist die grösste Falle bei Goals, und die verdient einen eigenen Abschnitt.

Die Nachteile, ehrlich gesagt

Das Affenpfoten-Problem. (Die alte Gruselgeschichte, in der jeder Wunsch wortwörtlich erfüllt wird — mit einem hässlichen Haken.) Du hast gesagt «keine fehlschlagenden Tests». Für jemanden, der unter Druck steht, diese Bedingung wörtlich zu erfüllen, gibt es einen naheliegenden Trick: die fehlschlagenden Tests löschen. Jetzt gibt es keine fehlschlagenden Tests mehr. Bedingung erfüllt, der Schiedsrichter sagt Ja, das Goal wird abgeschlossen, und dein Code ist kaputter als vorher. Das ist ein echtes Fehlerbild, und es kommt direkt daher, dass Claude darauf optimiert, die Worte zu erfüllen, die du geschrieben hast, nicht die Absicht dahinter. Der Fix sind Leitplanken direkt in der Bedingung: «alle Tests bestehen, ohne einen Test zu entfernen oder zu überspringen». Denk beim Schreiben eines Goals immer kurz wie ein Paragrafenreiter, der versucht, es auf die billige Tour zu erfüllen, und schliess diese Tür.

Es kann ewig laufen. Lässt sich die Bedingung nie beweisen — weil sie vage ist, tatsächlich unmöglich, oder der Beweis nie im Chat auftaucht —, startet Claude endlos weitere Runden und verbrennt dabei die ganze Zeit Tokens. Die Verteidigung ist, es zu begrenzen: Füg direkt in der Bedingung eine Klausel hinzu wie «oder nach 20 Runden stoppen». Claude meldet in jeder Runde den Fortschritt gegenüber dieser Klausel, und der Schiedsrichter erklärt es für fertig, wenn das Limit erreicht ist.

Es kostet echte Tokens. Jede Runde ist eine volle Runde des Hauptmodells, das unbeaufsichtigt arbeitet. Ein Goal, das dreissig Runden läuft, sind dreissig Runden Verbrauch, und hast du einen Plan mit Wochenlimits, kann ein ambitioniertes Übernacht-Goal einen echten Teil deines Budgets auffressen. (Der Schiedsrichter selbst ist günstig — das kleine Haiku-Modell —, dieser Teil fällt also kaum ins Gewicht. Es sind die Runden des Hauptmodells, die sich summieren.)

Unbeaufsichtigt heisst unbeaufsichtigt. Damit ein Goal ohne dich läuft, muss Claude seine Aktionen auch ausführen können, ohne für jeden Tool-Aufruf nach Erlaubnis zu fragen. Dafür gibt’s den Auto-Modus, und die beiden ergänzen sich: Der Auto-Modus entfernt die Prompts pro Tool, /goal entfernt die Prompts pro Runde. Lässt du ein leistungsfähiges Modell mit beidem aktiviert und ohne Leitplanken auf dein Repository los, kannst du echten Schaden anrichten. Lass es auf einem Branch laufen, nicht auf main.

Der Schiedsrichter beurteilt eine Geschichte, nicht die Realität. Weil er nur das Gespräch sieht, kann ein selbstsicheres, aber falsches Claude im Prinzip einen Erfolg erzählen, der nie stattgefunden hat, und ein «Ja» bekommen. Zwei Modelle machen das viel schwerer als Selbstbeurteilung, aber wasserdicht ist es nicht. Die Abhilfe ist wie immer: Verlang in der Bedingung echte Beweise im Transkript, keine Zusammenfassung. «Tests bestehen», belegt mit echter Testausgabe, schlägt «Ich habe alles repariert».

So probierst du es aus, konkret

Du brauchst Claude Code v2.1.139 oder neuer, und du musst den Trust-Dialog für den Workspace akzeptiert haben (die Goal-Maschinerie baut auf dem Hooks-System auf, deshalb läuft sie nicht in einem nicht vertrauenswürdigen Ordner).

Fang klein an, auf einem Wegwerf-Branch, damit du die Schleife beobachten kannst, ohne etwas zu riskieren:

/goal jede Datei im Ordner src/utils ist unter 100 Zeilen,
erreicht durch das Aufteilen längerer Dateien in fokussierte
Dateien, ohne das Verhalten einer Funktion zu ändern — führ nach
jedem Split die Tests aus und zeig, dass sie weiterhin bestehen.
Nach 15 Runden stoppen.

Diese eine Bedingung hat alle Teile: einen messbaren Endzustand (Dateien unter 100 Zeilen), eine festgelegte Prüfung (Tests bestehen weiterhin, im Chat gezeigt), eine Einschränkung (Verhalten nicht ändern) und eine Begrenzung (nach 15 Runden stoppen). Sie zu setzen, startet sofort die erste Runde. Dann schaust du einfach zu. Nach jeder Runde siehst du die Ein-Satz-Begründung des Schiedsrichters, warum es noch nicht fertig ist — echt interessant, das ist eine Live-Anzeige davon, was Claude noch zu tun glaubt.

Ein paar Befehle, die du kennen solltest, während es läuft:

• /goal allein (ohne Text) zeigt den Status: die Bedingung, wie lange es schon läuft, wie viele Runden, verbrauchte Tokens und die letzte Begründung des Schiedsrichters.
• /goal clear stoppt es, bevor die Bedingung erfüllt ist. (stop, off, reset, cancel und none funktionieren auch, und eine neue Session mit /clear zu starten, löscht es ebenfalls.)
• Schliesst du die Session, während ein Goal noch aktiv ist, und nimmst sie später mit --resume oder --continue wieder auf, kommt das Goal zurück — Timer und Rundenzahl setzen sich aber zurück.

Es funktioniert auch im Headless-Modus, und genau da wird es für geplante Arbeit richtig nützlich. Das hier lässt die ganze Schleife in einem Rutsch aus deinem Terminal oder einem Skript laufen, bis sie fertig ist:

claude -p "/goal CHANGELOG.md hat einen Eintrag für jeden PR, der diese Woche gemerged wurde"

Ctrl+C stoppt ein Headless-Goal, falls du aussteigen musst.

Goal, Loop oder Hook?

Noch eine letzte Sache, weil sich das leicht verwechseln lässt. Claude Code hat drei Wege, eine Session zwischen deinen Prompts am Laufen zu halten, und sie lösen bei unterschiedlichen Dingen aus.

/goal startet die nächste Runde, wenn die vorherige fertig ist, und stoppt, wenn der Schiedsrichter deine Bedingung bestätigt. Nutz es, wenn du eine prüfbare Ziellinie hast.

/loop startet die nächste Runde, wenn ein Zeitintervall verstreicht — alle zehn Minuten, zum Beispiel —, und stoppt, wenn du es stoppst oder Claude entscheidet, dass die Arbeit erledigt ist. Nutz es für Arbeit im Stil «immer wieder ein Stück weiter / immer im Auge behalten», die vom Takt der Uhr bestimmt wird statt von einer Bedingung.

Ein Stop-Hook ist die Selbstbau-Version. Er lebt in deiner Settings-Datei, gilt für jede Session in seinem Geltungsbereich und führt dein eigenes Skript oder deinen eigenen Prompt aus, um zu entscheiden, wann es weitergeht. /goal ist eigentlich eine freundliche Verpackung genau davon — ein Stop-Hook, der nur auf die aktuelle Session begrenzt ist. Greif zu einem echten Stop-Hook, wenn dieselbe Prüfung automatisch für jede Session gelten soll, oder wenn du eigene Logik brauchst, die eine einzeilige Bedingung nicht ausdrücken kann.

Für die meisten Leute ist die Antwort meistens /goal. Gib Claude eine Ziellinie, mach sie gut, füg die Leitplanke hinzu, die das Schummeln verhindert, und lass es laufen.

---

Bist du neu bei Claude Code als Agent statt als Chatbot, fang mit Claude Code: Wenn KI aufhört zu reden und anfängt zu handeln an. Und sobald du dich sicher fühlst, ein Goal laufen zu lassen, ist der nächste Schritt, Claude die Arbeit über Subagents verteilen zu lassen, die je ein Stück parallel übernehmen.