Entwicklungsworkflows mit Claude Code automatisieren

Workflow-Automatisierung mit Claude Code bedeutet nicht, dass ein Agent unbeaufsichtigt Code mergt. Die robuste Variante ist kleiner: Claude Code fasst Issues zusammen, bereitet begrenzte Änderungen vor, prüft PRs, erstellt Wartungsberichte und stoppt dort, wo ein Mensch entscheiden muss.

Die folgenden Beispiele lassen sich mit gh, git, node, npm und claude ausführen. Der wichtigste Gedanke ist ein Harness, also ein kontrolliertes Gerüst für den Agenten: Eingaben, erlaubte Aktionen, Logs, Retries, Rollback und menschliche Freigaben werden vorher festgelegt.

Die Grenze der Automatisierung festlegen

Phase	Claude Code übernimmt	Mensch entscheidet
Triage	Issues, Diffs und Fehlerlogs zusammenfassen	Priorität und Produktentscheidung
Änderung	Kleine Fixes, Tests, Dokumentation	Umfang und Veröffentlichung
Review	Bugs, Sicherheitsrisiken, fehlende Tests	Welche Hinweise umgesetzt werden
Betrieb	Geplante Checks, alte TODOs, Abhängigkeiten	Merge, Löschung, Release, Abrechnung

flowchart LR
  A["Issue / PR"] --> B["Kleiner Prompt"]
  B --> C["Claude Code"]
  C --> D["Diff und Logs"]
  D --> E["Tests"]
  E --> F["Menschliche Freigabe"]
  F --> G["PR / Release"]

Für den größeren Pipeline-Kontext passen der Claude Code CI/CD-Leitfaden und der Claude Code Hooks-Leitfaden gut dazu.

Anwendungsfall 1: Aus einem Issue einen sicheren Arbeitsbranch machen

Dieses Skript liest ein GitHub Issue, erstellt oder verwendet einen deterministischen Branch, bittet Claude Code um die kleinste sinnvolle Änderung, führt Tests aus und überlässt den Commit dir.

Speichere es als scripts/claude-issue-work.sh.

#!/usr/bin/env bash
set -euo pipefail

ISSUE_NUMBER="${1:-}"
if [ -z "$ISSUE_NUMBER" ]; then
  echo "Usage: ./scripts/claude-issue-work.sh <issue-number>"
  exit 1
fi

for command_name in git gh claude npm; do
  if ! command -v "$command_name" >/dev/null 2>&1; then
    echo "Missing command: $command_name"
    exit 1
  fi
done

: "${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY before running this script}"

mkdir -p .claude-logs
ISSUE_FILE=".claude-logs/issue-${ISSUE_NUMBER}.md"
LOG_FILE=".claude-logs/issue-${ISSUE_NUMBER}-$(date +%Y%m%d-%H%M%S).log"
BRANCH="claude/issue-${ISSUE_NUMBER}"

