+180 XP

Claude · Wiederkehrende Arbeit automatisieren

Derselbe Prompt, den Sie jeden Montagmorgen von Hand ausführen, kann sich selbst ausführen, ein Wettbewerbs-Briefing erzeugen und in Ihrem Postfach liegen, bevor Sie Ihren Kaffee ausgetrunken haben. Der Abstand zwischen einer einmaligen Claude-Aufgabe und einer freihändigen Pipeline ist kleiner, als er aussieht, und diese Lektion schließt ihn.

Sie wissen bereits, wie Sie einmal ein gutes Ergebnis von Claude bekommen. Jetzt machen wir es wiederholbar, geplant und sicher.

Die drei Orte, an denen Automatisierung lebt

Es gibt drei Sprossen auf der Automatisierungsleiter, und Sie steigen sie danach hoch, wie viel Kontrolle und Infrastruktur Sie wollen.

Sprosse 1: Innerhalb der Claude-Apps. Projects, Connectors und Skills erlauben Ihnen viel, ohne Code anzufassen. Ein Connector verbindet Claude mit einem externen System (Gmail, Google Drive, Linear, eine Datenbank) über MCP, das Model Context Protocol, den offenen Standard, mit dem ein Modell externe Tools und Datenquellen aufrufen kann. Das ist die No-Code-Sprosse.

Sprosse 2: Claude Code und geplante Agents. Claude Code kann unbeaufsichtigt in einem Terminal oder Container laufen. Kombinieren Sie es mit cron (dem Standard-Job-Scheduler unter Unix), und Sie haben einen wiederkehrenden Agent auf Ihrer eigenen Maschine oder einem kleinen Server.

Sprosse 3: CI wie GitHub Actions. Ihre Automatisierung lebt in einem Repo, läuft auf der Infrastruktur von Anthropic oder GitHub, hat Logs und wird zeitgesteuert oder durch ein Event ausgelöst. Das ist die am besten auditierbare und am stärksten „produktive“ Variante.

Wir bauen das Montags-Briefing auf Sprosse 3, aber ich zeige Ihnen, wo Sprosse 1 und 2 hineinpassen.

Was „geplant“ tatsächlich bedeutet

Ein Zeitplan ist nur ein Trigger. Die Arbeit selbst ist ein normaler Claude-Agent: ein Prompt, ein paar Tools und ein Modellaufruf. **Neu ist, dass *niemand zusieht, wenn er läuft*. Das ändert, wie Sie ihn entwerfen.**

Im Chatfenster sind Sie das Guardrail. Sie sehen eine schlechte Antwort und führen sie neu aus. Eine unbeaufsichtigte Pipeline hat keinen Menschen in dieser Schleife, also müssen die Guardrails in die Pipeline selbst geschrieben werden. Behalten Sie das im Kopf; es bestimmt jede Design-Entscheidung weiter unten.

Der konkrete Aufbau: ein Montags-Wettbewerbs-Briefing

Hier ist das Ziel. Jeden Montag um 7 Uhr macht Claude Folgendes:

  1. Zieht aktuelle News und Preisseiten von drei Wettbewerbern.
  2. Vergleicht sie mit dem Briefing der Vorwoche.
  3. Schreibt ein einseitiges Briefing, das hervorhebt, was sich geändert hat.
  4. Mailt es an das Team, aber erst, wenn eine Kosten- und Plausibilitätsprüfung bestanden ist.

Schritt 1: Die Aufgabe einmal von Hand zum Laufen bringen

Automatisieren Sie nie etwas, das Sie nicht vorher manuell ausgeführt haben. Bauen Sie es als Claude Code-Session oder als Project, bis das Ergebnis wirklich gut ist. Das ist Ihre Spezifikation.

Halten Sie die erfolgreichen Instruktionen als wiederverwendbares Asset fest. Ein Skill ist ein verpacktes Set aus Instruktionen und Ressourcen, das Claude bei Bedarf lädt, etwa ein Playbook für Wettbewerbsanalyse mit Ihrem Briefing-Template, Tonalitätsregeln und Quellenliste. Ein Skill macht dasselbe Verhalten portabel, von Ihrer Desktop-Session in die automatisierte.

Schritt 2: Die Engine wählen

Für einen geplanten Job ist das Claude Agent SDK (früher Claude Code SDK) das richtige Werkzeug. Es gibt Ihnen die Agent-Loop von Claude Code (Planung, Tool-Aufrufe, Datei-Edits) als programmierbare Library, damit Ihr geplanter Lauf sich so verhält wie die interaktive Session, die Sie bereits abgestimmt haben.

Hier ist der Kern des Jobs. Er ist absichtlich klein: die Intelligenz sitzt im Prompt und im Skill, nicht im Python.

python
import os
from claude_agent_sdk import query, ClaudeAgentOptions

