Claude Code mit /goal und /loop: was die Befehle tun und wo die Risiken liegen

Normalerweise wartet Claude Code nach jeder Antwort auf Ihre nächste Eingabe. Mit /goal und /loop arbeitet es ohne diese Eingabe weiter. Die beiden Befehle unterscheiden sich darin, was den nächsten Schritt auslöst: Bei /goal ist es ein Ziel, das noch nicht erreicht ist, bei /loop die Uhr.

/goal: arbeiten, bis eine Bedingung erfüllt ist

Hinter /goal schreiben Sie eine Bedingung, zum Beispiel:

/goal alle Tests in test/auth laufen durch und der Lint-Schritt ist sauber

Claude beginnt sofort mit der Arbeit. Nach jeder Runde schickt Claude Code die Bedingung und das bisherige Gespräch an ein kleines, schnelles Modell. Dieses Modell urteilt: noch nicht erfüllt, erfüllt oder unmöglich. Ist die Bedingung noch nicht erfüllt, macht Claude mit der nächsten Runde weiter und nimmt die Begründung des Prüfers als Hinweis mit. Bei „erfüllt“ oder „unmöglich“ endet das Ziel.

Die Bedingung darf bis zu 4.000 Zeichen lang sein, und pro Sitzung ist ein Ziel aktiv. /goal ohne Zusatz zeigt den Stand, darunter die Zahl der Runden und die bisher verbrauchten Tokens. /goal clear bricht das Ziel ab.

/loop: eine Aufgabe in festen Abständen wiederholen

/loop führt einen Prompt immer wieder aus, solange die Sitzung offen ist:

/loop 5m prüfe, ob das Deployment durch ist, und sag mir, was passiert ist

Das Intervall geben Sie in Sekunden, Minuten, Stunden oder Tagen an, das kürzeste Intervall ist eine Minute. Lassen Sie das Intervall weg, wählt Claude nach jedem Durchlauf selbst eine Pause zwischen einer Minute und einer Stunde. Lassen Sie auch den Prompt weg, arbeitet Claude einen eingebauten Wartungsauftrag ab: angefangene Arbeit fortsetzen, sich um den Pull Request des aktuellen Branches kümmern und, wenn sonst nichts ansteht, nach Fehlern suchen oder Code vereinfachen. Mit einer Datei loop.md ersetzen Sie diesen Auftrag durch einen eigenen.

Ein Durchlauf startet immer zwischen zwei Antworten, nie mitten in einer.

Die Risiken bei /goal

Der Prüfer kennt nur das Gespräch. Er liest keine Dateien und führt keine Befehle aus. Er urteilt nur über das, was Claude im Gespräch gezeigt hat. Eine Bedingung wie „der Code ist sauber“ kann er deshalb gar nicht prüfen, und ob eine Erfolgsmeldung stimmt, sieht er nur, wenn der Beleg im Gespräch steht. Schreiben Sie die Bedingung so, dass Claude diesen Beleg liefern muss, zum Beispiel „npm test endet mit Exit-Code 0“.

Ein Ziel lässt sich auch auf dem falschen Weg erreichen. „Alle Tests laufen durch“ ist auch dann erfüllt, wenn ein Test abgeschwächt oder gelöscht wurde. Schreiben Sie deshalb in die Bedingung, was sich auf dem Weg nicht ändern darf, etwa „keine Testdatei wird verändert“.

Die Laufzeit ist offen. Ein Ziel läuft, bis der Prüfer es für erfüllt oder unmöglich hält oder Sie es abbrechen, und jede Runde kostet Tokens. Sie können eine Grenze wie „oder hör nach 20 Runden auf“ in die Bedingung schreiben. Auch diese Grenze beurteilt der Prüfer nur anhand des Gesprächs, einen festen Zähler gibt es dafür nicht.

Die Rechte bleiben, wie sie sind. /goal ändert nichts an den Berechtigungen. Im normalen Modus fragt Claude vor jedem Befehl, den Sie nicht freigegeben haben, und wartet auf Ihre Antwort. Damit Claude wirklich unbeaufsichtigt weiterarbeitet, braucht es den Auto-Modus oder großzügige Freigaben. Was dann erlaubt ist, passiert über viele Runden, ohne dass jemand zusieht. Lassen Sie ein Ziel deshalb auf einem eigenen Branch laufen und sehen Sie sich das Ergebnis an, bevor Sie damit weiterarbeiten.

Die Risiken bei /loop

Jeder Durchlauf kostet, auch wenn nichts zu tun ist. Ein Loop im Fünf-Minuten-Takt startet in einer Stunde zwölf Durchläufe, an einem Arbeitstag von acht Stunden rund hundert, und jeder verbraucht Tokens. Wählen Sie das Intervall nach dem, was Sie beobachten: Ein Build, der zehn Minuten dauert, braucht keine Prüfung im Minutentakt.

Alle Durchläufe landen im selben Gespräch. Läuft ein Loop lange, wird das Gespräch irgendwann zu groß und automatisch zusammengefasst. Was in frühen Durchläufen passiert ist, steht danach nur noch verkürzt da.

Ein Loop hat die Rechte der Sitzung. Was Sie in der Sitzung freigegeben haben, darf auch jeder Durchlauf. Ist Pushen freigegeben, pusht ein Loop, der fehlgeschlagene Builds reparieren soll, seinen Fix ohne Rückfrage, auch wenn gerade niemand hinsieht. Beim eingebauten Wartungsauftrag pusht oder löscht Claude nur, wenn es damit etwas fortsetzt, das im Gespräch schon erlaubt wurde. Ob das zutrifft, beurteilt allerdings das Modell selbst.

Als Zeitplan ist ein Loop unzuverlässig. Er läuft nur, solange Claude Code offen ist und gerade nichts anderes tut. Verpasste Durchläufe holt er nicht nach, und wiederkehrende Durchläufe starten je nach Intervall bis zu 30 Minuten später als geplant, damit nicht alle Sitzungen gleichzeitig loslegen. Nach sieben Tagen läuft ein wiederkehrender Loop von selbst ab. Was zuverlässig zu einer festen Zeit laufen muss, gehört in eine geplante Aufgabe in der Cloud oder der Desktop-App oder in einen CI-Job.

Beide Befehle lassen Claude arbeiten, ohne dass jemand jeden Schritt bestätigt. Bevor Sie einen davon starten, sollten Sie wissen, was Claude in dieser Zeit tun darf.

Fragen dazu oder zu KI in Ihren eigenen Abläufen? Schreiben Sie uns gerne.