Claude Code automatisieren: Loops, Hooks und Goals fuer den Alltag

Vom Werkzeug zum Prozess

Claude Code benutzt du normalerweise interaktiv: du stellst eine Aufgabe, das Tool arbeitet sie ab, du liest das Ergebnis, stellst die naechste Aufgabe. Fuer viele Alltagsfaelle reicht das nicht - ein Deploy braucht zehn Minuten bis er durchlaeuft, ein Pull Request bekommt ueber Stunden verteilt neue Review-Kommentare, eine Migration ist erst nach hunderten Dateien fertig. Genau dafuer bringt Claude Code vier Bausteine mit, die aus einer einzelnen Session einen laufenden Prozess machen: /loop fuer zeitgesteuerte Wiederholung, Hooks fuer deterministische Eingriffe an festen Punkten im Lebenszyklus, /goal fuer “arbeite weiter, bis eine Bedingung erfuellt ist”, und Routinen fuer Automatisierung, die unabhaengig von einer offenen Session in der Cloud laeuft. Dazu kommen MCP-Server, Subagenten und Skills, die diese Bausteine mit Werkzeugen und wiederverwendbarer Logik fuettern.

Dieser Artikel zeigt dir, was jeder Baustein tut, wie du ihn einrichtest, und - genauso wichtig - wann sich Automatisierung lohnt und wann sie nur Kosten und Risiko produziert.

Baustein 1: /loop - denselben Prompt wiederholt ausfuehren

/loop laesst Claude Code einen Prompt in einer laufenden Session periodisch neu ausfuehren. Sowohl das Intervall als auch der Prompt sind optional, und was du angibst, bestimmt das Verhalten:

/loop 15m Pruefe, ob der Build in CI durchgelaufen ist,
und melde mir das Ergebnis.

Bei einem festen Intervall rechnet Claude den Wert in einen Cron-Ausdruck um (Einheiten s, m, h, d; Sekunden werden auf die naechste Minute aufgerundet, da Cron nur minutengenau taktet) und bestaetigt Takt und Job-ID. Laesst du das Intervall weg, waehlt Claude nach jedem Durchlauf selbst eine Wartezeit zwischen einer Minute und einer Stunde - kurz, solange ein Build laeuft oder ein PR aktiv ist, laenger, wenn nichts ansteht. Fuer diesen dynamischen Modus kann Claude direkt das Monitor-Werkzeug nutzen, das ein Hintergrundskript startet und dessen Ausgabe zeilenweise zurueckstreamt, statt aktiv zu pollen.

Ein blosses /loop ohne Prompt fuehrt einen eingebauten Wartungs-Prompt aus: unfertige Arbeit aus der Konversation fortsetzen, den Pull Request des aktuellen Branches betreuen (Review-Kommentare, fehlgeschlagene CI-Laeufe, Merge-Konflikte), und erst danach Aufraeumarbeiten wie Bug-Hunts oder Vereinfachungen. Eine .claude/loop.md (projektweit) oder ~/.claude/loop.md (nutzerweit) ersetzt diesen Standard-Prompt durch eigene Anweisungen - sie definiert genau einen Default-Prompt, keine Liste separater Aufgaben, und wird ignoriert, sobald du /loop mit eigenem Prompt aufrufst.

Pruefe den PR fuer den Branch `release/next`. Wenn CI rot ist,
hol das fehlgeschlagene Job-Log, diagnostiziere die Ursache und
pushe einen minimalen Fix. Wenn neue Review-Kommentare da sind,
geh jeden einzeln durch und loese den Thread auf. Ist alles
gruen und ruhig, sag das in einer Zeile.

Du kannst auch eine Skill statt eines freien Prompts uebergeben, zum Beispiel /loop 20m /review-pr 1234, um diese Skill bei jedem Durchlauf erneut auszufuehren. Zum Stoppen waehrend ein Loop auf den naechsten Durchlauf wartet, druecke Esc - das entfernt nur den anstehenden Weckruf, geplante Aufgaben, die du per natuerlicher Sprache angelegt hast, bleiben davon unberuehrt.

