KI-Code-Review in GitHub Actions mit Claude und Gemini

12 Min. Lesezeit·Matthieu·ci-cdgeminiclaudeai-code-reviewgithub-actions|

Richten Sie Claude Code Action und Gemini für automatisierte Pull-Request-Reviews ein. Multi-Modell-Workflows mit Rollentrennung, Quality Gates die Merges bei kritischen Befunden blockieren und Absicherung gegen Prompt Injection.

KI-Code-Review hat sich vom Experiment zum Produktionswerkzeug entwickelt. Claude Code Action und Gemini Code Assist können jeden Pull Request automatisch analysieren und dabei Logikfehler, Sicherheitslücken und fehlende Fehlerbehandlung erkennen, die Linter und statische Analyse komplett übersehen.

Dieses Tutorial richtet beide Modelle im selben Repository ein. Claude übernimmt die Logik- und Sicherheitsanalyse. Gemini kümmert sich um Stil und Dokumentation. Ein Quality Gate wertet die Severity beider Reviews aus und blockiert Merges, wenn kritische Probleme gefunden werden.

AIOps auf einem VPS: KI-gesteuerte Serververwaltung mit Open-Source-Tools

Was erkennt KI-Code-Review, das Linter nicht finden?

Linter prüfen Syntax und Formatierung. Statische Analysewerkzeuge wie Semgrep erkennen bekannte Muster. KI-Code-Reviewer machen etwas anderes: Sie lesen den Diff im Kontext und denken darüber nach, was der Code tut. Sie melden Race Conditions, fehlende Fehlerbehandlungspfade, unsichere Standardeinstellungen und Geschäftslogikfehler, die musterbasierte Werkzeuge nicht erkennen können.

Eine Milvus-Studie testete fünf KI-Modelle bei der Erkennung realer Bugs in Produktions-PRs. Das beste Einzelmodell erkannte 53 % der Bugs. Als mehrere Modelle dieselbe PR analysierten und ihre Ergebnisse diskutierten, stieg die Erkennungsrate auf 80 %. Die schwierigsten Bugs, solche die ein systemweites Verständnis von Aufrufketten und Fehlerausbreitung erfordern, erreichten im Multi-Modell-Debattenmodus 100 % Erkennung.

Diese Studie ist der Grund, warum dieses Tutorial zwei Modelle statt eines verwendet.

Konkrete Beispiele, was KI-Review erkennt:

  • Nicht validierte Benutzereingaben, die durch drei Funktionsaufrufe fließen, bevor sie eine Datenbankabfrage erreichen
  • Fehlende Null-Prüfungen, wenn eine Funktion Optional<T> zurückgibt, der Aufrufer aber davon ausgeht, dass sie immer erfolgreich ist
  • Hartcodierte Geheimnisse in Konfigurationsdateien, die wie Platzhalter aussehen, aber echte Zugangsdaten sind
  • Lücken in der Fehlerbehandlung, wo ein try/catch eine generische Exception fängt und sie stillschweigend verschluckt
  • Race Conditions in nebenläufigem Code, wo geteilter Zustand ohne Synchronisation verändert wird

Wie richtet man Claude Code Action für Pull-Request-Reviews ein?

Claude Code Action ist eine GitHub Action, die von Anthropic gepflegt wird und Claude auf Ihrem GitHub Runner ausführt. Sie liest PR-Diffs, veröffentlicht Inline-Kommentare und kann auch Fixes implementieren. Die Einrichtung dauert etwa fünf Minuten.

Die Claude GitHub App installieren

Gehen Sie zu github.com/apps/claude und installieren Sie sie in Ihrem Repository oder Ihrer Organisation. Gewähren Sie Zugriff auf die Repositories, die Sie analysieren lassen möchten. Die App benötigt diese Berechtigungen:

  • Contents: Read
  • Pull Requests: Read & Write
  • Issues: Read & Write (optional, für Issue-Triage)

Den API-Schlüssel hinzufügen

Gehen Sie in Ihrem Repository zu Settings > Secrets and variables > Actions und erstellen Sie ein neues Repository-Secret:

  • Name: ANTHROPIC_API_KEY
  • Value: Ihr Anthropic-API-Schlüssel (beginnt mit sk-ant-)

