Workflows und Automatisierung

Sobald Claude Code nicht mehr nur im Terminal vor dir sitzt, sondern in deiner Pipeline, in einem Zeitplan oder in einem Skript steckt, verschiebt sich die Frage: nicht „was kann ich es fragen", sondern „was soll ohne mich passieren". Dieses Modul geht die drei Wege durch — der einmalige Aufruf aus CI, die geplante Aufgabe in der Cloud und der Workflow, der Arbeit auf viele Agents verteilt — und schließt mit Mustern, die sich in der Praxis bewährt haben.

Claude Code aus CI und Skripten heraus aufrufen

Der Einstieg in jede Automatisierung ist --print, kurz -p. Claude arbeitet den mitgegebenen Prompt ab, schreibt die Antwort nach stdout und beendet sich — kein Prompt, keine Rückfragen. Für Skripte lohnen sich drei Begleiter: --output-format json verpackt Antwort, Session-ID und Metadaten so, dass jq damit umgehen kann, --permission-mode bypassPermissions nimmt die Berechtigungsabfragen heraus, die in einer CI ohnehin niemand beantworten könnte, und --max-turns deckelt die Zahl der agentischen Züge. Achtung bei der Bedeutung: --max-turns zählt Züge, nicht Minuten, und bricht beim Erreichen der Grenze mit einem Fehler ab.

Damit lässt sich ein PR-Review als ganz gewöhnlicher Schritt in GitHub Actions formulieren: Diff einsammeln, in claude -p pipen, Ergebnis weiterreichen. Das Piping hat einen Nebeneffekt, den man leicht übersieht — Claude braucht so keine Bash-Berechtigung, um an den Diff zu kommen:

- name: Claude Code Review
  run: |
    DIFF=$(git diff origin/main...HEAD)
    REVIEW=$(echo "$DIFF" | claude -p "Review these changes. Output JSON with fields: summary, critical_issues, suggestions" \
      --output-format json \
      --permission-mode bypassPermissions)
    echo "$REVIEW" | jq '.critical_issues[]' >> $GITHUB_STEP_SUMMARY

Ein verwandtes, aber anderes Werkzeug ist --from-pr. Es startet keine Session aus einem Pull Request, sondern findet sie: Claude Code verknüpft eine Session automatisch mit dem PR, den es anlegt, und --from-pr öffnet die Sitzungsauswahl gefiltert auf genau diesen PR. Als Argument geht die PR-Nummer oder die volle URL; seit v2.1.119 auch GitHub Enterprise, GitLab-Merge-Requests und Bitbucket-Pull-Requests:

claude --from-pr https://github.com/org/repo/pull/123
claude --from-pr https://gitlab.com/org/repo/-/merge_requests/456
claude --from-pr https://bitbucket.org/org/repo/pull-requests/789

Für Läufe, die nichts hinterlassen sollen, gibt es zwei Schalter mit verschiedenen Aufgaben. --no-session-persistence schreibt die Session gar nicht erst auf die Platte, sie ist danach also auch nicht fortsetzbar. --bare zielt auf etwas anderes: Es überspringt das automatische Einlesen von Hooks, Skills, Plugins, MCP-Servern, Auto-Memory und CLAUDE.md. Der Lauf startet dadurch schneller — vor allem aber liefert er auf jeder Maschine dasselbe, weil der Hook im Heimatverzeichnis eines Kollegen schlicht nicht gelesen wird. Genau deshalb ist --bare die empfohlene Form für Skripte und CI.

Wenn dein Team Pull Requests nicht auf github.com anschaut, sondern in einer eigenen Oberfläche, zeigt das PR-Abzeichen in der Fußzeile trotzdem dorthin. Die Einstellung prUrlTemplate (seit v2.1.119) biegt das Ziel auf deine URL um:

{
  "prUrlTemplate": "https://review.example.internal/pr/{number}"
}

Den umgekehrten Weg — GitHub ruft Claude, nicht Claude GitHub — richtet /install-github-app ein. Der Befehl installiert die Claude GitHub App auf dem Repository und fragt danach, ob er dich auch durch die GitHub-Actions-Workflows und das Secret für den API-Key führen soll; ab v2.1.187 kannst du mit „Skip for now" bei der App stehen bleiben und den Rest später nachholen. Für beides brauchst du Admin-Rechte auf dem Repository. Steht auch der Workflow, beantwortet Claude @claude-Erwähnungen in Pull Requests und Issues direkt im Thread.