async def generate_brief() -> str:
    options = ClaudeAgentOptions(
        system_prompt="You are a competitive intelligence analyst. "
                      "Use the competitive-brief skill. Be concise and cite sources.",
        allowed_tools=["WebFetch", "Read", "Write"],
        permission_mode="acceptEdits",
        max_turns=20,
    )

    prompt = (
        "Generate this week's competitive brief comparing Acme, Globex, and Initech. "
        "Compare against last_week.md. Output a one-page brief to brief.md. "
        "Flag only what materially changed."
    )

    result = []
    async for message in query(prompt=prompt, options=options):
        result.append(message)
    return open("brief.md").read()

Zwei Dinge fallen auf. allowed_tools ist eine Whitelist: der Agent darf Webseiten abrufen sowie Dateien lesen und schreiben, und nichts weiter. max_turns begrenzt, wie lange die Agent-Loop laufen kann. Beides sind Guardrails, und wir fangen gerade erst an.

Schritt 3: einplanen

Auf Ihrer eigenen Maschine oder Ihrem Server genügt cron. Ein Crontab-Eintrag besteht aus fünf Zeitfeldern plus einem Befehl. Das hier führt den Job jeden Montag um 7 Uhr aus:

bash
# m h dom mon dow  command
0 7 * * 1  cd /opt/briefs && /usr/bin/python run_brief.py >> brief.log 2>&1

Die 1 im fünften Feld ist Montag. Die Umleitung am Ende hält ein Log, das Sie beim ersten Mal brauchen werden, wenn um 7 Uhr etwas kaputtgeht, während Sie schlafen.

Cron ist gut für einen persönlichen Server, aber er stirbt, wenn Ihr Laptop in den Ruhezustand geht, und er hat keinen Audit-Trail außer einer Textdatei. Für alles, worauf ein Team angewiesen ist, wechseln Sie zu CI.

Schritt 4: zu GitHub Actions befördern

GitHub Actions führt Ihren Job zeitgesteuert mit derselben cron-Syntax aus, aber in einem sauberen Cloud-Container mit Logs, Secrets-Management und Historie. Die offizielle Claude-GitHub-Integration ist dafür gebaut.

yaml
name: weekly-competitive-brief
on:
  schedule:
    - cron: "0 7 * * 1"   # Mondays 07:00 UTC
  workflow_dispatch:        # lets you trigger a manual run too

jobs:
  brief:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install claude-agent-sdk
      - name: Generate brief
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: python run_brief.py

Ihr API-Key liegt in den verschlüsselten Secrets von GitHub, nie im Code. workflow_dispatch ist eine kleine, aber wichtige Ergänzung: damit können Sie die Pipeline zum Testen auf Abruf laufen lassen, statt auf Montag zu warten.

Die Guardrails, die es sicher machen

Das ist der Teil, den Leute überspringen, und es ist der Teil, der zählt. Ein unbeaufsichtigter Agent mit Kreditkarte und E-Mail-Knopf ist ein Risiko, solange Sie ihn nicht einschränken.

Kostenobergrenzen

Setzen Sie ein hartes Budget auf Account-Ebene in der Anthropic Console, mit Nutzungslimits und Spend-Alerts auf dem API-Key, den diese Pipeline verwendet. Geben Sie der Automatisierung ihren eigenen Key, damit eine entlaufene Loop nicht Ihr gesamtes Budget leeren kann. Das max_turns-Limit im SDK ist Ihre zweite Schicht: es begrenzt einen einzelnen Lauf, selbst wenn der Prompt den Agent im Kreis schickt.

Wählen Sie außerdem das richtige Modell für die Aufgabe. Ein wöchentliches Briefing braucht nicht für jede Teilaufgabe Ihr teuerstes Modell. Günstigere Modelle für Abrufen und Zusammenfassen, ein stärkeres Modell für die finale Synthese, das hält die Kosten planbar.

Ein Review-Schritt vor allem Irreversiblen

E-Mail-Versand ist irreversibel. Teilen Sie die Pipeline also: generate läuft unbeaufsichtigt, aber send wartet auf ein menschliches Nicken, zumindest solange, bis Sie ihm vertrauen.

Das saubere Muster in GitHub Actions ist, das Briefing als Entwurf auszugeben und eine manuelle Freigabe zu verlangen (eine Environment-Protection-Rule), bevor der Send-Schritt läuft. Sie bekommen die E-Mail automatisch entworfen und ein „ship it“ mit einem Klick.

Wissenscheck

1. Was ändert sich laut der Lektion grundlegend, wenn eine Claude-Aufgabe zeitgesteuert läuft und niemand zusieht?

2. Was ist MCP (das Model Context Protocol), wie es in der Lektion beschrieben wird?

3. Warum bestehtdie Lektion darauf, eine Aufgabe manuell auszuführen, bevor Sie sie automatisieren?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die drei Sprossen der Automatisierungsleiter korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Punkte, die echte Schritte der Montags-Wettbewerbs-Briefing-Automatisierung sind.

