Claude Code im Team: Übergaben, Reviews und Berechtigungsgrenzen

Claude Code beschleunigt einzelne Entwickler spürbar: Code untersuchen, Änderungen umsetzen und Tests schreiben geht schneller. Im Team wird das Problem aber weniger technisch und stärker organisatorisch. Wer hat welchen Befehl genehmigt? Welche Dateien hat Claude gesehen? Welche Risiken sind noch offen? Welche KI-Hinweise wurden wirklich von einem Menschen übernommen?

Dieser Leitfaden beschreibt einen praxistauglichen Ablauf für kleine und mittlere Entwicklungsteams. Er behandelt Übergaben, PR-Vorprüfung, Regeln in CLAUDE.md, Berechtigungsgrenzen, Onboarding, Incident-Übergaben und Kommunikationsfehler. Eine Berechtigungsgrenze ist der Bereich, in dem Claude Code lesen, bearbeiten oder Befehle ausführen darf. Ein Review-Beleg ist eine kurze PR-Notiz, die festhält, wie das Team mit KI-Vorschlägen umgegangen ist.

flowchart LR
  A["Anfrage des Entwicklers"] --> B["CLAUDE.md und Regeln"]
  B --> C["Arbeit mit Claude Code"]
  C --> D["Tests und Diff-Prüfung"]
  D --> E["Review-Beleg"]
  E --> F["Menschliches PR-Review"]

Vier gemeinsame Orte

Ein stabiler Teamprozess darf nicht davon abhängen, dass eine Person gute Prompts im Kopf hat. Regeln gehören in wiederverwendbare Dateien.