Benachrichtigungen aufs Handy

Läuft eine Remote-Control-Sitzung, kann Claude Push-Nachrichten auf dein Handy schicken. Wann, entscheidet es selbst: typischerweise, wenn eine lange Aufgabe fertig ist oder eine Entscheidung ansteht. Du kannst eine auch anfordern, etwa mit notify me when the tests finish. Nötig sind die Claude-App für iOS oder Android, angemeldet mit demselben Konto und derselben Organisation, die Mitteilungs-Freigabe des Betriebssystems und in /config einer der beiden Schalter oder beide: Push when Claude decides für Nachrichten, die Claude von sich aus schickt, Push when actions required für Berechtigungsabfragen und Rückfragen. Beide setzen Claude Code v2.1.119 oder neuer voraus, und mehr Feinsteuerung je Ereignis gibt es nicht. Solange du im verbundenen Terminal tippst, unterbleibt der Push.

Soll ein Pull Request auch dann weiterlaufen, wenn du längst woanders bist, übernimmt /autofix-pr. Der Befehl ermittelt aus deinem ausgecheckten Branch mit gh pr view den offenen PR — die gh-CLI ist also Voraussetzung — und startet eine Sitzung von Claude Code on the web, die ihn beobachtet. Fällt ein Check um oder kommt ein Review-Kommentar, sieht Claude nach: Ist der Fix eindeutig, pusht es ihn und erklärt im Verlauf, was es getan hat; ist die Anmerkung mehrdeutig oder architektonisch schwerwiegend, fragt es vorher nach. Mit einem Prompt engst du den Auftrag ein, etwa /autofix-pr only fix lint and type errors. Voraussetzung sind die Claude GitHub App auf dem Repository und Zugang zu Claude Code on the web — der Organisationen mit aktivierter Zero Data Retention verschlossen bleibt.

Für den gründlichen Blick vor dem Merge gibt es die Cloud-Review. Sie startet heute als /code-review ultra; /ultrareview ist der Alias aus der Einführung in v2.1.111 und funktioniert weiter. In einer entfernten Sandbox prüft eine ganze Flotte von Agents deinen Branch. Gegenüber einer lokalen Review sind das drei Unterschiede: jeder Befund wird unabhängig nachvollzogen, bevor er dir gemeldet wird; die größere Flotte kommt weiter in die Änderung hinein; und dein Rechner bleibt frei, weil alles entfernt läuft. Weil sie auf der Infrastruktur von Claude Code on the web läuft, braucht sie ein claude.ai-Konto; wer nur mit API-Key angemeldet ist, führt vorher /login aus. Ohne Argument vergleicht sie deinen Branch gegen den Standard-Branch samt nicht committeter Änderungen, mit einer PR-Nummer prüft sie einen Pull Request. Pro und Max bringen drei kostenlose Läufe mit, ein einmaliges Kontingent, das sich nicht auffrischt; danach — und auf Team und Enterprise von Anfang an — wird als Extra-Nutzung abgerechnet, je nach Umfang der Änderung ungefähr 5 bis 25 $. Ein Lauf dauert typisch 5 bis 10 Minuten; über /tasks siehst du ihn, öffnest die Detailansicht oder brichst ab — dann wird die Cloud-Sitzung archiviert, Teilergebnisse kommen nicht zurück:

/ultrareview           # review current branch
/ultrareview 456       # review GitHub PR #456

Nach Zeitplan: Routines und Arbeit im Hintergrund

Zeitgesteuert arbeiten kann Claude Code auf zwei Ebenen, die man nicht verwechseln sollte. /loop wiederholt einen Prompt, solange deine Sitzung offen ist — stirbt das Terminal, stirbt die Schleife. Routines dagegen liegen in der Cloud: Jeder Lauf klont dein Repository frisch, arbeitet autonom und kann Branches pushen oder Pull Requests öffnen, ganz gleich, ob dein Rechner an ist:

# Check build status every 5 minutes (session-scoped)
/loop 5m check if the build succeeded and summarize any failures

