Claude Code Routines

Problem: Dein Laptop muss offen bleiben, damit Claude Code irgendetwas tut. Desktop-Scheduled-Tasks und /loop laufen lokal, das heißt ein geschlossener Deckel killt jede Automatisierung, die du aufgesetzt hast. Du hast auch keine Möglichkeit, auf externe Events wie einen GitHub-PR oder einen Monitoring-Alert zu reagieren, ohne zu pollen.

Quick Win: Erstelle deine erste Cloud-Routine aus der CLI und teste sie on-demand:

/schedule daily PR review at 9am

/schedule run

Der erste Befehl erstellt eine Routine, die jeden Morgen dein Repo in Anthropics Cloud clont und den Prompt ausführt. Der zweite feuert sie sofort, damit du die Ausgabe verifizieren kannst, bevor du dem Zeitplan vertraust.

Was Routines sind

Eine Routine ist drei Dinge zusammengepackt: ein Prompt, ein oder mehrere GitHub-Repositories und eine Reihe von Connectors (MCP-Server wie Slack, Linear oder Datadog). Du konfigurierst sie einmal. Anthropics Cloud führt sie aus, wann immer ein Trigger feuert.

Jeder Run clont eine frische Kopie deines Repos, startet eine vollständige Claude Code-Session und führt autonom aus. Keine Permission-Prompts. Keine Approval-Klicks. Die Session kann Shell-Befehle ausführen, alle ins Repo committeten Skills nutzen und jeden angehängten Connector aufrufen.

Routines wurden am 14. April 2026 als Research-Preview veröffentlicht. Verhalten und API-Oberfläche können sich vor GA ändern.

Wo Routines leben

Drei Oberflächen erstellen und verwalten Routines. Alle schreiben in denselben Cloud-Account.

Web-UI unter claude.ai/code/routines. Volle Kontrolle über jede Einstellung: Prompt, Modell, Repos, Umgebung, Trigger und Connectors.

CLI mit /schedule. Erstellt nur Scheduled-Routines. Unterbefehle:

Desktop-App über Schedule > New task > New remote task. "New local task" wählen erstellt stattdessen eine Desktop-Scheduled-Task, die auf deinem Rechner läuft.

API-Trigger und GitHub-Trigger können nur über die Web-UI konfiguriert werden. Die CLI unterstützt sie noch nicht.

Drei Trigger-Typen

Eine einzelne Routine kann alle drei kombinieren. Eine PR-Review-Routine könnte nächtlich nach Zeitplan laufen, sofort reagieren wenn ein PR geöffnet wird und Ad-hoc-Aufrufe von einem Deploy-Skript akzeptieren.

Schedule-Trigger feuern nach einem Rhythmus. Presets umfassen stündlich, täglich, werktags und wöchentlich. Custom-Cron-Ausdrücke funktionieren auch (mit /schedule update setzen). Mindestintervall ist eine Stunde. Zeiten nutzen deine lokale Zeitzone.

API-Trigger geben jeder Routine einen dedizierten HTTP-Endpunkt. POST ihn aus jedem System. Das optionale text-Feld im Request-Body wird als zusätzlicher Kontext an den Prompt der Routine angehängt:

curl -X POST \
  https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

Die Antwort liefert eine Session-ID und eine URL zurück. Klick die URL an, um Claude in Echtzeit bei der Arbeit zuzuschauen:

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

GitHub-Trigger abonnieren Repository-Events. 18 Event-Kategorien werden unterstützt:

Pull-request-Trigger unterstützen Filter. Jeder Filter muss matchen, damit die Routine feuert:

Jedes matchende GitHub-Event startet seine eigene unabhängige Session. Kein Session-Reuse über Events hinweg.

Wie Routines sich von allem anderen unterscheiden

Claude Code hat jetzt vier Wege, Arbeit im Hintergrund laufen zu lassen. Sie lösen verschiedene Probleme.

Routines sind die richtige Wahl, wenn die Arbeit unabhängig davon passieren soll, ob dein Rechner an ist, oder wenn ein externes System sie triggern soll.

Desktop-Scheduled-Tasks sind besser, wenn du lokalen Dateizugriff oder Sub-Stunden-Intervalle brauchst.

/loop passt für schnelles, session-beschränktes Polling, das sterben soll, wenn du das Terminal schließt.

Monitor ist für event-getriebene Reaktionen auf einen laufenden Prozess (Logs beobachten, einen Dev-Server tailing).

Was du automatisieren kannst

Sechs Muster decken die meisten Use Cases ab. Jedes mappt auf einen Trigger-Typ und einen konkreten Workflow.

Nächtliche Issue-Triage (Schedule). Die Routine liest neue Issues von Linear oder GitHub via Connector, wendet Labels basierend auf Code-Bereich an, weist Eigentümer zu und postet eine Zusammenfassung an Slack. Läuft jede Nacht um 2 Uhr.