Committen Sie niemals API-Schlüssel in Ihr Repository. Wenn Sie organisationsweiten Zugriff benötigen, verwenden Sie Environment Secrets statt Repository Secrets.

Den Workflow erstellen

Erstellen Sie .github/workflows/claude-review.yml:

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

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

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      id-token: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review this pull request. Focus on:
            1. Security: injection flaws, auth bypass, hardcoded secrets, insecure defaults
            2. Logic errors: off-by-one, null dereference, race conditions, resource leaks
            3. Error handling: swallowed exceptions, missing retries, unclear error messages
            4. Performance: N+1 queries, unbounded loops, unnecessary allocations

            Skip cosmetic issues (formatting, naming style). Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Use inline comments for specific code issues.
            Use a summary PR comment for overall assessment.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Der paths-Filter beschränkt Reviews auf Quellcode-Änderungen. PRs, die nur Dokumentation betreffen, überspringen den Workflow, was API-Kosten spart. Der concurrency-Block bricht laufende Reviews ab, wenn ein neuer Commit in dieselbe PR gepusht wird, damit Sie nicht für die Analyse veralteten Codes bezahlen.

Die --allowedTools-Einschränkung ist eine Sicherheitsmaßnahme. Sie beschränkt Claude auf das Lesen von Diffs und das Veröffentlichen von Kommentaren. Claude kann keine Dateien ändern, keine beliebigen Befehle ausführen und nicht auf andere Repositories zugreifen.

Wie fügt man Gemini-Code-Review zum selben Repository hinzu?

Zwei Optionen für Gemini-Review: die Gemini Code Assist GitHub App (von Google verwaltet, kein YAML) oder die GitHub Action run-gemini-cli (selbst verwaltet, volle Kontrolle). Dieses Tutorial verwendet die GitHub Action, weil sie Kontrolle über den Prompt bietet und sich in den Quality-Gate-Workflow integriert.

Einen Gemini-API-Schlüssel erstellen

Erstellen Sie einen Schlüssel bei Google AI Studio. Fügen Sie ihn als Repository-Secret hinzu:

  • Name: GEMINI_API_KEY
  • Value: Ihr Gemini-API-Schlüssel

Für den Unternehmenseinsatz mit Vertex-AI-Authentifizierung lesen Sie die run-gemini-cli-Dokumentation zur Einrichtung von Workload Identity Federation.

Den Gemini-Workflow erstellen

Erstellen Sie .github/workflows/gemini-review.yml:

name: Gemini Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

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

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: google-github-actions/run-gemini-cli@main
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: |
            Review this pull request. Focus on:
            1. Code style: naming conventions, function length, complexity
            2. Documentation: missing docstrings, outdated comments, unclear variable names
            3. Test coverage: untested edge cases, missing assertions, test quality
            4. Maintainability: code duplication, tight coupling, violation of SOLID principles

            Skip security and logic analysis. Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Post your review as a single PR comment with structured sections.

Die run-gemini-cli-Action ist derzeit in der Beta-Phase, weshalb der Workflow auf @main verweist. Für den Produktionseinsatz pinnen Sie auf einen spezifischen Commit-SHA (z. B. @abc1234), um unerwartete Änderungen bei Updates des main-Branches zu vermeiden.

Warum zwei getrennte Workflows?

Claude und Gemini in separaten Workflow-Dateien auszuführen bedeutet, dass sie parallel laufen. Ein Fehler bei einem blockiert den anderen nicht. Sie können auch vorübergehend ein Modell deaktivieren, ohne den anderen Workflow zu berühren.

Die Rollentrennung ist beabsichtigt. Claude neigt dazu, Aufrufketten von oben nach unten zu verfolgen, und ist gut darin, Lücken in der Fehlerbehandlung und Sicherheitslücken zu erkennen. Gemini ist stark bei Codestil, Dokumentationsvollständigkeit und strukturellen Mustern. Überschneidungen sind normal. Übereinstimmung zwischen Modellen erhöht das Vertrauen in die Befunde.

Wie funktioniert Multi-Modell-Review mit Claude und Gemini zusammen?

Das obige Zwei-Workflow-Setup implementiert bereits Multi-Modell-Review. Beide Modelle analysieren dieselbe PR unabhängig und veröffentlichen separate Kommentare. Das ist das einfachste Muster und funktioniert gut für die meisten Teams.

