Cursor – Code Review

In diesem Tutorial lernst du, wie du Code Reviews mit der Cursor-CLI in GitHub Actions einrichtest. Der Workflow analysiert Pull Requests, erkennt Probleme und postet Feedback als Kommentare.

Für die meisten Nutzer empfehlen wir stattdessen den Bugbot. Bugbot bietet verwaltete, automatisierte Code Reviews ohne Setup. Dieser CLI-Ansatz ist hilfreich, um die Möglichkeiten zu erkunden und für fortgeschrittene Anpassungen.

Show full workflow file

cursor-code-review.yml

name: Code-Review

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

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

jobs:
  code-review:
    runs-on: ubuntu-latest
    # Automatisierte Code-Reviews für Entwurfs-PRs überspringen
    if: github.event.pull_request.draft == false
    steps:
      - name: Repository auschecken
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}

      - name: Cursor-CLI installieren
        run: |
          curl https://cursor.com/install -fsS | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

      - name: Git-Identität konfigurieren
        run: |
          git config user.name "Cursor Agent"
          git config user.email "cursoragent@cursor.com"

      - name: Automatisiertes Code-Review ausführen
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
          MODEL: gpt-5
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BLOCKING_REVIEW: ${{ vars.BLOCKING_REVIEW || 'false' }}
        run: |
          cursor-agent --force --model "$MODEL" --output-format=text --print 'Du arbeitest in einem GitHub-Actions-Runner und führst ein automatisiertes Code-Review durch. Die gh-CLI ist verfügbar und über GH_TOKEN authentifiziert. Du darfst Kommentare zu Pull Requests hinterlassen.

          Kontext:
          - Repo: ${{ github.repository }}
          - PR Number: ${{ github.event.pull_request.number }}
          - PR Head SHA: ${{ github.event.pull_request.head.sha }}
          - PR Base SHA: ${{ github.event.pull_request.base.sha }}
          - Blockierendes Review: ${{ env.BLOCKING_REVIEW }}

          Ziele:
          1) Vorhandene Review-Kommentare erneut prüfen und mit „resolved“ antworten, wenn behoben.
          2) Den aktuellen PR-Diff prüfen und nur eindeutige, schwerwiegende Probleme markieren.
          3) Sehr kurze Inline-Kommentare (1–2 Sätze) nur zu geänderten Zeilen hinterlassen und am Ende eine kurze Zusammenfassung.

          Vorgehen:
          - Vorhandene Kommentare abrufen: gh pr view --json comments
          - Diff abrufen: gh pr diff
          - Geänderte Dateien mit Patches abrufen, um Inline-Positionen zu berechnen: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files --paginate --jq '.[] | {filename,patch}'
          - Exakte Inline-Anker für jedes Problem berechnen (Dateipfad + Diff-Position). Kommentare MÜSSEN inline auf der geänderten Zeile im Diff platziert werden, nicht als Top-Level-Kommentare.
          - Frühere Top-Level-Kommentare im Stil „keine Probleme“ erkennen, die von diesem Bot verfasst wurden (Texte wie: „✅ keine Probleme“, „Keine Probleme gefunden“, „LGTM“).
          - Falls der aktuelle Lauf Probleme findet und frühere „keine Probleme“-Kommentare existieren:
            - Möglichst entfernen, um Verwirrung zu vermeiden:
              - Versuche, Top-Level-Issue-Kommentare zu löschen via: gh api -X DELETE repos/${{ github.repository }}/issues/comments/<comment_id>
              - Falls Löschen nicht möglich ist, minimiere sie via GraphQL (minimizeComment) oder bearbeite sie und stelle „[Durch neue Erkenntnisse ersetzt]“ voran.
            - Falls weder Löschen noch Minimieren möglich ist, antworte auf diesen Kommentar: „⚠️ Ersetzt: In neueren Commits wurden Probleme gefunden“.
          - Wenn ein zuvor gemeldetes Problem durch nahe Änderungen behoben erscheint, antworte: ✅ Dieses Problem scheint durch die jüngsten Änderungen behoben zu sein
          - NUR analysieren:
            - Null-/undefined-Dereferenzierungen
            - Ressourcenlecks (nicht geschlossene Dateien oder Verbindungen)
            - Injection (SQL/XSS)
            - Nebenläufigkeit/Race-Conditions
            - Fehlende Fehlerbehandlung bei kritischen Operationen
            - Offensichtliche Logikfehler mit fehlerhaftem Verhalten
            - Klare Performance-Anti-Patterns mit messbarem Einfluss
            - Eindeutige Sicherheitslücken
          - Duplikate vermeiden: überspringen, wenn ähnliches Feedback bereits auf oder nahe derselben Zeile existiert.

          Kommentarregeln:
          - Maximal 10 Inline-Kommentare insgesamt; die kritischsten Probleme priorisieren
          - Ein Problem pro Kommentar; exakt auf der geänderten Zeile platzieren
          - Alle Problem-Kommentare MÜSSEN inline sein (an Datei und Zeile/Position im PR-Diff verankert)
          - Natürlicher Ton, konkret und umsetzbar; erwähne nicht „automatisiert“ oder „hohe Sicherheit“
          - Emojis verwenden: 🚨 Kritisch 🔒 Sicherheit ⚡ Performance ⚠️ Logik ✅ Behoben ✨ Verbesserung

          Abgabe:
          - Wenn es KEINE Probleme zu melden gibt und bereits ein vorhandener übergeordneter Kommentar mit dem Hinweis „keine Probleme“ existiert (z. B. „✅ keine Probleme“, „Keine Probleme gefunden“, „LGTM“), reiche KEINEN weiteren Kommentar ein. Überspringe die Abgabe, um Redundanz zu vermeiden.
          - Wenn es KEINE Probleme zu melden gibt und KEIN vorheriger „keine Probleme“-Kommentar existiert, reiche einen kurzen Zusammenfassungskommentar ein, der festhält, dass keine Probleme vorliegen.
          - Wenn es Probleme zu melden gibt und ein vorheriger „keine Probleme“-Kommentar existiert, stell sicher, dass der vorherige Kommentar gelöscht/minimiert/als überholt markiert wird, bevor du die neue Review einreichst.
          - Wenn es Probleme zu melden gibt, reiche EINE Review ein, die NUR Inline-Kommentare plus einen optionalen knappen Zusammenfassungstext enthält. Verwende die GitHub Reviews API, um sicherzustellen, dass Kommentare inline sind:
            - Erstelle ein JSON-Array von Kommentaren wie: [{ "path": "<file>", "position": <diff_position>, "body": "..." }]
            - Reiche ein über: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/reviews -f event=COMMENT -f body="$SUMMARY" -f comments='[$COMMENTS_JSON]'
          - Nicht verwenden: gh pr review --approve oder --request-changes

          Blockierverhalten:
          - Wenn BLOCKING_REVIEW true ist und irgendwelche 🚨- oder 🔒-Probleme gepostet wurden: echo "CRITICAL_ISSUES_FOUND=true" >> $GITHUB_ENV
          - Andernfalls: echo "CRITICAL_ISSUES_FOUND=false" >> $GITHUB_ENV
          - Setze CRITICAL_ISSUES_FOUND immer am Ende
          '

      - name: Check blocking review results
        if: env.BLOCKING_REVIEW == 'true'
        run: |
          echo "Prüfe auf kritische Probleme..."
          echo "CRITICAL_ISSUES_FOUND: ${CRITICAL_ISSUES_FOUND:-nicht gesetzt}"

          if [ "${CRITICAL_ISSUES_FOUND:-false}" = "true" ]; then
            echo "❌ Kritische Probleme gefunden und blockierende Review ist aktiviert. Der Workflow wird fehlgeschlagen."
            exit 1
          else
            echo "✅ Keine blockierenden Probleme gefunden."
          fi

