Der Reviewer, der sich selbst reviewte

Der Pull Request, mit dem wir unseren KI-Code-Review-Workflow deployt haben, wurde vom KI-Code-Review-Workflow selbst reviewt.

Geplant war das nicht. Es hat sich einfach so gefügt: Der Reviewer lief bereits im Shared-Workflows-Monorepo, als wir den PR im Service-Repo geöffnet haben, um ihn anzubinden. Der Reviewer lief automatisch. Der Code, den er analysierte, war der Caller, der ihn selbst aufgerufen hatte — ein Loop, so sauber, dass er fast inszeniert wirkte.

Er war es nicht. Und was er fand, war nicht trivial.

---

Zwei Workflows, ein Prinzip

Das System hat auf oberster Ebene eine klare Trennung.

Der Reviewer läuft automatisch auf jedem Pull Request. Read-only. Strukturiertes Scoring in vier Dimensionen — Architektur, Testabdeckung, Sicherheit, Wartbarkeit — jede bewertet von 1 bis 10 mit konkreten Befunden. Er checkt den PR-Head aus, analysiert den Diff und postet einen Kommentar. Kein Schreibzugriff. Keine Secrets außer dem, was der Review selbst braucht.

Der Assistent läuft auf Anfrage. Erwähne @claude in einem PR-Kommentar, und er liest den Thread, analysiert den Code und kann Fixes direkt pushen. Write-enabled. Das ist der mächtige — und der gefährliche, wenn er nicht sauber abgegrenzt ist. Die Workflow-Struktur ist fast identisch mit der des Reviewers: gleiches Reusable-Pattern, gleicher schlanker Caller. Die Unterschiede liegen im Trigger (issue_comment statt pull_request), einem freien Prompt statt eines strukturierten Scoring-Templates und Schreibrechten statt Read-only.

Beide leben als Reusable Workflows in einem zentralen Monorepo. Jedes Service-Repo hat einen schlanken Caller — ein paar Zeilen, die den Shared Workflow aufrufen und auf eine repo-spezifische Prompt-Datei verweisen. Der Prompt enthält Team-Konventionen: zu prüfende Muster, Mindestwerte für Testabdeckung, verwendete Libraries. Fehlt im Caller-Repo eine Prompt-Datei, holt sich der Workflow einen Default. Einfach, komponierbar, konsistent.

Der Reusable Workflow im zentralen Monorepo (bereits mit den Fixes aus Runde eins und zwei — dazu gleich mehr):

# shared-workflows/.github/workflows/ai-code-review.yml
# Prerequisite: ANTHROPIC_API_KEY set as a repository secret.
name: AI Code Review

on:
  workflow_call:
    inputs:
      head_sha:
        required: true
        type: string
      pr_number:
        required: true
        type: string
  pull_request:              # also works standalone, not only as a reusable workflow
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: true

jobs:
  claude-code-review:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - name: Resolve PR context
        id: pr-context
        run: |
          # inputs.* set when called via workflow_call
          # github.event.pull_request.* set when triggered directly as pull_request
          HEAD_SHA="${{ inputs.head_sha || github.event.pull_request.head.sha }}"
          PR_NUMBER="${{ inputs.pr_number || github.event.pull_request.number }}"
          if [ -z "$HEAD_SHA" ] || [ -z "$PR_NUMBER" ]; then
            echo "Error: could not resolve PR context. Pass head_sha and pr_number when calling via workflow_call."
            exit 1
          fi
          echo "head_sha=$HEAD_SHA" >> "$GITHUB_OUTPUT"
          echo "pr_number=$PR_NUMBER" >> "$GITHUB_OUTPUT"

      - uses: actions/checkout@v4
        with:
          ref: ${{ steps.pr-context.outputs.head_sha }}  # PR head so Claude can read source files

      - name: Load review prompt
        id: prompt
        run: |
          # Base prompt lives in the shared-workflows repo.
          # Local copy used when this workflow runs on itself; API fetch used from service repos.
          if [ -f .claude/prompts/code-review.md ]; then
            BASE=$(cat .claude/prompts/code-review.md)
          else
            BASE=$(gh api repos/my-org/shared-workflows/contents/.claude/prompts/code-review.md \
              --jq '.content' | base64 -d) || { echo "Error: failed to fetch base prompt"; exit 1; }
          # base64 -d is GNU/Linux (works on ubuntu-latest); macOS uses -D
          fi
          [ -z "$BASE" ] && { echo "Error: base prompt is empty — refusing to run"; exit 1; }

          # Append repo-specific rules if the calling repo provides them
          RULES=""
          [ -f .claude/prompts/code-review-rules.md ] && RULES=$(cat .claude/prompts/code-review-rules.md)

          # Use a random delimiter to avoid collision if the prompt contains a literal "EOF"
          DELIM=$(openssl rand -hex 8)
          echo "PROMPT_CONTENT<<$DELIM" >> $GITHUB_OUTPUT
          printf '%s\n\n%s' "$BASE" "$RULES" >> $GITHUB_OUTPUT
          echo "$DELIM" >> $GITHUB_OUTPUT
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - uses: oven-sh/setup-bun@v2  # claude-code-action requires Bun at runtime

      - uses: anthropics/claude-code-action@v1.0.89
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ steps.pr-context.outputs.pr_number }}

            ${{ steps.prompt.outputs.PROMPT_CONTENT }}
          base_branch: main
          claude_args: |
            --allowedTools "Read,Grep,Glob,Bash(git log:*),Bash(gh pr diff:*),mcp__github__get_pull_request,mcp__github__create_and_submit_pull_request_review"