Für Teams, die eine einheitliche Ansicht möchten, fügen Sie einen Aggregationsschritt hinzu. Dieser dritte Workflow läuft nach Abschluss beider Reviews und veröffentlicht eine kombinierte Zusammenfassung:

name: AI Review Summary

on:
  workflow_run:
    workflows: ["Claude Code Review", "Gemini Code Review"]
    types: [completed]

jobs:
  aggregate:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    permissions:
      pull-requests: write
      actions: read

    steps:
      - name: Collect review comments
        id: collect
        uses: actions/github-script@v7
        with:
          script: |
            const pr_number = context.payload.workflow_run.pull_requests[0]?.number;
            if (!pr_number) return;

            const comments = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
            });

            const aiComments = comments.data.filter(c =>
              c.body.includes('CRITICAL') ||
              c.body.includes('HIGH') ||
              c.body.includes('MEDIUM')
            );

            const critical = aiComments.filter(c => c.body.includes('CRITICAL')).length;
            const high = aiComments.filter(c => c.body.includes('HIGH')).length;

            const summary = `## AI Review Summary\n\n` +
              `| Severity | Count |\n|----------|-------|\n` +
              `| CRITICAL | ${critical} |\n` +
              `| HIGH | ${high} |\n\n` +
              (critical > 0 ? '⛔ **Merge blocked:** Critical findings require human review.\n' :
               high > 0 ? '⚠️ High-severity findings detected. Review recommended before merge.\n' :
               '✅ No critical or high-severity findings.\n');

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
              body: summary,
            });

            core.setOutput('critical_count', critical);

      - name: Set status check
        if: steps.collect.outputs.critical_count > 0
        run: exit 1

Das ist ein Ausgangspunkt. Passen Sie die Kommentar-Parsing-Logik an das exakte Format an, das Ihre Prompts erzeugen. Die Severity-Schlüsselwörter (CRITICAL, HIGH, MEDIUM) in den Review-Prompts machen das Parsing unkompliziert.

Wie blockiert man Merges, wenn die KI-Review kritische Probleme findet?

Der obige Aggregations-Workflow setzt Exit-Code 1, wenn kritische Befunde vorliegen. Um daraus einen Merge-Blocker zu machen, konfigurieren Sie den Branch-Schutz:

  1. Gehen Sie zu Settings > Branches > Branch protection rules
  2. Wählen oder erstellen Sie eine Regel für Ihren Hauptbranch
  3. Aktivieren Sie Require status checks to pass before merging
  4. Suchen und fügen Sie „AI Review Summary" als erforderlichen Status Check hinzu
Severity Aktion Merge blockiert?
CRITICAL Status Check schlägt fehl Ja
HIGH Warnung in der Zusammenfassung Nein (beratend)
MEDIUM In Zusammenfassung aufgeführt Nein
LOW Aus Zusammenfassung ausgelassen Nein

Ein Wort der Vorsicht: KI-Reviewer erzeugen False Positives. Wenn Sie den Status Check als Pflicht einrichten, müssen Entwickler gelegentlich falsche Befunde verwerfen. Behalten Sie CRITICAL als einzige blockierende Severity bei. Wenn Sie auch bei HIGH blockieren, rechnen Sie mit Reibung.

Um einen blockierten Merge zu umgehen, kann ein Maintainer den Admin-Bypass der Branch-Schutzregel verwenden, oder Sie fügen einen /dismiss-ai-review-Kommentar-Handler hinzu, der den Summary-Workflow mit einem Force-Pass-Flag neu startet.

Wie reduziert man False Positives bei KI-Code-Review?

False Positives sind die häufigste Beschwerde von Teams, die KI-Code-Review einsetzen. Laute Reviews untergraben das Vertrauen schnell. Drei Techniken helfen.

Den Prompt eng fassen

Die obigen Prompts tun dies bereits: Claude analysiert Sicherheit und Logik, Gemini analysiert Stil und Dokumentation. Ein Modell, das „alles analysieren" soll, erzeugt mehr Rauschen als eines mit einem spezifischen Auftrag.