Alert-Triage (API). Dein Monitoring-Tool (Datadog, PagerDuty, Sentry) POSTet den Alert-Body an den Endpunkt der Routine. Claude zieht den Stack-Trace, korreliert ihn mit jüngsten Commits und öffnet einen Draft-PR mit einem vorgeschlagenen Fix. Wenn On-Call die Seite öffnet, ist der Kontext bereits zusammengestellt.

Code-Review bei jedem PR (GitHub). Löst auf pull_request.opened mit is_draft: false aus. Claude wendet die Review-Checkliste deines Teams an, hinterlässt Inline-Kommentare für Security- und Performance-Muster und fügt einen Summary-Kommentar hinzu. Nach Base-Branch oder Labels filtern, um es auf sensible Module einzugrenzen.

Deploy-Verifikation (API). Deine CD-Pipeline ruft den Endpunkt nach jedem Deploy auf. Claude führt Smoke-Checks gegen die Live-Umgebung durch, scannt Error-Logs auf Regressionen aus den letzten 30 Minuten und postet eine Go/No-Go-Nachricht an den Release-Channel.

Docs-Drift-Erkennung (Schedule). Läuft wöchentlich. Scannt gemergte PRs der letzten 7 Tage, identifiziert Docs-Seiten, die geänderte API-Endpunkte oder Funktionssignaturen referenzieren, und öffnet Update-PRs für jede.

Cross-SDK-Porting (GitHub). Löst auf pull_request.closed gefiltert auf is_merged: true aus. Wenn eine Änderung im Python-SDK landet, clont die Routine das Go-SDK-Repo, portiert die Änderung und öffnet einen passenden PR.

15 weitere Ideen, die sich lohnen zu automatisieren

Diese kamen von echten Nutzern, die teilten, was sie in den ersten Stunden nach dem Launch gebaut haben.

1. Morning-Standup-Vorbereitung. GitHub-Aktivität, Slack-Threads und Linear-Updates in ein einziges Briefing verdichten, das vor dem Standup in deinem Channel gepostet wird.
2. Dependency-Audit. Wöchentlicher Scan nach veralteten Paketen. Einen PR öffnen, der sichere Updates bumpt und brechende flaggt.
3. TODO-Scanner. Nächtlicher Sweep des Codebases nach neuen TODO-Kommentaren. In einem Tracking-Channel posten.
4. Release-Notes. Auf Release-Publish triggern. Gemergte PRs in formatierten Changelog kompilieren und CHANGELOG.md aktualisieren.
5. Security-Review-Gate. Auf PRs triggern, die auth- oder payments-Verzeichnisse berühren. Ein fokussiertes Security-Audit durchführen und riskante Muster flaggen.
6. Error-Log-Auto-Fix. Alle 2 Stunden Anwendungs-Logs nach FATAL-Einträgen scannen. Wenn der Fix offensichtlich ist, einen Draft-PR öffnen.
7. Stale-Branch-Cleanup. Wöchentliche Routine, die Branches ohne Commits in 30 Tagen listet und eine Cleanup-Zusammenfassung postet.
8. API-Contract-Check. Nachdem ein PR im Backend-Repo gemergt wird, verifizieren dass das Frontend noch zu den API-Typen passt.
9. Performance-Regression-Catch. GitHub-Trigger auf Push zu Main. Die Benchmark-Suite laufen und auf den Commit kommentieren, wenn etwas regressierte.
10. Competitor-Monitoring. Tägliche Routine, die Competitor-Changelog-Seiten checkt und eine Diff-Zusammenfassung postet.
11. Customer-Feedback-Triage. API-Trigger von deinem Support-Tool. Claude liest das Ticket, klassifiziert es und leitet es ans richtige Team weiter.
12. Onboarding-Doc-Frische. Monatliche Prüfung, dass Setup-Guides noch zu den tatsächlichen Install-Schritten passen.
13. PR-Babysitting. GitHub-Trigger bei Check-Fehlern. Claude liest die CI-Ausgabe, versucht einen Fix und pusht auf denselben Branch.
14. HN- und Reddit-Monitoring. Tägliche Routine, die nach Erwähnungen deines Produkts sucht und einen Digest postet.
15. Database-Migration-Review. GitHub-Trigger auf PRs, die Migration-Dateien berühren. Claude reviewed auf sicheres Rollback, Datenverlust-Risiko und Lock-Dauer.

Plan-Limits

Routines zählen gegen dein tägliches Run-Allowance und das Token-Budget deines Abonnements. Beide Limits gelten unabhängig.

Organisationen mit aktivierter Extra-Usage-Abrechnung können diese Caps zu gemessenen Overage-Raten überschreiten. Verbrauch unter claude.ai/settings/usage prüfen.

Gute Prompts für Routines schreiben

