GitHub PR-Reviews mit OpenClaw automatisieren

Was du bauen wirst

Eine vollautomatische PR-Review-Pipeline, die:

1. PRs erstellt — AI generiert aus deinem Commit-Verlauf eine saubere PR-Beschreibung
2. Code überprüft — KI-gestützte Analyse erkennt Bugs, Sicherheitslücken und Stilprobleme
3. Commits standardisiert — Conventional-Commits-Format wird durchgesetzt
4. Umsetzbares Feedback liefert — direkt als Inline-Kommentare im PR

Nach dieser Anleitung löst jeder neue PR automatisch eine KI-Review aus — ganz ohne manuelles Eingreifen.

Warum KI-gestützte PR-Reviews

Manuelles Code-Review ist unverzichtbar, hat aber in der Praxis klare Grenzen:

• Schwankende Qualität — Unterschiedliche Reviewer achten auf unterschiedliche Dinge. Die einen schauen auf Namenskonventionen, die anderen auf Fehlerbehandlung. Was gefunden wird, hängt davon ab, wer heute den PR reviewt.
• Review-Müdigkeit — Nach einigen Hundert Zeilen Code sinkt die Aufmerksamkeit deutlich. Studien zeigen, dass die Effektivität nach rund 60 Minuten spürbar nachlässt. Kritische Bugs verstecken sich oft am Ende großer Diffs.
• Lange Wartezeiten — Reviewer haben eigene Aufgaben. Ein PR kann Stunden oder sogar Tage warten. Das blockiert den Autor, fördert große gebündelte PRs und erzeugt Merge-Konflikte.
• Skalierungsprobleme — Je größer das Team, desto schlimmer der Review-Engpass. Senior-Entwickler verbringen immer mehr Zeit mit Reviews statt mit Entwicklung. Neue Teammitglieder kennen die Codebasis oft noch nicht gut genug.

KI-Review ersetzt menschliche Reviewer nicht — sie übernimmt die systematischen Prüfungen (Sicherheitsmuster, häufige Bugs, Stilverletzungen), damit sich Menschen auf Architektur, Design und Geschäftslogik konzentrieren können. Betrachte es als einen ersten Durchlauf, der die Basisqualität jedes PRs sicherstellt, bevor ein Mensch ihn überhaupt öffnet.

Voraussetzungen

Bevor du loslegst, stelle sicher, dass du Folgendes hast:

• OpenClaw installiert und konfiguriert (Erste-Schritte-Anleitung)
• GitHub CLI (gh) installiert und authentifiziert (gh auth login)
• Ein GitHub-Repository zum Testen (ein persönliches Projekt reicht)
• Node.js 18+

Schritt 1: Benötigte Skills installieren

Installiere alle drei Skills der Reihe nach:

# 1. GitHub-Integration (Grundlage)
npx clawhub@latest install github

# 2. PR Reviewer (Codeanalyse)
npx clawhub@latest install pr-reviewer

# 3. Conventional Commits (Commit-Formatierung)
npx clawhub@latest install conventional-commits

Installation überprüfen:

clawhub list

Alle drei Skills sollten als installed angezeigt werden.

Schritt 2: GitHub-Authentifizierung konfigurieren

Der GitHub-Skill braucht ein Personal Access Token mit folgenden Scopes:

• repo — vollständiger Repository-Zugriff
• read:org — Organisationsmitgliedschaft lesen (optional, für Organisations-Repos)

Falls du dich bereits mit gh auth login authentifiziert hast, verwendet der Skill deine vorhandenen Zugangsdaten. Andernfalls:

# Aktuellen Auth-Status prüfen
gh auth status

# Bei Bedarf einloggen
gh auth login

Schritt 3: PR Reviewer konfigurieren

Der PR Reviewer Skill funktioniert sofort nach der Installation, aber du kannst sein Verhalten anpassen:

# Standardkonfiguration anzeigen
clawhub inspect pr-reviewer

Wichtige Konfigurationsoptionen:

• Review-Tiefe: quick (oberflächlich) oder thorough (Tiefenanalyse)
• Schwerpunkte: Sicherheit, Performance, Stil, Bugs oder alles
• Auto-Kommentar: ob Kommentare direkt im PR gepostet werden

Schritt 4: Dein erstes automatisiertes PR-Review erstellen

Teste den Workflow mit einem echten PR:

4.1 Feature-Branch erstellen

git checkout -b feature/test-ai-review