gh issue view "$ISSUE_NUMBER" --json title,body,labels --jq '
  "# " + .title + "\n\n" + (.body // "") + "\n\nLabels: " + ([.labels[].name] | join(", "))
' > "$ISSUE_FILE"

if git show-ref --verify --quiet "refs/heads/$BRANCH"; then
  git switch "$BRANCH"
else
  git switch -c "$BRANCH"
fi

PROMPT=$(cat <<PROMPT
Du bist der Entwicklungsassistent für dieses Repository.
Lies das Issue unten und setze die kleinste nützliche Änderung um.

Einschränkungen:
- Untersuche zuerst die relevanten Dateien.
- Bevorzuge vorhandene Architektur, Namen und Teststile.
- Wenn Anforderungen unklar sind, hinterlasse ein TODO oder eine Frage statt ein großes Design zu erfinden.
- Berühre keine Secrets, Umgebungsdateien oder nicht verwandten Artikel.
- Lasse das Repository bereit für npm test.
- Führe keinen commit, push, PR-Erstellung oder merge aus.

Issue:
$(cat "$ISSUE_FILE")
PROMPT
)

claude -p "$PROMPT" \
  --max-turns 8 \
  --permission-mode acceptEdits \
  --output-format text 2>&1 | tee "$LOG_FILE"

npm test 2>&1 | tee -a "$LOG_FILE"
git diff --stat | tee -a "$LOG_FILE"

echo "Review the diff, then commit manually if it is correct."
echo "Log: $LOG_FILE"

Die Schutzmaßnahmen wirken im Alltag. Ohne ANTHROPIC_API_KEY stoppt das Skript sofort. Der Branchname ist idempotent, also kehrt ein erneuter Lauf zum gleichen Branch zurück. Die Logs in .claude-logs zeigen später, welcher Prompt lief und welcher Test fehlschlug.

Anwendungsfall 2: PR-Review in GitHub Actions

Die offizielle Claude Code GitHub Action kann bei PR-Ereignissen laufen. Dieser Workflow fordert nur Review-Hinweise an und verbietet Änderungen, Push und Merge.

Speichere ihn als .github/workflows/claude-review.yml.

name: Claude Review Gate

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Prüfe diesen Pull Request.
            Achte auf Bugs, Sicherheit, fehlende Tests, Rückwärtskompatibilität und Betriebslogs.
            Markiere jeden Fund mit high, medium oder low und schreibe konkrete Korrekturvorschläge.
            Ändere keinen Code, pushe nicht und merge nicht.
          claude_args: |
            --max-turns 6
            --permission-mode plan

Halte Berechtigungen eng. Für ein reines PR-Review sind meist contents: read und pull-requests: write zentral. issues: write ist nur nötig, wenn dein Workflow auch auf Issues kommentiert.

Prüfe vor dem Kopieren alter Beispiele die offizielle Claude Code CLI-Referenz, die Claude Code GitHub Actions-Dokumentation und die GitHub Actions Workflow-Syntax. Alte Beispiele mit @beta oder direct_prompt gehören auf @v1 und prompt umgestellt.

Anwendungsfall 3: Wartungsbericht mit Node.js

Geplante Wartung muss keine Dateien ändern. Ein Bericht über fehlgeschlagene Tests, große Diffs, alte TODOs, fehlende Logs oder Rollback-Risiken spart bereits viel Nacharbeit.

Speichere die Datei als scripts/claude-maintenance.mjs.

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
import { join } from "node:path";

const logDir = ".claude-logs";
const lockFile = join(logDir, "maintenance.lock");
const stamp = new Date().toISOString().replace(/[:.]/g, "-");
const logFile = join(logDir, `maintenance-${stamp}.log`);

function fail(message) {
  console.error(message);
  process.exit(1);
}

function run(command, args, options = {}) {
  const result = spawnSync(command, args, {
    encoding: "utf8",
    shell: process.platform === "win32",
    ...options,
  });

  const output = `${result.stdout || ""}${result.stderr || ""}`;
  if (result.status !== 0) {
    writeFileSync(logFile, output);
    fail(`Command failed: ${command} ${args.join(" ")}. See ${logFile}`);
  }
  return output;
}

if (!process.env.ANTHROPIC_API_KEY) {
  fail("Set ANTHROPIC_API_KEY before running this script.");
}

mkdirSync(logDir, { recursive: true });
if (existsSync(lockFile)) {
  fail(`Another maintenance run is active: ${lockFile}`);
}

writeFileSync(lockFile, String(process.pid));

try {
  const status = run("git", ["status", "--short"]);
  const tests = run("npm", ["test", "--", "--runInBand"]);
  const prompt = [
    "Du bist der Wartungsreviewer dieses Repositorys.",
    "Lies git status und die Testausgabe und fasse die heutigen Risiken zusammen.",
    "Ändere, lösche, committe oder pushe nichts.",
    "Gruppiere nach credentials / idempotency / retry / rollback / logs / human approval.",
    "",
    "git status:",
    status || "(clean)",
    "",
    "test output:",
    tests.slice(-12000),
  ].join("\n");

  const review = run("claude", [
    "-p",
    prompt,
    "--max-turns",
    "5",
    "--permission-mode",
    "plan",
    "--output-format",
    "text",
  ]);

  writeFileSync(logFile, review);
  console.log(`Maintenance report written to ${logFile}`);
} finally {
  rmSync(lockFile, { force: true });
}

Wenn du kein Jest nutzt, ersetze npm test -- --runInBand durch den Testbefehl deines Projekts. Das Skript übergibt nur die letzten 12000 Zeichen, damit ein zu langer Prompt die eigentliche Fehlermeldung nicht verdeckt.

Anwendungsfall 4: Mit cron oder Aufgabenplanung starten

Unter Linux und macOS eignet sich cron. Unter Windows nutzt du die Aufgabenplanung. GitHub Actions schedule funktioniert ebenfalls, aber lokale Ausführung ist oft besser, wenn Datenbank, VPN oder interne Zugangsdaten nötig sind.

# Werktags um 08:15 ausführen
15 8 * * 1-5 cd /path/to/repo && /usr/bin/node scripts/claude-maintenance.mjs >> .claude-logs/cron.log 2>&1

# Tägliche Windows-Aufgabe registrieren
schtasks /Create /TN "ClaudeMaintenance" /SC DAILY /ST 08:15 /F /TR "powershell -NoProfile -ExecutionPolicy Bypass -Command \"cd C:\path\to\repo; node scripts\claude-maintenance.mjs\""

Geplante Automatisierung muss idempotent sein: Ein zweiter Lauf darf keine doppelten PRs, Kommentare oder Branches erzeugen. Nutze Locks, stabile Namen, Statusprüfungen und Logs.

Anwendungsfall 5: Menschliche Freigaben in den Prompt schreiben

Ein kurzer Prompt ist nicht automatisch sicherer. Ein guter Workflow-Prompt nennt Erlaubtes, Verbotenes und Entscheidungen mit menschlicher Freigabe.

claude -p "
Ziel:
  Review-Feedback aus PR #123 umsetzen.

Erlaubt:
  - Relevante Implementierungs- und Testdateien ändern.
  - npm test ausführen.
  - Fehlerlogs zusammenfassen.

Verboten:
  - git push
  - gh pr merge
  - .env oder Secrets anzeigen
  - Nicht verwandte Refactorings

Menschliche Freigabe nötig:
  - Kompatibilitätsänderungen an API-Antworten
  - Datenbankmigrationen
  - Löschen bestehender Tests

Abschlussbericht:
  - Geänderte Dateien
  - Ausgeführte Tests
  - Verbleibende Risiken
  - Rollback-Schritte
" --max-turns 6 --permission-mode acceptEdits

Für Review-Struktur helfen die Claude Code Review-Checkliste und der Workflow für Verifikationsnachweise.

Fehlerbilder, die du einplanen musst

Fehlerbild	Wirkung	Praktische Gegenmaßnahme
Prompt zu lang	Einschränkungen gehen unter, Laufzeit steigt	Nur relevante Dateien und Log-Ende übergeben
Zugangsdaten fehlen	CI scheitert an ANTHROPIC_API_KEY oder GH_TOKEN	Umgebungsvariablen am Anfang prüfen
Keine Idempotenz	Doppelte PRs, Kommentare oder Branches	Stabile Namen, Locks, Zustandsprüfung
Keine Logs	Niemand weiß, was der Agent versucht hat	.claude-logs oder GitHub artifacts speichern
Naiver Retry	Temporärer Fehler wird zu doppeltem Schreiben	Nur Lesevorgänge wiederholen, vor Schreiben Zustand prüfen
Kein Rollback	Ein großer Commit ist schwer rückgängig zu machen	Kleine PRs und Rollback-Notizen verlangen
Keine Freigabe	Agent trifft Produkt- oder Releaseentscheidungen	Kompatibilität, Daten, Abrechnung, Löschung und Merge bleiben menschlich

Nahe Themen sind Claude Code Sicherheitsaudit, Claude Code Teststrategien und Git-Workflow-Automatisierung.

Monetarisierungs-CTA und AdSense

Die passende Conversion ist hier praktische Hilfe, nicht Übertreibung. Einzelne Entwickler starten mit dem kostenlosen Claude Code Spickzettel. Teams mit Bedarf an repo-spezifischen Prompts, Review-Gates, Freigaberichtlinien und Einführungstraining nutzen die Claude Code Trainings- und Beratungsseite. Für fertiges Setup-Material ist der Claude Code Setup-Leitfaden die bezahlte Abkürzung.

Platziere Anzeigen und CTA nicht mitten in Befehlsfolgen. Für AdSense-Qualität braucht dieser Artikel ausführbaren Code, konkrete Fehlerbilder, offizielle Links, interne Links und ein echtes Testergebnis.

Fazit

Claude Code Workflow-Automatisierung wird zuverlässig, wenn zuerst die Stopppunkte feststehen. Beginne mit Issue-Triage und PR-Review, ergänze kleine Änderungen und gehe erst danach zu geplanter Wartung und CI-Gates mit menschlicher Freigabe.

Im Praxistest von Masa war der größte Nutzen nicht die vollautomatische PR-Erstellung, sondern wiederholbare Issue-Logs und ein fester PR-Review-Prompt. Fehlender ANTHROPIC_API_KEY, zu lange Testausgaben und erneute Läufe auf demselben Branch verursachten je einen Fehler; Umgebungsprüfungen, Log-Kürzung und deterministische Branchnamen machten die nächste Diagnose deutlich leichter.