Automatisiertes Code-Review in Aktion mit Inline-Kommentaren in einem Pull Request

Authentifizierung konfigurieren

Richte deinen API-Schlüssel und deine Repository-Secrets ein, um die Cursor-CLI in GitHub Actions zu authentifizieren.

Agent-Berechtigungen einrichten

Erstell eine Konfigurationsdatei, um zu steuern, welche Aktionen der Agent ausführen darf. Das verhindert unbeabsichtigte Aktionen wie das Pushen von Code oder das Erstellen von Pull Requests. Erstell .cursor/cli.json im Root deines Repos:

{
  "permissions": {
    "deny": [
      "Shell(git push)",
      "Shell(gh pr create)",
      "Write(**)"
    ]
  }
}

Diese Konfiguration erlaubt dem Agenten, Dateien zu lesen und die GitHub-CLI für Kommentare zu verwenden, verhindert aber, dass er Änderungen an deinem Repository vornimmt. Sieh dir die Berechtigungsreferenz für weitere Konfigurationsoptionen an.

GitHub-Actions-Workflow erstellen

Lass uns den Workflow jetzt Schritt für Schritt aufbauen.

Workflow-Trigger einrichten

Erstelle .github/workflows/cursor-code-review.yml und konfiguriere ihn so, dass er bei Pull Requests läuft:

name: Cursor Code Review

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

jobs:
  code-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:

Repository auschecken

Füge den Checkout-Schritt hinzu, um auf den Pull-Request-Code zuzugreifen:

- name: Checkout repository
  uses: actions/checkout@v4
  with:
    fetch-depth: 0
    ref: ${{ github.event.pull_request.head.sha }}

Cursor CLI installieren

Füge den Installationsschritt für die CLI hinzu:

- name: Install Cursor CLI
  run: |
    curl https://cursor.com/install -fsS | bash
    echo "$HOME/.cursor/bin" >> $GITHUB_PATH

Review-Agent konfigurieren

Bevor wir den vollständigen Review-Schritt implementieren, lass uns die Anatomie unseres Review-Prompts verstehen. Dieser Abschnitt beschreibt, wie sich der Agent verhalten soll: Ziel: Wir wollen, dass der Agent den aktuellen PR-Diff prüft und nur eindeutige, schwerwiegende Probleme markiert, dann sehr kurze Inline-Kommentare (1–2 Sätze) ausschließlich auf geänderten Zeilen hinterlässt, mit einer kurzen Zusammenfassung am Ende. So bleibt das Signal-Rausch-Verhältnis ausgewogen. Format: Wir möchten Kommentare, die kurz und auf den Punkt sind. Wir verwenden Emojis, um das Scannen zu erleichtern, und wir wollen am Ende eine High-Level-Zusammenfassung des gesamten Reviews. Abgabe: Wenn der Review abgeschlossen ist, soll der Agent einen kurzen Kommentar basierend auf den Befunden einfügen. Der Agent soll einen Review einreichen, der Inline-Kommentare plus eine prägnante Zusammenfassung enthält. Randfälle: Wir müssen Folgendes handhaben:

Vorhandene Kommentare werden aufgelöst: Der Agent soll sie als erledigt markieren, wenn sie adressiert wurden
Duplikate vermeiden: Der Agent soll das Kommentieren überspringen, wenn ähnliches Feedback bereits auf oder nahe derselben Zeile existiert

Finaler Prompt: Der vollständige Prompt kombiniert all diese Verhaltensanforderungen, um fokussiertes, umsetzbares Feedback zu erzeugen Jetzt implementieren wir den Schritt für den Review-Agent:

- name: Perform code review
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
    GH_TOKEN: ${{ github.token }}
  run: |
    cursor-agent --force --model "$MODEL" --output-format=text --print "You are operating in a GitHub Actions runner performing automated code review. The gh CLI is available and authenticated via GH_TOKEN. You may comment on pull requests.
    
    Context:
    - Repo: ${{ github.repository }}
    - PR Number: ${{ github.event.pull_request.number }}
    - PR Head SHA: ${{ github.event.pull_request.head.sha }}
    - PR Base SHA: ${{ github.event.pull_request.base.sha }}
    
    Objectives:
    1) Re-check existing review comments and reply resolved when addressed
    2) Review the current PR diff and flag only clear, high-severity issues
    3) Leave very short inline comments (1-2 sentences) on changed lines only and a brief summary at the end
    
    Procedure:
    - Get existing comments: gh pr view --json comments
    - Get diff: gh pr diff
    - If a previously reported issue appears fixed by nearby changes, reply: ✅ This issue appears to be resolved by the recent changes
    - Avoid duplicates: skip if similar feedback already exists on or near the same lines
    
    Commenting rules:
    - Max 10 inline comments total; prioritize the most critical issues
    - One issue per comment; place on the exact changed line
    - Natural tone, specific and actionable; do not mention automated or high-confidence
    - Use emojis: 🚨 Critical 🔒 Security ⚡ Performance ⚠️ Logic ✅ Resolved ✨ Improvement
    
    Submission:
    - Submit one review containing inline comments plus a concise summary
    - Use only: gh pr review --comment
    - Do not use: gh pr review --approve or --request-changes"