Der Caller im Service-Repo:

# my-service/.github/workflows/code-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-code-review:
    uses: my-org/shared-workflows/.github/workflows/ai-code-review.yml@main
    with:
      head_sha: ${{ github.event.pull_request.head.sha }}
      pr_number: "${{ github.event.pull_request.number }}"
    secrets: inherit

Der Caller hat dreizehn Zeilen. Die gesamte Logik liegt im Shared Workflow. Um ein neues Service-Repo anzubinden: Caller hinzufügen, optional .claude/prompts/code-review-rules.md mit team-spezifischen Konventionen anlegen, fertig.

Der PR, den wir geöffnet haben, hat genau diesen Caller in ein Frontend-Service-Repo eingefügt. Fünf Minuten Arbeit. Der Reviewer lief sofort.

---

Runde eins: Der stille Fehler

Der Reviewer hat die Fallback-Prompt-Logik bemängelt.

Hatte das Caller-Repo keine Prompt-Datei, holte sich der Workflow einen Default aus dem zentralen Monorepo. Aber wenn dieser Fetch leer zurückkam — falscher Pfad, kurzer Netzwerkausfall, was auch immer — lief der Workflow ohne Fehlermeldung weiter. Die KI bekam einen leeren Prompt-String. Sie lieferte trotzdem einen Review: höflich, vage, nutzlos. Kein Fehler. Kein Hinweis, dass etwas schiefgelaufen war. Keine Möglichkeit für jemanden, der den Kommentar las, zu erkennen, dass der Review gar nicht richtig gelaufen war.

Fix: Den Prompt validieren, bevor er gesendet wird. Ist er leer, sofort mit einer aussagekräftigen Fehlermeldung abbrechen. Der Workflow soll laut scheitern, nicht still.

Ein einfaches Versehen, leicht zu übersehen, wenn man nur den Happy Path im Blick hat. Der Reviewer hat es in Runde eins gefunden.

---

Runde zwei: Der Kontext, der nicht da war

Zweiter Review, nach den Fixes aus Runde eins.

Diesmal hat der Reviewer einen strukturellen Bug in der Art bemängelt, wie der Reusable Workflow mit dem GitHub-Event-Kontext umging.

Wenn ein Workflow via workflow_call aufgerufen wird — dem Mechanismus, der ihn über Repos hinweg wiederverwendbar macht —, werden die Event-Daten des aufrufenden Workflows nicht weitergegeben. github.event_name wird zu 'workflow_call', nicht 'pull_request'. github.event.pull_request ist null. Jede Job-Bedingung, die github.event_name == 'pull_request' prüft, wertet stillschweigend zu false aus — der Schritt wird einfach übersprungen.

Die PR-Nummer und der Head-SHA — nötig, um den Review-Kommentar an die richtige Stelle zu posten — waren im Reusable Workflow nicht verfügbar. Der Caller musste sie explizit als Workflow-Inputs übergeben. Der Reusable Workflow musste diese Inputs entgegennehmen und verwenden, anstatt sie aus dem GitHub-Kontext zu lesen, den er nicht mehr hatte.

Das Symptom wäre verwirrend gewesen: Der Workflow läuft, beendet sich erfolgreich, postet nichts. Man würde denken, der Review wurde übersprungen. Warum — keine Ahnung.

Der Reviewer hat das erkannt, indem er die Workflow-Definition gelesen und nachvollzogen hat, was unter einem workflow_call-Event passiert — nicht als Lint-Check, sondern als echtes Verständnis davon, wie Reusable Workflows in GitHub Actions funktionieren.

---

Runde drei: Die Sicherheitslücke

Dritter Review, nach den Kontext-Fixes.

Der Reviewer hat den Assistenten-Workflow bemängelt.

Dem Assistenten — dem mit Schreibzugriff — fehlte ein Fork-Guard.

