Claude Code Routines
Claude Code Routines führen gespeicherte Prompts in Anthropics Cloud aus, ausgelöst durch Zeitplan, API-Aufruf oder GitHub-Event. Repo-Clone, Connectors, keine lokalen Abhängigkeiten.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Problem: Dein Laptop muss offen bleiben, damit Claude Code irgendetwas tut. Desktop Scheduled Tasks und /loop laufen lokal, das heißt ein zugeklappter Deckel killt jede Automatisierung. Außerdem kannst du nicht auf externe Events wie einen GitHub-PR oder einen Monitoring-Alert reagieren, ohne aktiv zu pollen.
Quick Win: Erste Cloud-Routine aus der CLI anlegen und sofort testen:
/schedule daily PR review at 9am/schedule runDer erste Befehl erstellt eine Routine, die jeden Morgen dein Repo in Anthropics Cloud clont und den Prompt ausführt. Der zweite feuert sie direkt, damit du den Output prüfen kannst, bevor du dem Zeitplan vertraust.
Was Routines sind
Eine Routine ist drei Dinge in einem Paket: ein Prompt, ein oder mehrere GitHub-Repositories und eine Reihe von Connectors (MCP-Server wie Slack, Linear oder Datadog). Einmal konfiguriert. 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 läuft autonom. 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 noch ändern.
Wo Routines verwaltet werden
Drei Oberflächen erstellen und verwalten Routines. Alle schreiben in denselben Cloud-Account.
Web-UI unter claude.ai/code/routines. Volle Kontrolle über alle Einstellungen: Prompt, Modell, Repos, Umgebung, Trigger und Connectors.
CLI mit /schedule. Erstellt nur Schedule-Routines. Unterbefehle:
| Befehl | Was er tut |
|---|---|
/schedule daily PR review at 9am | Erstellt eine neue Routine mit diesem Rhythmus |
/schedule list | Zeigt alle Routines auf deinem Account |
/schedule update | Öffnet den Editor für eine bestehende Routine |
/schedule run | Feuert eine Routine sofort zum Testen |
Desktop-App über Schedule > New task > New remote task. "New local task" erstellt stattdessen eine Desktop Scheduled Task, die auf deinem Rechner läuft.
API-Trigger und GitHub-Trigger lassen sich bislang nur über die Web-UI konfigurieren. 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: stündlich, täglich, werktags, wöchentlich. Custom-Cron-Ausdrücke funktionieren auch, einstellen mit /schedule update. Mindestintervall ist eine Stunde. Zeiten richten sich nach deiner lokalen 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. 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:
| Event | Feuert wenn |
|---|---|
| Pull request | Geöffnet, geschlossen, zugewiesen, gelabelt, synchronisiert |
| Pull request review | Eingereicht, bearbeitet, abgelehnt |
| PR review comment | Diff-Kommentar erstellt, bearbeitet, gelöscht |
| Push | Commits landen auf einem Branch |
| Release | Erstellt, veröffentlicht, bearbeitet, gelöscht |
| Issues | Geöffnet, bearbeitet, geschlossen, gelabelt |
| Issue comment | Kommentar zu Issue oder PR erstellt, bearbeitet, gelöscht |
| Check run | Erstellt, angefordert, abgeschlossen |
| Check suite | Abgeschlossen oder angefordert |
| Workflow run | GitHub Actions Workflow startet oder schließt ab |
| Workflow job | Job eingereiht oder abgeschlossen |
| Workflow dispatch | Workflow manuell ausgelöst |
| Repository dispatch | Custom repository_dispatch-Event gesendet |
| Discussion | Erstellt, bearbeitet, beantwortet |
| Discussion comment | Erstellt, bearbeitet, gelöscht |
| Sub issues | Sub-Issue oder Parent hinzugefügt/entfernt |
| Commit comment | Commit kommentiert |
| Merge queue entry | PR betritt oder verlässt die Merge-Queue |
Pull-request-Trigger unterstützen Filter. Jeder Filter muss matchen, damit die Routine feuert:
| Filter | Beispiel |
|---|---|
| Author | @dependabot |
| Title contains | auth-provider |
| Base branch | main |
| Head branch contains | feature/ |
| Labels include | needs-review |
| Is draft | false |
| Is merged | true |
| From fork | true |
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 (Cloud) | Desktop Scheduled Tasks | /loop | Monitor | |
|---|---|---|---|---|
| Läuft auf | Anthropic Cloud | Deinem Rechner | Deinem Rechner | Deinem Rechner |
| Rechner muss an sein | Nein | Ja | Ja | Ja |
| Session muss offen sein | Nein | Nein | Ja | Ja |
| Lokaler Dateizugriff | Nein (frischer Clone) | Ja | Ja | Ja |
| Mindestintervall | 1 Stunde | 1 Minute | 1 Minute | Echtzeit |
| API/Webhook-Trigger | Ja | Nein | Nein | Nein |
| Übersteht Neustart | Ja | Ja | Nein | Nein |
| Permission-Prompts | Keine (autonom) | Konfigurierbar | Geerbt | Geerbt |
Routines sind die richtige Wahl, wenn die Arbeit unabhängig davon laufen soll, ob dein Rechner eingeschaltet ist, oder wenn ein externes System sie triggern soll.
Desktop Scheduled Tasks sind besser, wenn du lokalen Dateizugriff oder kürzere Intervalle als eine Stunde brauchst.
/loop passt für schnelles, session-gebundenes Polling, das sterben soll, wenn du das Terminal schließt.
Monitor ist für event-getriebene Reaktionen auf einen laufenden Prozess, zum Beispiel Logs beobachten oder einen Dev-Server begleiten.
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, vergibt Labels nach Code-Bereich, 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 oder 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 fertig.
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-Meldung an den Release-Channel.
Docs-Drift-Erkennung (Schedule). Läuft wöchentlich. Scannt gemergte PRs der letzten 7 Tage, findet 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 in den ersten Stunden nach dem Launch geteilt haben, was sie gebaut haben.
- Morning Standup Prep. GitHub-Aktivität, Slack-Threads und Linear-Updates zu einem einzigen Briefing verdichten, das vor dem Standup in deinem Channel landet.
- Dependency-Audit. Wöchentlicher Scan nach veralteten Paketen. PR öffnen, der sichere Updates bumpt und brechende flaggt.
- TODO-Scanner. Nächtlicher Sweep der Codebase nach neuen TODO-Kommentaren. In einem Tracking-Channel posten.
- Release-Notes. Trigger auf Release Publish. Gemergte PRs in formatierten Changelog kompilieren und CHANGELOG.md aktualisieren.
- Security-Review-Gate. Trigger auf PRs, die auth- oder payments-Verzeichnisse berühren. Fokussiertes Security-Audit durchführen und riskante Muster flaggen.
- Error-Log-Auto-Fix. Alle 2 Stunden Anwendungs-Logs nach FATAL-Einträgen scannen. Wenn der Fix offensichtlich ist, Draft-PR öffnen.
- Stale-Branch-Cleanup. Wöchentliche Routine, die Branches ohne Commits in 30 Tagen listet und eine Cleanup-Zusammenfassung postet.
- API-Contract-Check. Nachdem ein PR im Backend-Repo gemergt wurde, prüfen ob das Frontend noch zu den API-Typen passt.
- Performance-Regression-Catch. GitHub-Trigger auf Push zu main. Benchmark-Suite laufen und auf den Commit kommentieren, wenn etwas regressierte.
- Competitor-Monitoring. Tägliche Routine, die Competitor-Changelog-Seiten prüft und eine Diff-Zusammenfassung postet.
- Customer-Feedback-Triage. API-Trigger von deinem Support-Tool. Claude liest das Ticket, klassifiziert es und leitet es ans richtige Team weiter.
- Onboarding-Doc-Frische. Monatliche Prüfung, dass Setup-Guides noch zu den tatsächlichen Install-Schritten passen.
- PR-Babysitting. GitHub-Trigger bei Check-Fehlern. Claude liest den CI-Output, versucht einen Fix und pusht auf denselben Branch.
- HN- und Reddit-Monitoring. Tägliche Routine, die nach Erwähnungen deines Produkts sucht und einen Digest postet.
- Database-Migration-Review. GitHub-Trigger auf PRs, die Migration-Dateien berühren. Claude prüft 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 voneinander.
| Plan | Tägliche Routine-Runs |
|---|---|
| Pro ($20/mo) | 5 |
| Max ($100-200/mo) | 15 |
| Team | 25 |
| Enterprise | 25 |
Organisationen mit aktivierter Extra-Usage-Abrechnung können diese Caps zu Metered-Overage-Raten überschreiten. Verbrauch prüfen unter claude.ai/settings/usage.
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. Prüfe für jeden 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, was Erfolg aussieht. "Wenn keine Issues gefunden werden, poste einen einzigen Kommentar: 'Reviewed, no issues.' Öffne keinen PR. Poste nichts auf Slack."
Scope den Output. "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 so, als würdest du jemandem für eine Stunde deine Anmeldedaten überlassen.
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. Diese Einschränkung nur deaktivieren, wenn die Routine gezielt 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 dabei. 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 und Tokens leben in der Umgebungskonfiguration, nicht im Prompt. Einrichten unter claude.ai/code/environments, bevor du die Umgebung an eine Routine hängst.
Token-Speicherung. API-Trigger-Tokens werden genau einmal angezeigt, wenn sie generiert werden. Sofort in deinem Secret-Manager speichern. Später nicht mehr abrufbar.
Aktuelle Einschränkungen
Routines sind in Research Preview. Ein paar Grenzen lohnen sich 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. Kein lokaler Dateizugriff, kein State zwischen Runs. Wenn eine Routine sich etwas über Runs hinweg merken muss, schreibt sie diesen State ins Repo: 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. Kein Teilen mit Teamkollegen. Wer dieselbe 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, und eine nützliche Routine läuft heute.
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. Klick in die Session-URL, lies was Claude getan hat, prüfe den Output. Passe den Prompt basierend auf dem Gesehenen an. 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 zu. Die Arbeit wird erledigt. Die Session liegt zur Review bereit, wenn du wieder aufklappst.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Das Claude Code Monitor-Tool
Das Claude Code Monitor-Tool umschließt einen Hintergrundprozess mit einem ereignisgesteuerten Watcher. Dein Dev-Server bleibt still, bis er abbricht, dann weckt er Claude mit Fehlermeldungen.
Die Ralph-Wiggum-Technik
Gib Claude Code eine Aufgabenliste, nutze Stop-Hooks und Completion-Promises, und der autonome Loop liefert Features über Nacht. Native Tasks ersetzen inzwischen den meisten Boilerplate.