Prompts regelmäßig ausführen mit Claude Code! Verwendung des /loop-Befehls und geplanter Aufgabe
Inhaltsverzeichnis
Nach dem Starten eines Deployments starrt man auf das Terminal und wartet auf den Abschluss. Man lädt den Browser immer wieder neu, bis die CI durchläuft. Die Konzentration bricht ab, weil man sich fragt, ob ein Review-Kommentar zur PR hinzugekommen ist ... Solche „kurz nachschauen, aber nicht wirklich die Arbeit unterbrechen"-Aufgaben während der Entwicklung sind auf eine stille Art stressig, oder?
Mit dem /loop-Befehl und der Funktion für geplante Aufgaben in Claude Code lassen sich solche Überprüfungen an Claude delegieren. Diese Funktion wurde am Wochenende auch in der Ankündigung von Boris Cherry vorgestellt. Basierend auf der offiziellen Dokumentation fasse ich hier die wichtigsten Punkte zusammen, die man für den praktischen Einsatz kennen sollte.
Erstmal ausprobieren
Die Verwendung ist denkbar einfach. Man schreibt nach /loop einfach das Intervall und den Prompt.
/loop 5m Überprüfe, ob das Deployment abgeschlossen ist, und teile mir das Ergebnis mit
Damit startet eine Aufgabe, die „alle 5 Minuten den Abschluss des Deployments überprüft und meldet". Claude registriert dies intern als Cron-Job und gibt die Job-ID sowie das Ausführungsintervall zurück.
Das Intervall kann am Anfang oder am Ende stehen, und wenn es weggelassen wird, beträgt der Standardwert 10 Minuten.
/loop 30m Überprüfe den Build-Status
/loop Überprüfe den Build-Status every 2 hours
/loop Überprüfe den Build-Status
Die Einheiten sind s (Sekunden), m (Minuten), h (Stunden), d (Tage). Da intern eine Cron-Ausdrucks-Konvertierung stattfindet, werden Sekunden auf die nächste Minute aufgerundet, und Werte wie 7m, die sich nicht glatt teilen lassen, werden auf ein nahes rundes Intervall gerundet. Claude teilt mit, auf wie viele Minuten das Intervall tatsächlich eingestellt wurde, sodass man sich um die Details keine Gedanken machen muss.
Wenn man bereits Workflows als Skills oder Befehle zusammengefasst hat, können diese auch in eine Schleife eingebunden werden.
/loop 20m /review-pr 1234
So ist es möglich, alle 20 Minuten ein PR-Review durchzuführen und bei jedem neuen Commit Feedback zu erhalten.
Auch „später erinnern" ist möglich
Für einmalige Erinnerungen statt Wiederholungen kann man /loop weglassen und die Anfrage einfach in natürlicher Sprache stellen.
Erinnere mich um 3 Uhr daran, den Release-Branch zu pushen
Überprüfe in 45 Minuten, ob die Integrationstests durchgelaufen sind
Claude konvertiert die Uhrzeit in einen Cron-Ausdruck, registriert sie als einmalige Aufgabe und löscht sie nach der Ausführung automatisch. Es ist praktisch, solche Aufgaben, die man während intensiver Entwicklungsarbeit leicht vergisst, schnell einzurichten.
Aufgaben überprüfen und abbrechen
Wenn man sich fragt „Welche Aufgaben laufen gerade?", kann man auch das in natürlicher Sprache fragen.
Zeige alle geplanten Aufgaben an
Brich den Deployment-Check-Job ab
Im Hintergrund laufen drei Tools: CronCreate (Registrierung), CronList (Auflistung) und CronDelete (Löschung). Jede Aufgabe erhält eine 8-stellige ID, und pro Sitzung können maximal 50 Aufgaben registriert werden. Im normalen Gebrauch wird man die 50er-Grenze jedoch kaum erreichen.
Eigenheiten, die man kennen sollte
Die Funktion ist praktisch, aber es kann Fälle geben, in denen sie nicht wie erwartet funktioniert. Wenn man die Funktionsweise ein wenig kennt, kann man ruhig reagieren, wenn etwas nicht stimmt.
Aufgaben laufen, „wenn Claude frei ist"
Geplante Aufgaben werden in den Pausen zwischen Benutzerinteraktionen ausgeführt. Sie unterbrechen Claude nicht, während eine Antwort generiert wird. Wenn der geplante Zeitpunkt während einer langen Verarbeitung kommt, wird die Aufgabe erst ausgeführt, nachdem diese abgeschlossen ist.
Das bedeutet: nicht „genau alle 5 Minuten", sondern eher „ungefähr alle 5 Minuten". Für Anwendungsfälle, die sekundengenaue Präzision erfordern, ist dies nicht geeignet.
Leichte Abweichungen beim Ausführungszeitpunkt
Um gleichzeitige API-Zugriffe zu vermeiden, wird dem Ausführungszeitpunkt automatisch ein kleiner Versatz (Jitter) hinzugefügt.
- Wiederkehrende Aufgaben: Verzögerung von maximal 10 % des Zyklus (maximal 15 Minuten)
- Einmalige Aufgaben: Bei Planung auf :00 oder :30 einer Stunde kann die Ausführung bis zu 90 Sekunden früher erfolgen
Bei einem stündlichen Job bedeutet das, dass die Ausführung irgendwo zwischen :00 und :06 stattfindet. Der Versatz wird aus der Aufgaben-ID berechnet, sodass er bei derselben Aufgabe jedes Mal gleich ist.
Wiederkehrende Aufgaben verfallen nach 3 Tagen automatisch
Damit vergessene Schleifen nicht endlos weiterlaufen, haben wiederkehrende Aufgaben eine Gültigkeitsdauer von 3 Tagen. Nach der letzten Ausführung werden sie automatisch gelöscht.
Wenn man eine Aufgabe länger als 3 Tage laufen lassen möchte, muss man sie vor Ablauf abbrechen und neu erstellen oder eine der weiter unten beschriebenen alternativen Methoden verwenden.
Benachrichtigungen nur innerhalb der Sitzung
Hier ist Vorsicht geboten. Erinnerungen und Aufgabenergebnisse werden nur als Nachrichten innerhalb der Claude Code-Sitzung angezeigt. Es erfolgt keine Benachrichtigung über externe Dienste wie Slack, E-Mail oder andere Messaging-Dienste.
Auch wenn man „Erinnere mich" sagt: Wenn man das Claude Code-Fenster nicht im Blick hat, wird man es nicht bemerken. Für externe Benachrichtigungen muss man selbst eine Lösung einrichten, z. B. durch Kombination von Shell-Befehlen oder API-Aufrufen im Prompt.
Grenzen der geplanten Aufgaben
Da es sich um einen sitzungsgebundenen Mechanismus handelt, gibt es strukturelle Einschränkungen.
- Verschwinden beim Sitzungsende -- Beim Neustart von Claude Code werden alle Aufgaben gelöscht. Dasselbe gilt beim Schließen des Terminals oder beim Beenden der Sitzung.
- Keine Nachholung verpasster Ausführungen -- Wenn der geplante Zeitpunkt einer Aufgabe verstrichen ist, während Claude lange beschäftigt war, wird sie einmalig ausgeführt, sobald Claude wieder frei ist. Alle verpassten Ausführungen werden nicht nachgeholt.
Das bedeutet: Der Anwendungsbereich sind „kleine Automatisierungen während der aktiven Arbeit mit Claude Code". Für Aufgaben, die unbeaufsichtigt weiterlaufen müssen, sind der schedule-Trigger von GitHub Actions oder Desktop scheduled tasks besser geeignet.
Umgekehrt bietet die Sitzungsbindung auch den Vorteil, dass man die Funktion „leichtfüßig ausprobieren" kann. Wenn die Konfiguration falsch ist, wird beim Beenden der Sitzung alles sauber bereinigt - ohne den Druck, den man beim direkten Bearbeiten von Cron hat, nämlich die Angst, etwas nicht gelöscht zu haben.
Deaktivierung per Umgebungsvariable möglich
Wenn man im Team arbeitet und Cron aus Sicherheitsgründen nicht erlauben möchte, kann man den gesamten Scheduler durch Setzen der Umgebungsvariable CLAUDE_CODE_DISABLE_CRON=1 deaktivieren.
Mögliche Einsatzszenarien
Basierend auf dem bisher Gesagten, hier einige Muster, die sich in der Entwicklung als nützlich erweisen könnten.
Health-Check nach dem Deployment
/loop 5m Überprüfe, ob das Deployment in der Staging-Umgebung korrekt ist, und melde Fehler
Nach dem Deployment kann man zu einer anderen Aufgabe wechseln und wird bei Problemen benachrichtigt.
Warten auf CI-Abschluss
Überprüfe in 30 Minuten, ob die CI-Pipeline durchgelaufen ist, und fasse das Ergebnis zusammen
Bei Projekten mit langer CI-Laufzeit ist es praktisch, einen einmaligen Check zum voraussichtlichen Abschlusszeitpunkt einzurichten.
Vergessen vor dem Release verhindern
Erinnere mich um 17 Uhr daran, das Changelog vor dem Release zu aktualisieren
Als Erinnerung für Routineaufgaben, die man bei konzentrierter Arbeit leicht überspringt.
Zusammenfassung
Die geplanten Aufgaben in Claude Code sind eine Funktion, die kleine Unannehmlichkeiten während der Entwicklung - wie „regelmäßig etwas überprüfen" oder „später daran erinnern" - unkompliziert beseitigt.
- Mit
/loopPrompts wiederholt planen - Einmalige Erinnerungen auch in natürlicher Sprache einstellbar
- Sitzungsgebunden, daher leicht zu verwenden und beim Beenden automatisch bereinigt
- Wiederkehrende Aufgaben verfallen nach 3 Tagen automatisch
- Benachrichtigungen nur innerhalb der Sitzung. Für externe Benachrichtigungen ist eine separate Lösung erforderlich
- Für dauerhaftes Scheduling GitHub Actions oder Desktop scheduled tasks verwenden
Für Details zur Cron-Ausdrucks-Syntax und den Spezifikationen der internen Tools ist die offizielle Dokumentation umfangreich - wer tiefer einsteigen möchte, sollte dort nachschauen.
Am besten fängt man mit etwas Leichtem an wie /loop 10m Überprüfe den Build-Status, um ein Gefühl für die Einfachheit dieser Funktion zu bekommen.