Das Risiko: Der Assistent wird ausgelöst, wenn jemand @claude in einem PR-Kommentar erwähnt. Er hat Schreibzugriff — er kann Commits pushen. Würde er auf Fork-PRs ohne Einschränkung laufen, könnte ein Angreifer einen Fork-Pull-Request öffnen, einen @claude-Kommentar hinterlassen und damit einen Workflow auslösen, der seinen Code auscheckt und mit Schreibrechten auf das Ziel-Repository läuft. Der Fachbegriff für diese Angriffsklasse ist Pwn-Request. Er ist in der GitHub-Actions-Sicherheitsliteratur gut dokumentiert und ernst zu nehmen.

Der Fix ist eine einzige Bedingung:

if: github.event.pull_request.head.repo.full_name == github.repository

Eine Zeile. Sie verhindert die Ausführung auf Fork-PRs. Aber bis der Reviewer sie bemängelt hat, fehlte sie.

Ich bin mir nicht sicher, ob wir das im manuellen Review gefunden hätten. Reviewer und Assistent sehen auf den ersten Blick ähnlich aus — beide werden durch PR-Events ausgelöst, beide involvieren Claude. Man muss den Unterschied im Permission-Scope gleichzeitig mit dem Fork-Szenario im Kopf haben, um das Risiko zu sehen. Der KI-Reviewer hatte beides.

---

Was dieser Loop wirklich bedeutet

Der beste Test dafür, ob ein Code-Review-Workflow funktioniert, ist, ob er die eigene Codequalität verbessert. Hätte der Reviewer keine Probleme im Code gefunden, der definiert, wie er selbst läuft, wäre der Code entweder fehlerfrei gewesen (unwahrscheinlich) oder der Reviewer hätte nicht funktioniert (hier ebenfalls unwahrscheinlich). Er hat drei Probleme gefunden.

Wer KI-gestützte Pipelines baut, sollte die KI zum ersten Nutzer ihres eigenen Outputs machen. Nicht als Gimmick. Als Quality Gate. Wenn der Code-Review-Workflow eine Sicherheitslücke im eigenen Deployment-PR findet, bevor ein Mensch draufschaut, leistet die Pipeline bereits mehr als die meisten manuellen Review-Prozesse.

Etwas anderes hat der Reviewer angefangen zu tun, ohne dass wir ihn darum gebeten hätten: Bei normalen PRs hat er manchmal darauf hingewiesen, dass ein anderer offener Pull Request denselben Bereich der Codebase berührt. Würden beide mergen, gäbe es einen Konflikt — nicht beim Review, sondern in QA, wo Konflikte teuer sind und die beteiligten Teams gedanklich längst weitergezogen sind. Der Reviewer hat die Überschneidung bemerkt, bevor einer der PRs gemergt wurde. Das Gespräch zwischen den Teams fand statt, bevor der Code kollidierte.

Niemand hat ihm gesagt, er solle andere offene PRs im Blick behalten. Das macht ein gründlicher Reviewer eben — er liest den aktuellen Diff nicht isoliert, sondern denkt mit, was gerade noch in Arbeit ist. Der Unterschied: Ein menschlicher Reviewer muss die parallele Arbeit bereits kennen, um sie zu erwähnen. Der Reviewer hat nachgeschaut.

---

Was nicht reibungslos lief

Ein Problem, das der Reviewer nicht erkennen konnte: eine Kompatibilitäts-Regression in der zugrunde liegenden GitHub Action.

Eine neuere Version der claude-code-action hatte via oven-sh/setup-bun eine Abhängigkeit von Bun — einer JavaScript-Runtime — eingeführt. In einer GitHub-Enterprise-Umgebung ruft diese Setup-Action api.github.com auf, nicht den Enterprise-GitHub-Host. Enterprise-Credentials funktionieren dort nicht. Die Action schlägt mit einem 401 fehl, bevor sie irgendetwas tut.

Der Reviewer hat einige Konfigurationsbedenken rund um die Action-Version gemeldet, konnte das Upstream-Dependency-Problem aber nicht identifizieren — dafür hätte er Zugriff auf den Quellcode der Action gebraucht. Dieses Problem haben wir in Produktion entdeckt. Fix: auf eine ältere Version pinnen, die noch keine Bun-Abhängigkeit hat.

Das ist der ehrliche Teil. Der Loop hat bei Logik-Bugs und Sicherheits-Blindstellen funktioniert. Umgebungs-Inkompatibilitäten, die upstream des eigenen Codes liegen — die erfordern nach wie vor, das Ding tatsächlich auszuführen.

---

Der Loop schließt sich

Geplant war nicht, dass der Reviewer auf dem eigenen Deployment-PR läuft. Beim nächsten Mal machen wir das absichtlich.

Der Fork-Guard, der Pwn-Request-Angriffe verhindert, war im Code, bevor ein Mensch den PR gelesen hat. Genauso die leere Prompt-Validierung und der workflow_call-Kontext-Fix. Drei Dinge, die kaputt in Produktion gegangen wären — gefunden im Review, von genau dem Ding, das deployt wurde.

Die Tools, die wir bauen, sollten zuerst auf sich selbst laufen.