# Create a cloud routine from the CLI
/schedule "run a full security audit at 2am"
/schedule daily PR review at 9am

Was eine Routine ist

Eine Routine ist eine einmal gespeicherte Claude-Code-Konfiguration: ein Prompt, ein oder mehrere Repositories, eine Umgebung und eine Auswahl an Connectors. Ausgeführt wird sie auf von Anthropic verwalteter Infrastruktur. Anlegen und pflegen kannst du sie im Web unter claude.ai/code/routines, in der Desktop-App oder mit /schedule im Terminal; /schedule list zeigt alle, /schedule update ändert eine, /schedule run stößt eine sofort an. Weil der Lauf niemanden fragen kann, trägt der Prompt die ganze Last: Er muss aus sich heraus verständlich sein und sagen, woran man Erfolg erkennt.

Was eine Routine startet, legst du über Trigger fest — beliebig kombinierbar, eine Routine darf alle drei tragen:

• Zeitplan — eine wiederkehrende Frequenz (stündlich, täglich, an Wochentagen, wöchentlich) oder ein einzelner Lauf zu einem künftigen Zeitpunkt. Zeiten gibst du in deiner Zone an, umgerechnet wird automatisch; ein Versatz von wenigen Minuten ist eingeplant und je Routine gleich. Einen eigenen Cron-Ausdruck setzt du danach mit /schedule update — kürzer als eine Stunde wird abgelehnt.
• API — ein eigener HTTP-Endpunkt je Routine. Ein POST mit dem Bearer-Token der Routine startet einen Lauf und liefert dir die Session-URL zurück; im optionalen Feld text kannst du laufspezifischen Kontext mitgeben. Der Token wird genau einmal angezeigt, also gleich sicher ablegen.
• GitHub — reagiert auf Ereignisse am Repository, wählbar sind Pull Requests und Releases. Filter grenzen ein, welcher davon zählt: Autor, Titel, Rumpf, Base- und Head-Branch, Labels, Entwurfs- und Merge-Status, je mit einem Operator von „ist gleich" bis „passt auf diesen regulären Ausdruck". Dafür muss die Claude GitHub App auf dem Repository installiert sein.

Ein Lauf ist eine vollwertige Cloud-Sitzung ohne Berechtigungsabfragen: keine Modus-Auswahl, keine Rückfrage, auch nicht bei schreibenden Werkzeugen. Begrenzt wird sie durch das, was du ihr gibst — die ausgewählten Repositories, den Netzzugang der Umgebung und die Connectors. Deine claude.ai-Connectors sind beim Anlegen alle enthalten; alles, was die Routine nicht braucht, gehört heraus. Pushen darf Claude standardmäßig nur auf Branches mit dem Präfix claude/; wer mehr will, schaltet je Repository Allow unrestricted branch pushes frei. Und was die Routine über dein GitHub-Konto oder deine Connectors tut, erscheint unter deinem Namen.

Routines sind eine Research Preview — Verhalten, Grenzen und API können sich ändern. Verfügbar sind sie auf Pro, Max, Team und Enterprise, sofern Claude Code on the web für das Konto freigeschaltet ist, und sie gehören deinem persönlichen claude.ai-Konto, nicht dem Team. Owner auf Team und Enterprise können sie für alle Mitglieder über den Routines-Schalter unter claude.ai/admin-settings/claude-code abschalten; vorhandene Routines laufen dann nicht mehr, und neue lassen sich auch nicht mehr anlegen. Im Terminal legt /schedule nur zeitgesteuerte Routines an — API- und GitHub-Trigger ergänzt du im Web.

Automatik im Hintergrund

Nicht jede Nebenläufigkeit braucht die Cloud. Subagents laufen seit v2.1.198 ohnehin standardmäßig im Hintergrund; background: true im Frontmatter erzwingt das auch dann, wenn Claude das Ergebnis eigentlich sofort bräuchte. Du stößt also eine lange Analyse an, arbeitest weiter und bekommst ihr Ergebnis, wenn sie fertig ist. Automatik hängst du an die Übergänge, die die Doku dafür vorsieht — jeder an seiner eigenen Stelle: TaskCompleted läuft, wenn eine Aufgabe als erledigt markiert wird, sei es über das Werkzeug TaskUpdate oder weil ein Team-Mitglied seinen Zug mit offenen Aufgaben beendet; TeammateIdle greift, kurz bevor ein Team-Mitglied in den Leerlauf geht. Was du daranhängst, ist frei — eine Nachricht in den Team-Kanal genauso wie eine Prüfung, die den Abschluss verweigert: Endet der Hook mit Code 2, bleibt die Aufgabe offen und seine Meldung geht als Rückmeldung an das Modell:

{
  "hooks": {
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST $SLACK_WEBHOOK -d '{\"text\": \"Task completed: $TASK_NAME\"}'"
          }
        ]
      }
    ]
  }
}

Über mehrere Sitzungen hinweg trägt kein Hintergrundlauf. Was trägt, ist Gedächtnis: Ein Subagent mit memory: user bekommt ein eigenes Memory-Verzeichnis, schreibt seine Erkenntnisse dort hinein, und die ersten 200 Zeilen beziehungsweise 25 KB seiner MEMORY.md stehen beim nächsten Start wieder in seinem Systemprompt. Für lange Recherche ist das der verlässlichere Weg als der Versuch, einen Lauf offen zu halten.

Dynamische Workflows: das Skript hält den Plan

Subagents, Skills und Agent Teams haben eines gemeinsam: Claude entscheidet Zug um Zug, was als Nächstes passiert, und jedes Zwischenergebnis landet in seinem Kontextfenster. Ein dynamic workflow dreht das um. Claude schreibt ein JavaScript-Skript, und eine Laufzeitumgebung führt es aus — die Schleife, die Verzweigung und die Zwischenergebnisse stecken im Skript, Claudes Kontext behält nur die Antwort. Damit sind Dutzende bis Hunderte Agents in einem Lauf möglich, und die Orchestrierung selbst wird zu etwas, das man lesen und noch einmal laufen lassen kann.

Ausgelöst wird ein Workflow, indem du das Wort ultracode irgendwo in deinen Prompt schreibst; „nutze einen Workflow" in eigenen Worten zählt genauso. Vor v2.1.160 hieß das Schlüsselwort workflow. Wichtig ist, wo es wirkt: nur in einem Prompt, den du selbst tippst. Über -p, aus einer geplanten Aufgabe, aus einem Webhook oder aus einem weitergereichten PR-Kommentar startet es keinen Workflow. Je nach Berechtigungsmodus zeigt Claude Code danach die geplanten Phasen zur Freigabe — im Auto-Modus nur beim ersten Lauf und bei eingeschaltetem ultracode gar nicht, unter bypassPermissions, mit -p und im Agent SDK nie. Der Lauf arbeitet dann im Hintergrund, während deine Sitzung bedienbar bleibt. Unterbrichst du ihn, nimmt ein Fortsetzen die fertigen Agent-Ergebnisse aus dem Zwischenspeicher — aber nur innerhalb derselben Sitzung: Beendest du Claude Code, fängt der Workflow beim nächsten Mal von vorn an.

Einen fertigen Workflow bringt Claude Code mit. /deep-research <question> fächert Websuchen über mehrere Blickwinkel auf, holt die gefundenen Quellen, prüft sie gegeneinander, stimmt über jede Behauptung ab und liefert am Ende einen Bericht mit Quellenangaben, aus dem alles herausgefallen ist, was der Gegenprüfung nicht standgehalten hat. Was die Prüfer gar nicht bewerten konnten, etwa nach einem Rate-Limit, steht seit v2.1.196 als „ungeprüft" darin statt als widerlegt. Voraussetzung ist das WebSearch-Werkzeug:

/deep-research What changed in the Node.js permission model between v20 and v22?

Was gerade läuft, zeigt /workflows. Aus der Liste öffnest du die Fortschrittsansicht mit Agent-Zahl, Token-Summe und verstrichener Zeit je Phase und steigst bis zum einzelnen Agent hinunter, um Prompt, Werkzeugaufrufe und Ergebnis zu lesen; p pausiert, x stoppt. Hat ein Lauf getan, was du wolltest, drückst du s und legst sein Skript als Befehl ab — im Projekt unter .claude/workflows/ für alle, die das Repository klonen, oder unter ~/.claude/workflows/ nur für dich. Danach steht er als /<name> in jeder weiteren Sitzung bereit; über args kann er beim Aufruf noch Eingaben entgegennehmen.