Fügen Sie projektspezifischen Kontext hinzu, um False Positives weiter zu reduzieren. Erstellen Sie eine CLAUDE.md-Datei im Wurzelverzeichnis Ihres Repositorys (Claude Code Action liest diese automatisch):

# Project Context

This is a Django REST API. Python 3.12. PostgreSQL.

## Review Guidelines
- We use `rest_framework.exceptions` for all error handling. Do not flag bare `except` blocks in middleware.
- `settings.py` contains environment variable references, not hardcoded secrets. Do not flag `os.environ.get()` calls.
- We intentionally use `Any` type hints in the serializer layer. Do not flag these.
- Test files use `pytest` fixtures. Do not flag unused function parameters in test files.

Für Gemini erstellen Sie eine GEMINI.md-Datei im Wurzelverzeichnis des Repositorys mit gleichwertigem Projektkontext.

Dateien filtern

Die paths- und paths-ignore-Filter im Workflow-YAML verhindern Reviews von Dateien, die Rauschen erzeugen:

paths-ignore:
  - "**/*.md"
  - "**/*.txt"
  - "**/*.lock"
  - "**/*.generated.*"
  - "migrations/**"
  - "vendor/**"
  - "dist/**"
  - "__snapshots__/**"

Lock-Dateien, generierter Code, gebündelte Abhängigkeiten und Migrationsdateien erzeugen False Positives, weil sie maschinell erstellt sind oder Muster folgen, die das Modell im Kontext nicht versteht.

Einen Severity-Schwellenwert festlegen

Wenn Sie nur CRITICAL- und HIGH-Befunde in der Zusammenfassung anzeigen, erreichen MEDIUM- und LOW-Rauschen den Entwickler nie. Das ist ein besserer Standard als alles anzuzeigen und Entwickler zu bitten, das Rauschen zu ignorieren.

Welche Sicherheitsrisiken birgt KI-Code-Review bei Pull Requests?

KI-Code-Reviewer verarbeiten nicht vertrauenswürdige Eingaben. Der PR-Diff, Commit-Nachrichten, Issue-Titel und Dateiinhalte werden in Open-Source-Repositories oder bei externen Beiträgen vom Angreifer kontrolliert. Das erzeugt ein Prompt-Injection-Risiko.

Der Clinejection-Angriff

Im Februar 2026 nutzte ein Angreifer den Cline-Issue-Triage-Bot über indirekte Prompt Injection aus. Der Angriff war einfach: Ein bösartiger GitHub-Issue-Titel enthielt Anweisungen, die als Fehlermeldung getarnt waren. Der Workflow des KI-Agenten interpolierte den Issue-Titel direkt in den Prompt. Der Agent befolgte die injizierten Anweisungen, führte npm install für ein bösartiges Paket aus und schleuste den ANTHROPIC_API_KEY aus der CI-Umgebung heraus.

Der Angriff kompromittierte etwa 4.000 Entwicklermaschinen, bevor das bösartige Paket entfernt wurde.

Ihre Workflows absichern

Werkzeugberechtigungen einschränken. Das --allowedTools-Flag im obigen Claude-Workflow begrenzt, was Claude tun kann. Es kann Diffs lesen und Kommentare veröffentlichen. Es kann keine beliebigen Shell-Befehle ausführen, keine Dateien schreiben und nicht auf Secrets zugreifen. Das ist die wirksamste Gegenmaßnahme.

claude_args: |
  --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Ohne diese Einschränkung könnte ein manipulierter PR-Diff Claude anweisen, Befehle auf dem Runner auszuführen.

Interpolieren Sie niemals nicht vertrauenswürdige Eingaben in Prompts. Verwenden Sie nicht ${{ github.event.issue.title }} oder ${{ github.event.pull_request.body }} im prompt-Feld. Übergeben Sie Repository und PR-Nummer und lassen Sie die Action den Inhalt über die GitHub-API abrufen.

Gehen Sie mit Fork-PRs vorsichtig um. Fork-PRs laufen standardmäßig mit eingeschränkten GITHUB_TOKEN-Berechtigungen, aber Ihre Secrets sind weiterhin für den Workflow verfügbar, wenn er durch pull_request_target ausgelöst wird. Verwenden Sie pull_request (nicht pull_request_target) für KI-Review-Workflows. Fork-PRs können dann nicht auf Ihre API-Schlüssel zugreifen und die Review wird nicht ausgeführt, was das sichere Standardverhalten ist.