Fuer einmalige Erinnerungen brauchst du kein /loop - eine natuerlichsprachliche Bitte wie erinnere mich in 45 Minuten, die Integrationstests zu pruefen legt eine selbstloeschende Einzel-Aufgabe an. Unter der Haube laufen sowohl wiederkehrende als auch einmalige Aufgaben ueber dieselben Cron-Werkzeuge, die sich auch direkt ansprechen lassen (Aufgaben anlegen, auflisten, loeschen); eine Session haelt bis zu 50 davon gleichzeitig.

Baustein 2: Hooks - deterministische Eingriffe in settings.json

Waehrend /loop und /goal das Modell selbst entscheiden lassen, wann weitergearbeitet wird, greifen Hooks deterministisch: Shell-Kommandos, HTTP-Endpunkte, Modell-Prompts oder MCP-Tools, die der Harness - also Claude Code selbst, nicht das Modell - an festen Punkten im Lebenszyklus ausfuehrt. Konfiguriert werden sie in einer JSON-Settings-Datei, mit unterschiedlichem Geltungsbereich:

Wichtige Ereignisse: PreToolUse/PostToolUse feuern vor beziehungsweise nach jedem Tool-Aufruf, Stop/SubagentStop wenn Claude beziehungsweise ein Subagent eine Antwort beendet, SessionStart/SessionEnd einmal pro Session, UserPromptSubmit wenn du einen Prompt abschickst. Der Exit-Code des Hooks steuert das Verhalten: 0 heisst Erfolg (optional mit strukturierter JSON-Ausgabe auf stdout), 2 blockiert - bei PreToolUse den Tool-Aufruf, bei Stop das Beenden der Antwort, wobei stderr dem Modell als Grund mitgegeben wird. Andere Exit-Codes gelten als nicht-blockierender Fehler, die erste Zeile von stderr wird im Transcript angezeigt.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/run-tests.sh"
          }
        ]
      }
    ]
  }
}

Der matcher filtert, fuer welche Tools ein Hook feuert - ein exakter Name oder eine Liste (Bash, Edit|Write), ein regulaerer Ausdruck (mcp__.* fuer alle Tools eines MCP-Servers), oder weggelassen fuer “immer”. Neben command-Hooks (Shell-Skript) gibt es http (POST an eine URL), mcp_tool (ruft ein Tool eines verbundenen MCP-Servers auf), prompt (schickt eine Ja/Nein-Frage an ein Modell) und - experimentell - agent (spawnt einen Subagenten zur Pruefung). Ein Beispiel, das einen rm -rf-Befehl blockiert:

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destruktiver Befehl von Hook blockiert"
    }
  }'
else
  exit 0
fi

Baustein 3: /goal - weiterarbeiten, bis eine Bedingung erfuellt ist

/goal setzt eine Abschlussbedingung; Claude arbeitet danach ueber mehrere Runden hinweg weiter, ohne dass du jeden Schritt erneut anstoesst. Nach jeder Runde prueft ein kleines, schnelles Modell (standardmaessig Haiku), ob die Bedingung erfuellt ist. Falls nicht, startet Claude direkt die naechste Runde statt dir die Kontrolle zurueckzugeben. Das Ziel wird automatisch geloescht, sobald die Bedingung zutrifft.

/goal Alle Tests in test/auth sind gruen und der Lint-Schritt ist sauber

Technisch ist /goal ein Wrapper um einen session-gebundenen, prompt-basierten Stop-Hook: Bedingung und bisherige Konversation gehen nach jeder Runde an das konfigurierte kleine Modell, das ein Ja/Nein mit kurzer Begruendung zurueckgibt. Der Evaluator ruft dabei selbst keine Tools auf - er beurteilt nur, was Claude im Transcript bereits sichtbar gemacht hat. Eine gute Bedingung braucht deshalb einen messbaren Endzustand (Testergebnis, Exit-Code, leere Warteschlange) und eine genannte Pruefmethode (“npm test beendet mit Exit-Code 0”), zum Beispiel ergaenzt um eine Obergrenze: oder brich nach 20 Runden ab.

Sinnvoll ist /goal fuer substanzielle Arbeit mit verifizierbarem Endzustand: ein Modul auf eine neue API migrieren, bis jeder Aufrufort kompiliert und Tests durchlaufen; ein Design-Dokument umsetzen, bis alle Akzeptanzkriterien erfuellt sind; eine grosse Datei aufteilen, bis jedes Modul unter einem Groessen-Budget liegt.