4.2 Code ändern

Bearbeite eine Datei in deinem Projekt. Zum Testen kannst du bewusst typische Fehler einbauen, die der Reviewer erkennen soll:

Fehlender await (Async-Bug):

// Bug: fehlendes await beim asynchronen Aufruf
function getUserData(userId) {
  const response = fetch(`/api/users/${userId}`);  // await fehlt
  return response.json();  // TypeError: response.json is not a function
}

SQL-Injection-Schwachstelle:

# Sicherheit: Benutzereingabe direkt in SQL-Query eingebaut
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = '{user_id}'"  # SQL-Injection-Risiko
    return db.execute(query)

Hartcodierter Schlüssel:

// Sicherheit: API-Key im Quellcode sichtbar
const stripe = require('stripe')('sk_live_abc123secretkey');

N+1-Query-Problem:

# Performance: N+1 Query — pro Bestellung eine Datenbankabfrage
def get_orders_with_items(user_id):
    orders = Order.objects.filter(user_id=user_id)
    for order in orders:
        order.items = OrderItem.objects.filter(order_id=order.id)  # N+1!
    return orders

4.3 Mit Conventional Commits committen

Statt die Commit-Nachricht selbst zu schreiben, lässt du OpenClaw sie generieren:

git add .
# OpenClaw generiert eine Commit-Nachricht im Conventional-Commits-Format
# z. B. "feat(api): add getUserData function for user data retrieval"

4.4 PR erstellen und reviewen

# OpenClaw erstellt den PR mit KI-generierter Beschreibung
# PR Reviewer analysiert dann automatisch den Diff

Innerhalb von Sekunden siehst du:

• Eine sauber formatierte PR-Beschreibung, die deine Änderungen zusammenfasst
• Inline-Review-Kommentare zu konkreten Codezeilen
• Einen Zusammenfassungskommentar mit Gesamtbewertung und Verbesserungsvorschlägen

So sehen die KI-Review-Kommentare an deinem PR aus:

🔒 Sicherheitsproblem (Zeile 14, auth.py):
  Benutzereingabe wird direkt in den SQL-Query-String eingebaut.
  Das ist anfällig für SQL-Injection-Angriffe.
  Vorgeschlagene Lösung: Parameterisierte Queries verwenden.

  - query = f"SELECT * FROM users WHERE id = '{user_id}'"
  + query = "SELECT * FROM users WHERE id = %s"
  + return db.execute(query, (user_id,))

⚡ Performance-Problem (Zeile 8, orders.py):
  N+1 Query erkannt — OrderItem.objects.filter() wird innerhalb
  der Schleife pro Bestellung einmal aufgerufen. Verwende
  select_related() oder prefetch_related() für eine einzelne Abfrage.

  - orders = Order.objects.filter(user_id=user_id)
  + orders = Order.objects.filter(user_id=user_id).prefetch_related('items')

🐛 Bug (Zeile 3, api.js):
  fetch() gibt ein Promise zurück, aber await fehlt.
  response.json() wird fehlschlagen, weil response ein
  hängendes Promise ist, kein Response-Objekt.

  - const response = fetch(`/api/users/${userId}`);
  + const response = await fetch(`/api/users/${userId}`);

Schritt 5: Den Review-Workflow anpassen

Sicherheits-Fokus

Für sicherheitskritische Repositories kannst du den PR Reviewer auf Sicherheitsprüfungen fokussieren:

• SQL-Injection-Muster
• Hartcodierte Zugangsdaten oder API-Keys
• Unsichere Datenverarbeitung (unvalidierte Eingaben, fehlende Filterung)
• Schwachstellen in Abhängigkeiten
• Cross-Site Scripting (XSS) im Frontend-Code
• Unsichere Deserialisierungsmuster

Performance-Fokus

Für performancekritische Services lässt du den Reviewer auf Performance-Muster achten. Bei React-Projekten erkennt er zum Beispiel unnötige Re-Renders:

// Performance: Neue Objektreferenz bei jedem Render führt zu Re-Renders
function ParentComponent({ items }) {
  return (
    <ChildComponent
      style={{ margin: 10 }}        // Neues Objekt bei jedem Render
      onClick={() => doSomething()}  // Neue Funktion bei jedem Render
    />
  );
}

Teamweite Konfiguration

Die Konfiguration im gesamten Team teilen:

1. Exportiere deine Skill-Konfiguration in ein .openclaw/-Verzeichnis im Repo
2. Committe sie ins Repository
3. Teammitglieder installieren mit derselben Konfiguration — die Skills lesen automatisch die projektbezogene Konfiguration

Fortgeschritten: Review-Schwerpunkte steuern

Du kannst den Fokus der Review durch natürliche Sprache an den PR Reviewer Skill anpassen.

Sprachspezifische Ausrichtung

Teile dem Agent beim Starten einer Review mit, worauf er achten soll:

• Python: auf nackte except:-Blöcke prüfen, fehlende Type Hints, Django-ORM-N+1-Queries
• JavaScript/TypeScript: übrig gebliebene console.log markieren, fehlendes await bei async-Aufrufen, hartcodierte Secrets
• Rust: .unwrap() in Produktionscode markieren, saubere Result-Behandlung vorschlagen

Verzeichnisbasierte Konfiguration

Unterschiedliche Prüftiefe für verschiedene Verzeichnisse:

• Kern-Geschäftslogik (src/core/) — gründliche Review mit Fokus auf Sicherheit, Bugs und Performance
• Testdateien (src/tests/) — schneller Check auf Korrektheit
• Dokumentation (docs/) — leichte Stil-Review
• Skripte (scripts/) — Fokus auf Sicherheit und Bugs

Benutzerdefinierte Regeln

Lass den Reviewer projektspezifische Anti-Patterns markieren, zum Beispiel:

• Direkter Datenbankzugriff in API-Routen statt über die Repository-Schicht
• Seitenkomponenten ohne Error Boundary
• API-Endpunkte ohne Rate Limiting

Integration in CI/CD

Für vollständig automatisierte Reviews bei jedem PR integrierst du den PR Reviewer in deine CI/CD-Pipeline.

GitHub Actions

Erstelle eine Workflow-Datei unter .github/workflows/ai-review.yml:

name: AI PR Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install OpenClaw and skills
        run: |
          npm install -g clawhub@latest
          clawhub install pr-reviewer

      - name: Run AI Review
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENCLAW_API_KEY: ${{ secrets.OPENCLAW_API_KEY }}
        run: |
          clawhub run pr-reviewer \
            --pr ${{ github.event.pull_request.number }} \
            --repo ${{ github.repository }} \
            --auto-comment

Review-Auslöser steuern

Begrenze die KI-Review auf bestimmte Bedingungen, um Kosten zu sparen:

on:
  pull_request:
    types: [opened, synchronize]
    paths-ignore:
      - '*.md'
      - 'docs/**'
      - '.github/**'

Oder erfordere ein Label vor der Review:

- name: Check for review label
  if: contains(github.event.pull_request.labels.*.name, 'ai-review')
  run: clawhub run pr-reviewer --pr ${{ github.event.pull_request.number }}

Andere CI-Plattformen

Derselbe Ansatz funktioniert auf jeder CI-Plattform mit Node.js-Unterstützung. Die wesentlichen Schritte:

1. clawhub und den pr-reviewer Skill installieren
2. OPENCLAW_API_KEY als Umgebungsvariable setzen
3. PR-Nummer und Repository-Information übergeben
4. Sicherstellen, dass der CI-Bot Schreibrechte auf Pull Requests hat

Ergebnisse in der Praxis

Teams, die diesen Workflow nutzen, berichten typischerweise:

• 40 % schnellere PR-Bearbeitung — KI erkennt offensichtliche Probleme vor dem menschlichen Review
• Gleichbleibende Review-Qualität — jeder PR durchläuft dieselbe gründliche Analyse
• Bessere Commit-Historie — Conventional Commits machen Changelogs automatisch
• Weniger Bugs in Produktion — KI erkennt Probleme, die Menschen übersehen könnten

Fehlerbehebung

"GitHub CLI not found"

Stelle sicher, dass gh installiert und im PATH ist:

# macOS
brew install gh

# Linux
sudo apt install gh

# Windows
winget install GitHub.cli

"Permission denied" beim Erstellen eines PR

Prüfe deine Token-Scopes:

gh auth status

Stelle sicher, dass der repo-Scope enthalten ist. Bei Bedarf neu authentifizieren:

gh auth login --scopes repo

PR Reviewer kommentiert nicht

Überprüfe Installation und Konfiguration des Skills:

clawhub inspect pr-reviewer

Stelle sicher, dass dein OpenClaw-KI-Provider konfiguriert ist und verfügbares Guthaben hat.