Wenn du nicht bei jeder Aufgabe neu entscheiden willst, gibt es /effort ultracode: Es verbindet die Denktiefe xhigh mit automatischer Orchestrierung, und Claude plant von sich aus einen Workflow für jede substanzielle Aufgabe — manchmal mehrere hintereinander, einen zum Verstehen, einen zum Ändern, einen zum Prüfen. Das kostet spürbar mehr Zeit und Tokens. Die Einstellung gilt für die laufende Sitzung; /effort high bringt dich zurück.

Dynamic workflows brauchen Claude Code v2.1.154 oder neuer und stehen auf allen kostenpflichtigen Plänen zur Verfügung, mit Zugang zur Anthropic-API sowie auf Amazon Bedrock, Google Clouds Agent Platform und Microsoft Foundry. Auf Pro schaltest du sie in der Zeile „Dynamic workflows" in /config ein. Abschalten geht an drei Stellen: derselbe Schalter in /config, "disableWorkflows": true in den Einstellungen oder CLAUDE_CODE_DISABLE_WORKFLOWS=1 in der Umgebung, das beim Start gelesen wird und deshalb überall greift, wo du es setzt. Sind Workflows aus, verschwinden die mitgelieferten Workflow-Befehle, das Schlüsselwort löst nichts mehr aus, und ultracode fehlt im /effort-Menü.

Muster, die mehrere Schritte tragen

Die haltbaren Automatisierungen bestehen selten aus einem Werkzeug. Sie setzen Skills, Hooks und Subagents zu einer Kette zusammen, in der jeder Schritt weiß, was er bekommt, was er abliefert und was bei einem Fehler passieren soll. Drei dieser Ketten kommen immer wieder vor.

Das erste Muster ist die Abschlussprüfung. Ein Stop-Hook vom Typ prompt bekommt beim Beenden eine Frageliste vorgelegt: Wurden alle Dateien aus der Spezifikation angefasst, laufen die Tests, ist die Umsetzung vollständig? Fällt die Antwort negativ aus, kommt sie als Rückmeldung zu Claude zurück, und die Arbeit geht weiter, statt zu enden:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check: 1) Were all files in the spec modified? 2) Do tests pass? 3) Is the implementation complete per the requirements? If anything is incomplete, explain what remains.",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Das zweite Muster ist die Prüfung aus mehreren Blickwinkeln. Mit Agent Teams — experimentell und standardmäßig aus, freigeschaltet über CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 — sieht ein Teammitglied auf Sicherheit, ein zweites auf Performance, ein drittes auf die Testabdeckung. Anders als Subagents reden sie direkt miteinander und arbeiten eine gemeinsame Aufgabenliste ab; die Sitzung, die als Lead auftritt, führt die Befunde zusammen. Der Preis ist hoch: Jedes Mitglied ist eine eigene Claude-Instanz, und bei Sitzungs-Wiederaufnahme, Aufgaben-Koordination und Herunterfahren gibt es bekannte Einschränkungen.

Das dritte Muster ist die Massenänderung. /batch <instruction> liest sich erst in die Codebasis ein, zerlegt die Arbeit in 5 bis 30 unabhängige Einheiten und legt dir den Plan vor. Nach deiner Freigabe bekommt jede Einheit einen Hintergrund-Subagent in einem eigenen Git-Worktree, der sie umsetzt, die Tests laufen lässt und einen Pull Request öffnet. Ein Git-Repository ist Voraussetzung.

Die Isolierung dahinter kannst du auch einzeln haben: isolation: worktree im Frontmatter eines Subagents gibt ihm eine eigene Arbeitskopie, standardmäßig vom Standard-Branch abgezweigt und nicht vom aktuellen Stand deiner Sitzung. Sein cd und seine Befehle bleiben in dieser Kopie; ein Kommando, das doch in deinem Hauptcheckout landen würde, scheitert mit einer Fehlermeldung. Hat der Agent nichts geändert, räumt Claude Code den Worktree selbst wieder weg — was mit Änderungen zurückbleibt, bleibt liegen, bis du es angesehen hast.