/goal ohne Argument zeigt den Status (Bedingung, Laufzeit, Anzahl geprueften Runden, Token-Verbrauch, letzte Begruendung), /goal clear (Aliase: stop, off, reset, none, cancel) bricht vorzeitig ab. /goal aendert selbst keine Berechtigungen - fuer unbeaufsichtigte Runden kombinierst du es mit dem Auto-Modus, der Tool-Aufrufe innerhalb einer Runde automatisch freigibt, aber keine neue Runde startet. /goal uebernimmt genau das: eine frische Bewertung nach jeder Runde statt nach jedem einzelnen Werkzeugaufruf.

Baustein 4: Routinen - Automatisierung ohne offene Session

/loop, Hooks und /goal brauchen alle eine laufende, lokale Session. Routinen loesen sich davon: eine gespeicherte Konfiguration aus Prompt, einem oder mehreren Repositories und angebundenen MCP-Connectors, die auf Anthropic-verwalteter Cloud-Infrastruktur laeuft und damit weiterarbeitet, auch wenn dein Rechner aus ist. Eine Routine kann mehrere Ausloeser kombinieren: zeitgesteuert (stuendlich, naechtlich, woechentlich oder einmalig zu einem Zeitpunkt), per API (HTTP-POST mit Bearer-Token an einen routinen-eigenen Endpunkt) und per GitHub-Ereignis (Pull-Request- oder Release-Events, optional gefiltert nach Autor, Branch oder Label).

/schedule taegliche PR-Review um 9 Uhr

/schedule in der CLI legt zeitgesteuerte Routinen an (Alias: /routines); API- und GitHub-Trigger konfigurierst du im Web-Interface unter claude.ai/code/routines. Routinen laufen vollstaendig autonom - es gibt keinen Permission-Modus-Picker und keine Freigabe-Nachfragen waehrend eines Laufs, was sie leistungsfaehig, aber auch riskant macht: was eine Routine erreichen kann, wird ausschliesslich durch die ausgewaehlten Repositories, deren Branch-Push-Einstellung, die Netzwerk-Policy der Cloud-Umgebung und die eingebundenen Connectors begrenzt. Standardmaessig darf Claude nur auf claude/-praefixierte Branches pushen.

MCP, Subagenten und Skills als Zubehoer

Diese vier Automatisierungs-Bausteine werden erst nuetzlich, wenn Claude auch etwas zu tun hat. Ueber MCP (Model Context Protocol) bindest du zusaetzliche Werkzeuge und Datenquellen an - ein GitHub-, Jira- oder Slack-Server liefert Claude die Tools, die ein Loop oder eine Routine tatsaechlich braucht:

# MCP-Server lokal hinzufuegen (Beispiel: GitHub, mit PAT als Header)
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer DEIN_GITHUB_PAT"

# Server mit Umgebungsvariable, z.B. eine eigene Slack-Anbindung per stdio
claude mcp add --env SLACK_BOT_TOKEN=xoxb-dein-token --transport stdio slack \
  -- npx -y @modelcontextprotocol/server-slack

Subagenten sind eigenstaendige Claude-Code-Sitzungen mit eigenem Kontextfenster und eigener Werkzeugliste, gestartet ueber das Task-Werkzeug der Hauptsession - nuetzlich, um unabhaengige Arbeit zu parallelisieren oder den Hauptkontext vor grossen Zwischenergebnissen zu schuetzen. Skills sind Ordner mit einer SKILL.md-Anleitung plus optionalen Skripten und Vorlagen, die Claude automatisch aus ~/.claude/skills/ (nutzerweit) oder .claude/skills/ (projektweit) entdeckt und bei Bedarf selbst aufruft - eine Skill lohnt sich fuer wiederkehrende Domain-Logik, ein Subagent fuer isolierte Parallelarbeit. Beide lassen sich innerhalb eines /loop- oder Goal-Zyklus wiederverwenden, statt dieselbe Anleitung jedes Mal neu im Prompt zu formulieren.

Praxisbeispiele

Deploy beobachten, ohne selbst zu warten:

/loop check ob der Deploy auf staging durchgelaufen ist,
und falls die Health-Checks fehlschlagen, lies die Logs
und fasse die wahrscheinliche Ursache zusammen