on:
  pull_request:        # Safe: fork PRs cannot access secrets
    types: [opened, synchronize]
  # pull_request_target:  # Dangerous: fork PRs CAN access secrets

Rotieren Sie Ihre API-Schlüssel. Wenn ein Schlüssel über ein CI-Log oder einen kompromittierten Runner offengelegt wird, ist der Schadensradius auf die Zeit zwischen den Rotationen begrenzt. Rotieren Sie mindestens vierteljährlich.

Prüfen Sie Workflow-Ausführungen. Kontrollieren Sie den Actions-Tab regelmäßig auf ungewöhnliche Laufzeiten oder unerwartete Werkzeugaufrufe. Eine Review, die 45 Minuten statt der üblichen 3 Minuten dauert, kann darauf hindeuten, dass das Modell manipuliert wird.

Was kostet KI-Code-Review pro Pull Request?

Die Kosten skalieren mit der PR-Größe. Sowohl Claude als auch Gemini rechnen pro verarbeitetem Token ab. Die Eingabe-Token umfassen den PR-Diff, den Dateikontext und Ihren Prompt. Die Ausgabe-Token sind die Review-Kommentare.

PR-Größe Typischer Diff (Zeilen) Geschätzte Eingabe-Token
Klein 50–100 2.000–5.000
Mittel 200–500 8.000–20.000
Groß 500–1.500 20.000–60.000

Die Token-Anzahl variiert je nach Sprache. Ein 200-Zeilen-Python-Diff verbraucht weniger Token als ein 200-Zeilen-Java-Diff, weil Java ausführlicher ist.

Zwei Modelle zu verwenden verdoppelt die Token-Kosten, aber nicht die Euro-Kosten, da die Preisgestaltung zwischen Anbietern variiert. Prüfen Sie die aktuellen Pro-Token-Tarife auf der Anthropic-Preisseite und der Google-AI-Preisseite. Beide verwenden eine Pro-Token-Abrechnung mit unterschiedlichen Tarifen für Eingabe- und Ausgabe-Token.

Um Ihr Monatsbudget zu schätzen: Multiplizieren Sie die durchschnittliche PR-Größe (in Token) mit der Anzahl der PRs pro Monat, dann multiplizieren Sie mit dem Pro-Token-Tarif für jedes Modell. Ein Team, das 50 PRs pro Woche mit mittelgroßen Diffs mergt, kann berechnen:

weekly_cost = 50 * avg_tokens_per_pr * (claude_input_rate + gemini_input_rate)
              + 50 * avg_output_tokens * (claude_output_rate + gemini_output_rate)

Kosten reduzieren

  • Pfadfilter verhindern Reviews von Docs, Lock-Dateien und generiertem Code. Das ist die größte Kosteneinsparung.
  • Concurrency-Abbruch stoppt die Analyse veralteter Commits, wenn ein neuer Push eintrifft.
  • Draft-PRs überspringen, indem Sie ready_for_review nicht in Ihre Trigger-Typen aufnehmen und es nur hinzufügen, wenn Sie Reviews bei Draft-zu-Ready-Übergängen möchten.
  • Kleinere Modelle für Stil-Review verwenden. Gemini Flash ist günstiger als Gemini Pro für Stil- und Dokumentationsprüfungen, bei denen tiefes Reasoning nicht nötig ist.

Vergleich: KI-Code-Review-Werkzeuge

Merkmal Claude Code Action Gemini Code Assist CodeRabbit GitHub Copilot
Einrichtungsmethode GitHub Action (YAML) GitHub App oder Action GitHub App Integriert
Preismodell Pro Token (API) Pro Token oder Gratiskontingent Abo pro Repository Abo pro Arbeitsplatz
Inline-Kommentare Ja Ja Ja Ja
Eigene Prompts Volle Kontrolle Volle Kontrolle (Action) Konfigdatei Eingeschränkt
Selbstgehosteter Runner Ja Ja (Action) Nein Nein
Multi-Modell-Unterstützung Kombinierbar Kombinierbar Einzelmodell Einzelmodell
Open Source Ja (MIT) Ja (Action) Nein Nein