Ort	Zweck	In Git
CLAUDE.md	Projektregeln, Verbote, Testbefehle	Ja
.claude/settings.json	Gemeinsame Berechtigungen, deny-Regeln, hooks	Ja
.claude/settings.local.json	Persönliche Sandbox-URLs, temporäre Einstellungen	Nein
.claude/prompts/*.md	Vorlagen für Übergabe, Review und Untersuchung	Ja

Die offiziellen Dokumente erklären Claude Code Memory, Einstellungen, Berechtigungen und Sicherheit. Intern passen dazu CLAUDE.md Best Practices, der Claude Code Hooks Guide und GitHub Actions für Fortgeschrittene.

Fall 1: Übergabe vom Entwickler zum Reviewer

Der häufigste Fehler ist eine PR mit dem Hinweis „Claude hat es repariert“. Reviewer müssen wissen, welche Dateien Claude gelesen hat, welche Befehle genehmigt wurden, welche Tests fehlgeschlagen sind und welche Entscheidungen noch menschlich sind.

Erstelle .claude/prompts/handoff.md:

# Team-Übergabe schreiben

Lies den aktuellen Diff und schreibe die Übergabe in diesem Format.

## Ziel
- Problem, das diese Änderung lösen soll:

## Umfang
- Geänderte Dateien:
- Nicht geänderte, aber wahrscheinlich betroffene Dateien:

## Prüfung
- Ausgeführte Befehle:
- Ergebnis:
- Zusammenfassung fehlgeschlagener Logs:

## Fokus für den Reviewer
- Produktentscheidung:
- Sicherheit:
- Performance:
- Fehlende Tests:

## Nächste verantwortliche Person
- Zuerst prüfen:
- Kann warten:

Nach dem Erstellen des Diffs ausführbar:

claude -p "Lies git diff und erstelle eine Team-Übergabe im Format .claude/prompts/handoff.md"

Füge das Ergebnis in die PR-Beschreibung ein. So beginnt der Reviewer bei bekannten Risiken, statt den Kontext neu zu rekonstruieren.

Fall 2: PR-Vorprüfung mit KI

Claude Code sollte menschliche Freigabe nicht ersetzen. Es eignet sich als Vorprüfung, die offensichtliche Bugs, fehlende Tests, Sicherheitsrisiken und inkonsistente Änderungen früh sichtbar macht.

Erstelle .claude/prompts/pr-review.md:

# PR-Vorprüfung

Prüfe den Diff nach diesen Punkten:

1. Verzweigungen, null/undefined und Grenzwerte, die Bugs erzeugen können
2. Autorisierung, Validierung und Offenlegung von Geheimnissen
3. N+1-Abfragen, unnötige Rerender und schwere synchrone Arbeit
4. Verstöße gegen CLAUDE.md-Regeln
5. Fehlende Testfälle

Ausgabeformat:
- Schweregrad: hoch / mittel / niedrig
- Datei:
- Zeile oder Funktion:
- Grund:
- Korrekturvorschlag:

Kennzeichne spekulative Hinweise als “zu bestätigen”.

Lokal mit GitHub CLI:

gh pr diff 123 | claude -p "$(cat .claude/prompts/pr-review.md)"

Bei GitHub Actions sollte die Automatisierung nur kommentieren. Die Merge-Entscheidung bleibt bei Menschen.

name: Claude PR pre-review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  pre-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install tools
        run: npm install -g @anthropic-ai/claude-code
      - name: Run Claude Code review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: |
          gh pr diff "$PR_NUMBER" > /tmp/pr.diff
          claude -p "$(cat .claude/prompts/pr-review.md)

          Diff:
          $(cat /tmp/pr.diff)" > /tmp/claude-review.md
          gh pr comment "$PR_NUMBER" --body-file /tmp/claude-review.md

Die offiziellen Workflow-Beispiele behandeln ebenfalls Reviews und Tests. Die Teamregel muss klar sein: KI-Kommentare helfen, Menschen genehmigen.

Fall 3: Onboarding neuer Teammitglieder

Neue Teammitglieder scheitern selten an Syntax. Häufiger wissen sie nicht, welcher Befehl sicher ist, wo Geschäftsregeln stehen und welche Datei zuerst gelesen werden sollte. Claude Code kann eine erste Repository-Karte erstellen.

claude -p "
Erkläre dieses Repository für ein neues Teammitglied.
Enthalten sein müssen:
- Hauptverzeichnisse und Verantwortlichkeiten
- Befehle für lokales Starten, lint, test und build
- Die ersten 3 Dateien zum Lesen
- Geschäftsregeln, die vor Änderungen geprüft werden müssen
- Häufige Fehler und wie man sie vermeidet
- Eine Übungsaufgabe für 30 Minuten

Nicht raten. Unklares als zu bestätigen auflisten.
"

Veröffentliche die Ausgabe nicht ungeprüft. Eine erfahrene Person sollte Produktionsgrenzen, historische Entscheidungen und Betriebsrisiken ergänzen. Für größere Untersuchungen helfen Subagent-Muster, Recherche und Zusammenfassung zu trennen.

Fall 4: Incident-Übergabe

Während eines Incidents kann Claude Code Logs zusammenfassen und Hypothesen ordnen. Die Risiken sind hoch: Geheimnisse werden eingefügt, unbestätigte Vermutungen als Fakten geteilt oder bereits getestete Schritte gehen beim Schichtwechsel verloren.

Speichere diese Vorlage als .claude/prompts/incident-handoff.md:

# Incident-Übergabe

## Symptom
- Seit wann:
- Umfang:
- Auswirkung auf Nutzer:

## Beobachtete Fakten
- Logs:
- Metriken:
- Reproduktionsschritte:

## Bereits versucht
- Befehle:
- Ergebnis:
- Verworfene Hypothesen:

## Offenes Risiko
- Datenbeschädigung:
- Sicherheitsauswirkung:
- Rollback-Status:

## Nächste verantwortliche Person
- Erste Ansicht/erstes Log:
- Befehle, die nicht ausgeführt werden dürfen:

Maskiere E-Mail-Adressen, Zugriffstoken und Kunden-IDs, bevor Logs an Claude Code gehen. Die Sicherheitsdokumentation weist ebenfalls auf Berechtigungen und Prompt-Injection-Risiken hin.

Gute CLAUDE.md-Regeln

CLAUDE.md enthält Fakten, die das Team ständig wiederholt. Halte die Regeln kurz, konkret und prüfbar.

# Projektanweisungen für Claude Code

## Vor der Arbeit
- Vor Änderungen `git status --short` ausführen.
- Bestehende Änderungen anderer Personen nicht zurücksetzen.
- Bei unklarem Produktverhalten “zu bestätigen” in die PR schreiben.

## Code-Regeln
- Alle API-Eingaben validieren.
- Transaktionsgrenzen bei Datenbankschreibvorgängen explizit machen.
- Vor neuem UI-Text vorhandene Übersetzungsschlüssel wiederverwenden.

## Tests
- Für Logikänderungen Unit-Tests ergänzen.
- Für jeden Bugfix einen Regressionstest ergänzen.
- Nicht ausgeführte Tests mit Grund dokumentieren.

## PR
- Zusammenfassung, Prüfung und offenes Risiko angeben.
- Vorschläge von Claude Code nur nach menschlicher Prüfung übernehmen.

Wenn das Repository bereits AGENTS.md nutzt, importiere es statt Regeln zu duplizieren.

@AGENTS.md

## Nur für Claude Code
- Bei Abrechnung, Authentifizierung und Löschflüssen zuerst plan mode nutzen.
- Menschen führen `git push`, Produktionsdeployments und Migrationen aus.

Berechtigungsgrenzen festlegen

Das größte Risiko ist, Berechtigungen aus Bequemlichkeit zu erweitern. Starte mit klaren deny-Regeln und minimalem allow.

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)",
      "Bash(git diff *)",
      "Bash(git status *)",
      "Edit(src/**)",
      "Edit(tests/**)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(git commit *)",
      "Write(.github/**)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Bash(git push --force*)",
      "Bash(rm -rf *)",
      "Bash(npm publish*)"
    ]
  }
}

Hooks können nach Änderungen Prüfungen starten oder riskante Befehle stoppen. Lies vor der Einführung die offizielle Hooks-Referenz.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint -- --quiet"
          }
        ]
      }
    ]
  }
}

Dieses Beispiel setzt npm run lint voraus. In großen Monorepos sind dateibasierte Prüfungen oder CI meist besser.

Review-Beleg in der PR

KI-Review wird riskant, wenn niemand festhält, welche Vorschläge übernommen wurden. Ergänze die PR-Vorlage:

## Claude Code Review-Beleg

- Verwendeter Prompt:
- Von Claude Code geprüfter Diff:
- Übernommene Vorschläge:
- Abgelehnte Vorschläge und Grund:
- Zusätzliche menschliche Prüfungen:
- Ausgeführte Tests:
- Offenes Risiko:

Verantwortlich für die finale Entscheidung:

Wenn Claude Code nicht genutzt wurde, reicht “nicht genutzt”. Ziel ist, KI-gestützte Arbeit mindestens so transparent wie normale Arbeit zu machen.

Konkrete Fehler und Gegenmaßnahmen

Fehler	Auswirkung	Gegenmaßnahme
CLAUDE.md ist veraltet	Alte Befehle und entfernte APIs tauchen wieder auf	Monatlich anhand echter Fehler prüfen
Zu breite Rechte	Geheimnisse und produktionsnahe Aktionen kommen zu nah	Erst deny schreiben, allow minimieren
Nur KI-Freigabe	Produktentscheidung und Verantwortung verschwinden	PR-Freigabe immer menschlich
Mündliche Übergabe	Am nächsten Tag ist der Grund nicht nachvollziehbar	Notiz in PR oder Issue einfügen
/clear löscht Kontext	Warum geändert wurde, geht verloren	Vor reset oder compact Zusammenfassung speichern
Hooks sind zu schwer	Das Team umgeht sie	Dateibasierte hooks oder CI nutzen

Auch Kommunikation scheitert. “Mach es sauber” zwingt Claude Code, das Ziel zu erraten. Besser sind kurze Grenzen: “nur diese Funktion”, “schema nicht anfassen”, “zuerst das fehlgeschlagene Testlog lesen”.

Minimale Team-Checkliste

• CLAUDE.md enthält Befehle, Verbote und PR-Regeln
• .claude/settings.json trennt allow, ask und deny
• .claude/settings.local.json steht in .gitignore
• Prompts für Übergabe, PR-Review und Incident sind geteilt
• Die PR-Vorlage enthält einen Review-Beleg
• Die final entscheidende Person ist klar
• Es gibt eine 30-Minuten-Onboarding-Aufgabe

ClaudeCodeLab verbessert solche Vorlagen für KI-gestützte Entwicklungsteams fortlaufend. Für einen schnelleren internen Start siehe die ClaudeCodeLab-Produkte.

Fazit

Claude Code im Team bedeutet nicht, einen magischen Prompt zu finden. Es geht um gemeinsame Anweisungen, enge Berechtigungen, dauerhafte Übergaben und prüfbare Review-Belege.

Allein reichen ein paar gute Prompts oft aus. Im Team muss eine andere Person den Ablauf reproduzieren, Fehler nachvollziehen und Vorschläge von Claude Code von menschlichen Entscheidungen trennen können.

In Masas kleinem Validierungs-Repository brachte diese Struktur den größten Effekt durch Übergaben und Review-Belege in PRs. Reviewer fragten seltener “was hast du geprüft?”. Die schlechteste Einstellung war vollständiges lint nach jeder Bearbeitung per hook: zu langsam, daher besser in CI. Starte mit CLAUDE.md, dem PR-Vorprüfungs-Prompt und dem Review-Beleg.