Pull Request babysitten bis zum Mergen:

Pruef den PR fuer den aktuellen Branch. CI rot: Log holen,
Ursache diagnostizieren, minimalen Fix pushen. Neue Review-
Kommentare: einzeln beantworten, Thread aufloesen. Alles
gruen und ruhig: kurz bestaetigen, keine neue Arbeit anfangen.

Migration bis zum verifizierbaren Endzustand:

/goal Jeder Aufrufort der alten Auth-API ist auf die neue API
migriert, `npm run build` und `npm test` laufen beide fehlerfrei
durch, oder brich nach 30 Runden ab

Naechtliche Backlog-Pflege ohne offene Session (Routine):

Ein zeitgesteuerter Trigger laeuft jede Nacht gegen den Issue-Tracker via MCP-Connector, vergibt Labels basierend auf betroffenen Codebereichen und postet eine Zusammenfassung in Slack - laeuft auch, wenn niemand einen Laptop offen hat.

Kosten, Kontrolle und wann sich Automatisierung nicht lohnt

Jede automatisierte Runde - ob durch /loop, /goal oder eine Routine ausgeloest - verbraucht Tokens wie eine normale Session, plus bei /goal einen kleinen, meist vernachlaessigbaren Zusatzverbrauch fuer die Bewertung. Ein dynamisch getakteter Loop, der ueber Stunden alle paar Minuten pollt, oder ein /goal, das nie zutrifft und 30 Runden lang weiterlaeuft, summiert sich. Mehr zu Kostenkontrolle generell in Tokens und Kosten optimieren.

Wichtiger als die reinen Kosten ist die Kontrollfrage: Automatisierung heisst, dass Aktionen ohne deine Freigabe pro Schritt passieren. Routinen laufen komplett ohne Permission-Prompts, ein /goal kombiniert mit Auto-Modus ebenso. Das ist genau dann sinnvoll, wenn die Aufgabe eng begrenzt ist (ein Modul, ein PR, ein klar definierter Testlauf) und ein verifizierbares Abbruchkriterium hat - und riskant, wenn die Aufgabe vage bleibt (“verbessere den Code”) oder irreversible Aktionen wie Force-Push, Datenbank-Migrationen oder das Loeschen von Branches ausserhalb der eng begrenzten claude/-Praefix-Regel involviert.

Zusammenfassung

• /loop wiederholt einen Prompt zeitgesteuert oder selbstgetaktet innerhalb einer offenen Session; eine loop.md ersetzt den eingebauten Wartungs-Prompt durch eigene Anweisungen.
• Hooks in settings.json fuehren deterministisch Shell-Kommandos, HTTP-Calls, MCP-Tool-Aufrufe oder Modell-Prompts an festen Lebenszyklus-Punkten (PreToolUse, Stop etc.) aus - der Harness fuehrt sie aus, nicht das Modell selbst.
• /goal setzt eine Abschlussbedingung, die nach jeder Runde von einem kleinen Modell geprueft wird, technisch ein Wrapper um einen prompt-basierten Stop-Hook.
• Routinen laufen unabhaengig von einer offenen Session auf Anthropic-Cloud-Infrastruktur, ausgeloest per Zeitplan, API oder GitHub-Ereignis - vollstaendig autonom, ohne Permission-Nachfragen.
• MCP-Server, Subagenten und Skills liefern die Werkzeuge und wiederverwendbare Logik, die diese Automatisierungs-Bausteine erst nuetzlich machen.
• Automatisierung lohnt sich fuer eng begrenzte Aufgaben mit klarem, verifizierbarem Endzustand - nicht fuer vage Ziele oder irreversible Aktionen ohne Sicherheitsnetz.

Weiterlernen

• Claude Code Hooks Reference (offiziell)
• Run prompts on a schedule - /loop (offiziell)
• Keep Claude working toward a goal - /goal (offiziell)
• Automate work with routines (offiziell)
• Connect to MCP servers (offiziell)
• Claude Code Overview (offiziell)

Verwandte Themen: MCP - Model Context Protocol · Agentische Coding-CLIs im Vergleich · KI-Agents und Tool-Use · Tokens und Kosten optimieren