.
├── .cursor/
│   └── cli.json
├── .github/
│   └── workflows/
│       └── cursor-code-review.yml

Teste deinen Reviewer

Erstell einen Test-Pull-Request, um zu prüfen, dass der Workflow funktioniert und der Agent Review-Kommentare mit Emoji-Feedback postet.

Pull Request mit automatisierten Review-Kommentaren, Emojis und Inline-Feedback zu bestimmten Zeilen

Nächste Schritte

Du hast jetzt ein funktionierendes automatisiertes Code-Review-System. Überleg dir diese Verbesserungen:

Richte zusätzliche Workflows zum Beheben von CI-Fehlern ein
Konfiguriere unterschiedliche Review-Level für verschiedene Branches
Integriere das System in den bestehenden Code-Review-Prozess deines Teams
Passe das Verhalten des Agents für unterschiedliche Dateitypen oder Verzeichnisse an

Show Fortgeschritten: Blockierende Reviews

Du kannst den Workflow so konfigurieren, dass er fehlschlägt, wenn kritische Probleme gefunden werden. Dadurch wird das Zusammenführen des Pull Requests verhindert, bis sie behoben sind.Blockierendes Verhalten zum Prompt hinzufügenAktualisiere zuerst deinen Review-Agent-Step, um die Umgebungsvariable BLOCKING_REVIEW einzuschließen, und füge dieses blockierende Verhalten zum Prompt hinzu:

Blocking behavior:
- If BLOCKING_REVIEW is true and any 🚨 or 🔒 issues were posted: echo "CRITICAL_ISSUES_FOUND=true" >> $GITHUB_ENV
- Otherwise: echo "CRITICAL_ISSUES_FOUND=false" >> $GITHUB_ENV
- Always set CRITICAL_ISSUES_FOUND at the end

Den blockierenden Prüf-Schritt hinzufügenFüge dann diesen neuen Schritt nach deinem Code-Review-Schritt hinzu:

      - name: Check blocking review results
        if: env.BLOCKING_REVIEW == 'true'
        run: |
          echo "Checking for critical issues..."
          echo "CRITICAL_ISSUES_FOUND: ${CRITICAL_ISSUES_FOUND:-unset}"

          if [ "${CRITICAL_ISSUES_FOUND:-false}" = "true" ]; then
            echo "❌ Critical issues found and blocking review is enabled. Failing the workflow."
            exit 1
          else
            echo "✅ No blocking issues found."
          fi

Erste Schritte

Headless

Referenz

Code Review

Authentifizierung konfigurieren

Agent-Berechtigungen einrichten

GitHub-Actions-Workflow erstellen

Workflow-Trigger einrichten

Repository auschecken

Cursor CLI installieren

Review-Agent konfigurieren

Teste deinen Reviewer

Nächste Schritte

Erste Schritte

Headless

Referenz

​Authentifizierung konfigurieren

​Agent-Berechtigungen einrichten

​GitHub-Actions-Workflow erstellen

​Workflow-Trigger einrichten

​Repository auschecken

​Cursor CLI installieren

​Review-Agent konfigurieren

​Teste deinen Reviewer

​Nächste Schritte

Authentifizierung konfigurieren

Agent-Berechtigungen einrichten

GitHub-Actions-Workflow erstellen

Workflow-Trigger einrichten

Repository auschecken

Cursor CLI installieren

Review-Agent konfigurieren

Teste deinen Reviewer

Nächste Schritte