Claude Code Action und die Gemini-CLI-Action sind Open Source und laufen auf Ihren eigenen Runnern. Ihr Code verlässt nie Ihre Infrastruktur, außer für den API-Aufruf an den Modellanbieter. CodeRabbit und Copilot sind verwaltete Dienste, bei denen der Code auf deren Infrastruktur verarbeitet wird.

Was sind die Grenzen von KI-Code-Review?

KI-Code-Review ersetzt keine menschliche Review. Sie ist ein erster Durchgang, der häufige Probleme erkennt und menschliche Reviewer entlastet, damit sie sich auf Architektur, Design und Geschäftslogik-Entscheidungen konzentrieren können.

Kontextfenster-Grenzen. Große PRs (über 1.500 geänderte Zeilen) können das Kontextfenster des Modells überschreiten oder oberflächliche Reviews erzeugen, weil das Modell nicht den gesamten Diff im Kontext halten kann. Teilen Sie große PRs in kleinere auf. Das ist unabhängig von KI-Review eine gute Praxis.

Kein Laufzeit-Verständnis. KI-Reviewer sehen statischen Code. Sie können keine Probleme erkennen, die sich nur zur Laufzeit zeigen: Speicherlecks unter Last, timing-abhängige Race Conditions oder Leistungseinbußen bei großer Skalierung.

False Positives sind unvermeidlich. Selbst mit eng gefassten Prompts und Projektkontextdateien werden Modelle korrekten Code beanstanden. Rechnen Sie mit 10–20 % False Positives bei den Befunden. Wenn die Rate höher ist, verschärfen Sie Ihre Prompts und fügen Sie mehr Kontext zu CLAUDE.md oder GEMINI.md hinzu.

Kein institutionelles Wissen. Das Modell kennt die ungeschriebenen Konventionen Ihres Teams, historische Entscheidungen oder domänenspezifische Muster nicht, sofern Sie diese nicht in den Kontextdateien dokumentieren. Investieren Sie Zeit in gute CLAUDE.md- und GEMINI.md-Dateien. Diese Investition zahlt sich bei jeder zukünftigen Review aus.

Determinismus. Dieselbe PR kann bei zweimaliger Analyse unterschiedliche Befunde erzeugen. KI-Review ist probabilistisch. Behandeln Sie „keine Befunde" nicht als „keine Bugs".

Fehlerbehebung

Der Claude-Review-Workflow wird nie ausgelöst. Prüfen Sie den paths-Filter. Wenn Ihr Quellcode außerhalb von src/, lib/ oder app/ liegt, passen Sie die Pfade an Ihre Projektstruktur an. Überprüfen Sie auch, ob die Claude GitHub App im Repository installiert ist.

Gemini liefert leere Reviews. Bestätigen Sie, dass das GEMINI_API_KEY-Secret gesetzt ist und der Schlüssel gültig ist. Testen Sie ihn lokal:

curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_KEY" | head -20

Wenn Sie eine Liste von Modellen sehen, funktioniert der Schlüssel.

Reviews dauern zu lange. Die Einstellung timeout-minutes: 15 beendet den Workflow, wenn er 15 Minuten überschreitet. Große PRs mit über 1.000 Zeilen können 5–10 Minuten dauern. Wenn Timeouts häufig auftreten, verschärfen Sie den paths-Filter, um die Diff-Größe zu reduzieren.

Zu viele False Positives. Fügen Sie Projektkontext zu CLAUDE.md und GEMINI.md hinzu. Seien Sie spezifisch bei Mustern, die das Modell ignorieren soll. „Nicht X melden" ist wirksamer als „sei nachsichtig".

Status Check bleibt ausstehend. Der Aggregations-Workflow wird bei workflow_run-Abschluss ausgelöst. Wenn einer der beiden Review-Workflows übersprungen wird (weil keine passenden Dateien geändert wurden), wird die Aggregation möglicherweise nicht ausgelöst. Fügen Sie dem Aggregations-Workflow einen paths-Filter hinzu, der die Vereinigung beider Review-Workflows abdeckt, oder verwenden Sie einen separaten Status Check, der immer ausgeführt wird.

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD. →