Ein Routine-Prompt läuft ohne Menschen in der Schleife. Der Prompt muss den gesamten Kontext tragen, den eine Konversation normalerweise durch Hin-und-Her liefert.

Sei explizit über das Ziel. "Review PRs" ist zu vage. "Lies jeden offenen PR in diesem Repo. Für jeden: prüfe auf fehlendes Error-Handling in async-Funktionen, SQL-Abfragen ohne parametrierte Inputs und React-Komponenten, die Hooks bedingt aufrufen. Hinterlasse einen Inline-Kommentar bei jedem Fund. Poste am Ende einen Summary-Kommentar." Diese Version läuft autonom ohne Raten.

Definiere, wie Erfolg aussieht. "Wenn keine Issues gefunden werden, poste einen einzigen Kommentar: 'Reviewed, no issues.' Öffne keinen PR. Poste nichts auf Slack."

Scope die Ausgabe. "Erstelle einen Draft-PR, keinen ready-for-review-PR. Push auf einen claude/-präfixierten Branch. Merge nichts."

Füge Fehler-Anweisungen ein. "Wenn der Build nach deinen Änderungen fehlschlägt, revertiere den Commit und hinterlasse einen Kommentar, der erklärt, was schiefgelaufen ist."

Sicherheit und Zugriffskontrolle

Routines handeln als du. Commits tragen deinen GitHub-Benutzernamen. Slack-Nachrichten nutzen deinen verknüpften Account. Behandle Routine-Zugriff genauso, wie du jemanden für eine Stunde deine Anmeldedaten überlässt.

Branch-Einschränkungen. Standardmäßig können Routines nur auf Branches mit dem Präfix claude/ pushen. Das verhindert, dass ein schlechter Prompt direkt zu main pusht. Deaktiviere diese Einschränkung nur, wenn die Routine speziell auf andere Branches pushen muss und du Branch-Protection-Regeln als Sicherheitsnetz hast.

Connector-Scoping. Jeder Connector, den du verknüpft hast, ist standardmäßig enthalten. Entferne die, die die Routine nicht braucht. Eine PR-Review-Routine braucht keinen Slack-Write-Zugriff. Eine Slack-Digest-Routine braucht keinen GitHub-Push-Zugriff.

Umgebungsvariablen. Secrets (API-Keys, Tokens) leben in der Umgebungskonfiguration, nicht im Prompt. Richte sie unter claude.ai/code/environments ein, bevor du die Umgebung an eine Routine anhängst.

Token-Speicherung. API-Trigger-Tokens werden genau einmal angezeigt, wenn sie generiert werden. Speichere sie sofort in deinem Secret-Manager. Du kannst sie später nicht abrufen.

Aktuelle Einschränkungen

Routines sind in Research-Preview. Ein paar Grenzen sind es wert zu kennen, bevor du darauf aufbaust.

Das Mindest-Schedule-Intervall ist eine Stunde. Für alles Schnellere nutze Desktop-Scheduled-Tasks (1 Minute Minimum) oder /loop.

Jeder Run clont das Repo frisch. Es gibt keinen lokalen Dateizugriff und keinen State, der zwischen Runs getragen wird. Wenn eine Routine sich etwas über Runs hinweg merken muss, muss sie diesen State ins Repo schreiben (eine JSON-Datei, einen Kommentar oder ein Issue).

GitHub-Webhook-Events haben während der Preview per-Routine- und per-Account-stündliche Caps. Ein hochfrequentiertes Repo mit breiten Trigger-Filtern kann den Cap schnell erschöpfen.

Routines gehören zu deinem individuellen Account. Sie werden nicht mit Teamkollegen geteilt. Jedes Teammitglied, das die gleiche Automatisierung will, erstellt seine eigene Kopie.

Der /fire-API-Endpunkt erfordert den Beta-Header anthropic-beta: experimental-cc-routine-2026-04-01. Das wird sich vor GA ändern.

Einstieg

Drei Schritte bringen heute eine nützliche Routine zum Laufen.

Wähl etwas mit niedrigem Risiko. Einen Morning-Digest, einen wöchentlichen TODO-Scan oder einen nächtlichen Issue-Label-Pass. Nichts, das zu main pusht oder Kunden anschreibt.

Erstelle es aus der CLI mit /schedule oder im Web unter claude.ai/code/routines. Schreib den Prompt, als würdest du einen Contractor briefen, der deinen Codebase noch nie gesehen hat. Mit /schedule run testen.

Beobachte die ersten drei Runs. Klicke in die Session-URL, lies was Claude getan hat, prüfe die Ausgabe. Verfeinere den Prompt basierend auf dem, was du siehst. Dann lass sie laufen.

Routines schließen die Lücke zwischen "Claude tut, was du ihm sagst" und "Claude tut, was getan werden muss, von selbst." Der Laptop bleibt geschlossen. Die Arbeit wird erledigt. Die Session liegt zur Review bereit, wenn du es wieder aufmachst.