Wählen Sie alle richtigen Antworten aus.

Das Ergebnis validieren, nicht nur den Lauf

Ein Job, der „erfolgreich“ ist, kann trotzdem Müll produzieren. Bauen Sie vor dem Send-Schritt ein günstiges Validierungs-Gate ein: existiert brief.md, ist es von vernünftiger Länge, enthält es die drei Wettbewerbsnamen, zitiert es mindestens eine Quell-URL? Wenn eine Prüfung scheitert, stoppen und alarmieren, statt Unsinn zu mailen.

python
def validate(brief: str) -> None:
    assert 500 < len(brief) < 8000, "brief length looks wrong"
    for name in ("Acme", "Globex", "Initech"):
        assert name in brief, f"missing competitor: {name}"
    assert "http" in brief, "no sources cited"

Das ist absichtlich dummer Code. Deterministische Prüfungen fangen die Fehler, die ein modellbasiertes Review wegargumentieren könnte.

Tools eng zuschneiden

Beachten Sie: wir haben dem Agent im SDK-Aufruf nie ein „E-Mail senden“-Tool gegeben. Der Versand passiert in einem separaten, dummen Skript *nach* der Freigabe. Halten Sie destruktive oder nach außen wirkende Aktionen aus der Tool-Liste des Agents heraus und in einfachem Code, den Sie kontrollieren. Der Agent schreibt eine Datei; Ihre Pipeline entscheidet, was damit passiert.

Building Agents with the Claude Agent SDK

Watch on YouTube

Wo die No-Code-Sprosse hineinpasst

Sie brauchen nicht immer ein Repo. Wenn Ihre wiederkehrende Aufgabe „fasse die Linear-Issues dieser Woche in einem Slack-Post zusammen“ lautet, genügt vielleicht ein Connector plus ein geplanter Trigger in einem Automatisierungstool, ganz ohne Python. Der Connector-Marktplatz wächst schnell, prüfen Sie also, ob es für Ihre Datenquelle schon einen gibt, bevor Sie einen eigenen MCP-Server bauen.

Die Entscheidungsregel: bleiben Sie no-code, solange die Aufgabe einfach und der Blast Radius klein ist. Wechseln Sie zu SDK und CI, wenn Sie Versionskontrolle, echtes Logging, Kostenkontrollen und Review-Gates brauchen. Das Montags-Briefing liegt genau auf der Grenze, deshalb ist es ein gutes Lehrbeispiel.

Idempotenz: die stille Anforderung

Ein letztes Konzept, das ein Spielzeug von einer Pipeline trennt. Idempotenz heißt, dass ein zweimaliges Ausführen des Jobs ein korrektes Ergebnis produziert, nicht zwei Katastrophen. Wenn GitHub einen Lauf wiederholt oder Sie ihn manuell zum Testen auslösen, wollen Sie keine zwei E-Mails oder eine beschädigte History-Datei.

Machen Sie den Lauf wiederholbar: schreiben Sie in eine datierte Datei (brief-2026-01-19.md), prüfen Sie vor dem Versand, ob das Briefing dieser Woche schon existiert, und behandeln Sie „schon erledigt“ als Erfolg. Billig hinzuzufügen, schmerzhaft nachzurüsten nach dem Tag, an dem Sie zwei Briefings und ein verwirrtes Team haben.

Wichtigste Erkenntnisse

  • Bringen Sie es zuerst von Hand zum Laufen, dann planen Sie es ein. Ihre abgestimmte Claude-Code- oder Project-Session ist die Spezifikation; verpacken Sie das erfolgreiche Verhalten als Skill, damit es sauber in den automatisierten Lauf übergeht.
  • Passen Sie die Sprosse an die Einsätze an. Connectors und die App für einfache, risikoarme Aufgaben; das Claude Agent SDK plus cron für persönliche Jobs; GitHub Actions, wenn ein Team auf Logs, Secrets und Historie angewiesen ist.
  • Schreiben Sie die Guardrails in die Pipeline, denn kein Mensch schaut zu. Nutzen Sie einen dedizierten API-Key mit Nutzungslimits, begrenzen Sie max_turns, setzen Sie Tools auf eine Whitelist und führen Sie deterministische Validierung vor jeder irreversiblen Aktion aus.
  • Halten Sie irreversible Aktionen aus dem Agent heraus. Lassen Sie Claude die Datei erzeugen; lassen Sie einfachen Code, abgesichert durch eine menschliche Freigabe, den Versand machen.
  • Machen Sie jeden Lauf idempotent. Datierte Outputs und „schon erledigt“-Prüfungen sorgen dafür, dass ein Retry oder ein Testlauf nie doppelte E-Mails oder beschädigten Zustand produziert.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Jeden geplanten Run idempotent machen: datierte Outputs und Done-Checks
Vollständiges Action Playbook ansehen →