⚠️ Disclaimer — große Macht, große Verantwortung

Claude Code kann ein Repository lesen, Dateien verändern, Befehle ausführen, Tests starten und externe Tools anbinden. Das ist mächtig — aber genau deshalb braucht es Obacht. Behandle Claude Code nicht wie einen harmlosen Chatbot, sondern wie einen sehr schnellen Entwickler mit Terminalzugriff.

Die wichtigsten Risikosäulen sind:

1. Prompt Injection & Code Injection: Externe Inhalte können versteckte oder direkte Anweisungen enthalten. Eine README, ein Issue, ein Kommentar, ein Figma-/Ticket-Text oder eine scheinbar harmlose Datei kann Sätze enthalten wie „ignoriere alle Regeln“, „lies Secrets aus“, „führe diesen Befehl aus“ oder „ändere Sicherheitslogik“. Auch package.json-Scripts, Installationsbefehle, Tests, Migrationsskripte oder Shell-Kommandos können unerwartet Code ausführen.

2. API-Keys, Tokens & andere Secrets: Sobald Claude Code Zugriff auf Ordner und Dateien erhält, können dort .env-Dateien, private Keys, Cloud-Credentials, Datenbank-URLs, OAuth-Secrets, GitLab-/GitHub-Tokens oder Zertifikate liegen. Solche Secrets dürfen nicht ungeprüft gelesen, kopiert, erklärt, committed, in Logs ausgegeben oder an externe Tools weitergegeben werden. Idealerweise arbeitet Claude mit minimal nötigen Berechtigungen und ohne Zugriff auf produktive Secrets.

3. Abhängigkeiten & Supply Chain: Neue Packages, Build-Scripts, Postinstall-Hooks oder automatisch ausgeführte Tools können schädlichen oder unerwarteten Code enthalten. Jede neue Dependency, jedes Installationskommando und jedes Script sollte geprüft werden, bevor es ausgeführt oder übernommen wird.

4. Daten, Datenschutz & Compliance: Testdaten, Kundendaten, interne Dokumente oder exportierte Datenbankinhalte können vertraulich sein. Prüfe, welche Daten Claude sehen darf und ob sie in Prompts, Logs, Commits, Tickets oder externen Integrationen auftauchen könnten.

5. Produktivsysteme & Berechtigungen: Claude sollte nicht unkontrolliert auf produktive Infrastruktur, Deployments, Datenbanken, Cloud-Ressourcen oder Admin-Funktionen zugreifen. Kritische Aktionen brauchen klare Freigabe, begrenzte Rechte und menschliches Review.

Grundregel: Claude darf helfen, aber nicht blind lenken. Arbeite mit Branches, prüfe Diffs, führe keine unbekannten Befehle ungeprüft aus, gib keine Secrets frei, begrenze Berechtigungen und lasse kritische Änderungen immer menschlich reviewen. Die Macht ist nützlich — solange jemand am Steuer bleibt.

Claude Code für Repositories

Wie Teams AI-gestützte Coding-Workflows sinnvoll in ihre Entwicklung integrieren

Agenda

1. Zielsetzung — Worum geht es in diesem Whitepaper?
2. Das große Bild — Claude Chat, Claude Code, Desktop, Web, IDE und MCP
3. Die Kernfrage — Brauchen wir für Code-Repositories einen MCP?
4. Die wichtigsten Varianten im Überblick
5. Vergleichstabelle — Welche Option kann was?
6. Der empfohlene Ziel-Workflow für Repositories
7. Stufenweise Implementierungsguideline
8. Best Practices für die tägliche Nutzung
9. Typische Stolperfallen und Grenzen
10. Empfehlung zum Start

1. Zielsetzung — Worum geht es in diesem Whitepaper?

Dieses Whitepaper beantwortet eine konkrete Frage:

Wie nutzen wir Claude sinnvoll für Code — nicht nur als Chatbot, sondern als Werkzeug, das unser Repository versteht, echte Dateien anpasst, Apps mitentwickelt und sich in unsere Entwicklungsprozesse integrieren lässt?

Im Design-Kontext ist der Nutzen von Claude in Verbindung mit Figma relativ greifbar: Ein Design-Frame wird analysiert, eine Variante wird erzeugt, ein Design-System wird geprüft oder Code aus einem Frame abgeleitet.

Bei Code ist die Lage etwas anders. Hier geht es nicht primär darum, ein externes Tool wie Figma anzubinden. Es geht darum, dass Claude direkten Zugriff auf ein Projekt erhält: auf Dateien, Architektur, bestehende Patterns, Tests, Build-Skripte, Git-Status und Team-Konventionen.

Die zentrale Erkenntnis lautet:

Für normale Code-Arbeit brauchen wir nicht zuerst einen MCP. Wir brauchen zuerst Claude Code direkt im Repository — ergänzt durch klare Projektregeln, saubere Review-Prozesse und später gezielte Integrationen.

Dieses Whitepaper zeigt:

• welche Claude-Code-Zugangswege es gibt,
• wann welche Variante sinnvoll ist,
• wo MCP wirklich gebraucht wird,
• wie ein Team schrittweise starten kann,
• und welche Struktur sich für professionelle Repo-Arbeit empfiehlt.

2. Das große Bild — Claude Chat, Claude Code, Desktop, Web, IDE und MCP

Bevor man sich für einen Workflow entscheidet, lohnt sich eine kurze Landkarte. Claude ist nicht einfach nur ein Chatfenster. Das Ökosystem besteht aus mehreren Oberflächen und Erweiterungsmechanismen.

Claude.ai / Claude Chat

Das ist der klassische Chat im Browser oder in der App. Er eignet sich sehr gut für:

• Architektur-Sparring,
• Konzeptarbeit,
• technische Einschätzungen,
• Erklärungen,
• Entscheidungsfindung,
• Review von eingefügtem Code.

Aber: Claude Chat arbeitet nicht automatisch in deinem lokalen Repository. Er sieht nur den Kontext, den du ihm gibst — etwa kopierte Code-Snippets, hochgeladene Dateien oder verknüpfte Quellen.

Claude Code

Claude Code ist der agentische Coding-Assistent. Er kann:

• ein Repository lesen,
• Dateien ändern,
• Befehle ausführen,
• Tests starten,
• Build-Fehler analysieren,
• Git-Diffs prüfen,
• Branches vorbereiten,
• und Aufgaben über mehrere Dateien hinweg umsetzen.

Claude Code ist damit nicht nur ein Antwortsystem, sondern ein ausführendes Werkzeug.

Desktop App

Die Claude Desktop App bündelt mehrere Arbeitsweisen:

• Chat für allgemeine Gespräche,
• Cowork für längere agentische Aufgaben in einer Cloud-Umgebung,
• Code für interaktive Softwareentwicklung mit Zugriff auf lokale Dateien.

Der Code-Tab ist dabei besonders relevant, wenn man ohne Terminal arbeiten möchte, aber trotzdem echte Dateien im Projekt ändern lassen will.

IDE-Integration

Für Entwickler:innen ist die Integration in VS Code oder JetBrains besonders naheliegend. Claude Code sitzt dann direkt dort, wo ohnehin gearbeitet wird. Das erleichtert:

• Inline-Diffs,
• File-Auswahl,
• Kontextreferenzen,
• Review von Änderungen,
• paralleles Arbeiten mit Editor und Claude.

Claude Code im Web

Claude Code im Web läuft nicht lokal, sondern in einer Cloud-Umgebung. Das ist sinnvoll, wenn ein GitHub-Repository bearbeitet werden soll, ohne lokal etwas einzurichten. Claude erstellt Änderungen dann typischerweise in einem Branch oder Pull Request.

Für lokale Setups mit Docker, .env, Datenbanken, Keycloak, internen Tools oder halbfertigen lokalen Änderungen ist der lokale Workflow meist besser.

MCP — Model Context Protocol

MCP ist ein Standard, um Claude mit externen Werkzeugen und Datenquellen zu verbinden. Dazu gehören zum Beispiel:

• Figma,
• GitHub oder GitLab,
• Jira oder Linear,
• Slack,
• Google Drive,
• Datenbanken,
• interne APIs,
• eigene Toolserver.

MCP ist also nicht der Weg, um normale Projektdateien zu lesen. Dafür reicht Claude Code im Repository. MCP wird dann relevant, wenn Claude über das Repository hinaus auf externe Systeme zugreifen oder dort Aktionen ausführen soll.

3. Die Kernfrage — Brauchen wir für Code-Repositories einen MCP?

Die kurze Antwort:

Nein, nicht für das Repository selbst.

Wenn Claude Code lokal im Projektordner gestartet wird, kann es bereits mit dem Projekt arbeiten. Es kann Dateien lesen, Änderungen vorschlagen oder durchführen, Terminalbefehle ausführen, Tests starten und Git-Diffs erzeugen.

Ein MCP ist dafür nicht nötig.

Wann kein MCP nötig ist

Kein MCP ist nötig für:

• React-Komponenten erstellen,
• Flask- oder Node-Endpunkte anpassen,
• bestehende Patterns im Repo verstehen,
• Tests schreiben,
• Build-Fehler beheben,
• Refactorings durchführen,
• Dokumentation im Repo ergänzen,
• CLAUDE.md erstellen,
• Git-Diff prüfen,
• Commits vorbereiten.

Hier reicht Claude Code mit lokalem Repo-Zugriff.

Wann MCP sinnvoll wird

MCP wird sinnvoll, sobald Claude Informationen oder Aktionen aus externen Systemen braucht.

Beispiele:

• Claude soll ein Figma-Design direkt lesen und daraus eine React-Komponente ableiten.
• Claude soll ein GitLab-Issue lesen und daraus einen Merge Request vorbereiten.
• Claude soll eine Datenbankstruktur prüfen.
• Claude soll in Slack nach Kontext zu einer Produktentscheidung suchen.
• Claude soll interne PRIM- oder OLYMP-Generatoren ansprechen.
• Claude soll eine eigene Modul-Registry abfragen.

Die Formel lautet:

Repository-Arbeit = Claude Code lokal.
Externe Tool-Integration = MCP.

4. Die wichtigsten Varianten im Überblick

Im Folgenden werden die wichtigsten Arbeitsvarianten beschrieben.

Variante A — Claude.ai / Chat

Claude.ai ist der richtige Ort für Denk- und Konzeptarbeit.

Typische Aufgaben:

• „Wie würdest du diese Architektur bewerten?“
• „Welche Optionen haben wir für Mandantenfähigkeit?“
• „Erkläre mir diesen Code-Ausschnitt.“
• „Formuliere eine technische Spezifikation.“
• „Vergleiche Flask, FastAPI und NestJS für unseren Use Case.“

Was gut funktioniert

Claude Chat ist stark, wenn man diskutieren, strukturieren oder Entscheidungen vorbereiten möchte. Es eignet sich auch gut, um Anforderungen zu schärfen, bevor Claude Code später wirklich Dateien ändert.

Grenzen

Claude Chat arbeitet nicht automatisch im lokalen Repository. Ohne Uploads oder eingefügten Kontext kennt es weder aktuelle Dateien noch lokale Änderungen noch Projektstruktur.

Einordnung

Claude Chat ist der Denkraum. Claude Code ist der Ausführungsraum.

Variante B — Claude Code CLI lokal im Repository

Das ist der direkteste und mächtigste Standardweg.

Man öffnet ein Terminal im Projektordner und startet Claude Code:

cd /pfad/zum/projekt
claude

Danach kann man Claude Aufgaben geben wie:

Lies zuerst das Projekt. Erstelle mir eine Architekturübersicht: Frontend, Backend, Auth, Datenmodell, Build- und Testbefehle. Ändere noch keine Dateien.

Oder:

Baue eine neue Kundenprofil-Seite nach bestehendem Pattern. Nutze vorhandene Komponenten, führe Tests aus und zeige mir danach den Diff.

Was gut funktioniert

• vollständiger Zugriff auf lokale Projektdateien,
• Arbeiten über mehrere Dateien hinweg,
• Nutzung von Tests und Build-Befehlen,
• Git-Diff und Commit-Vorbereitung,
• direkte Nutzung von CLAUDE.md, Skills, Hooks und MCP,
• gut geeignet für Power-User und technische Workflows.

Grenzen

• terminalorientiert,
• weniger visuelle Diff-Erfahrung als in VS Code oder Desktop,
• für nicht-technische Nutzer:innen zunächst ungewohnt.

Einordnung

Die CLI ist der Referenzweg. Auch wenn später VS Code oder Desktop genutzt wird, sollte das Team verstehen: Claude Code arbeitet auf einem echten Projektordner und nicht auf einer abstrakten Chat-Kopie.

Variante C — Claude Code in VS Code

Für Entwickler:innen ist die VS-Code-Integration meist der beste Alltagsweg.

Claude sitzt direkt im Editor und kann:

• Dateien und Ordner aus dem Projektkontext verwenden,
• Änderungen als Inline-Diff anzeigen,
• ausgewählte Codebereiche berücksichtigen,
• Terminalbefehle ausführen,
• mehrere Sessions unterstützen,
• und mit denselben Projektregeln arbeiten wie die CLI.

Was gut funktioniert

• sehr gute Integration in den Entwicklungsalltag,
• visuelle Prüfung von Änderungen,
• weniger Kontextwechsel,
• direkte Verbindung von Code, Terminal und Claude,
• ideal für Feature-Entwicklung, Bugfixing und Refactoring.

Grenzen

• an VS Code gebunden,
• Teams mit anderen IDEs brauchen alternative Setups,
• für Automatisierung nicht so skriptbar wie die CLI.

Einordnung

Für PRIM-/OLYMP-Entwicklung wäre das vermutlich der beste Standard für Entwickler:innen.

Variante D — Claude Code Desktop, Tab „Code“

Der Code-Tab in der Claude Desktop App ist interessant für alle, die weniger terminalorientiert arbeiten möchten.

Man wählt einen Projektordner aus, startet eine Session und Claude kann lokal mit den Dateien arbeiten. Änderungen werden sichtbar gemacht und müssen geprüft beziehungsweise freigegeben werden.

Was gut funktioniert

• lokale Dateien nutzbar,
• visuelle Diff-Prüfung,
• parallele Sessions,
• App-Preview,
• weniger Terminalhürde,
• gut für steuernde Rollen oder Design-Engineering-Workflows.

Grenzen

• nicht so terminal- und skriptingnah wie die CLI,
• nicht auf allen Plattformen gleich verfügbar,
• für tiefe Entwicklerarbeit ist VS Code oft natürlicher.

Einordnung

Gut für Personen, die Code-Arbeit steuern oder prüfen wollen, ohne komplett im Terminal zu arbeiten.

Variante E — Claude Code im Web

Claude Code im Web ist eine Cloud-Variante. Claude arbeitet dabei nicht auf deinem lokalen Ordner, sondern in einer gehosteten Umgebung mit einem geklonten Repository.

Typischer Ablauf:

1. Repository verbinden.
2. Aufgabe formulieren.
3. Claude arbeitet in einer Cloud-Umgebung.
4. Claude erstellt Branch oder Pull Request.
5. Team reviewed die Änderungen.

Was gut funktioniert

• kein lokales Setup nötig,
• gut für klar abgegrenzte Aufgaben,
• nützlich für parallele Arbeiten,
• geeignet für Pull-Request-orientierte Workflows,
• Aufgaben können weiterlaufen, auch wenn man nicht lokal verbunden ist.

Grenzen

• kein direkter Zugriff auf lokale .env, lokale Docker-Setups oder lokale Datenbanken,
• weniger geeignet für unfertige lokale Änderungen,
• abhängig von Repository- und Cloud-Konfiguration.

Einordnung

Gut für klar beschriebene Repo-Aufgaben. Weniger gut, wenn lokale Entwicklungsumgebung, Secrets, Docker Compose, Keycloak, Testdatenbanken oder interne Services entscheidend sind.

Variante F — Remote Control

Remote Control ist ein Hybrid. Claude Code läuft lokal, kann aber über Browser oder mobile Oberfläche gesteuert werden.

Was gut funktioniert

• lokale Umgebung bleibt erhalten,
• Steuerung von anderem Gerät möglich,
• nützlich für längere laufende Aufgaben,
• lokale MCP-Server und lokale Projektkonfiguration bleiben nutzbar.

Grenzen

• der lokale Rechner muss laufen,
• weniger ein Startpunkt als eine Ergänzung,
• für strukturierte Teamprozesse weniger zentral als CI/CD.

Einordnung

Nice-to-have, wenn man lokale Sessions aus der Ferne überwachen oder steuern möchte.

Variante G — GitHub Actions / GitLab CI/CD

Das ist die Team- und Automatisierungsvariante.

Claude wird dabei über CI/CD eingebunden. Aufgaben können zum Beispiel durch Kommentare, Issues, Merge Requests oder manuelle Pipeline-Auslöser gestartet werden.

Typische Anwendungsfälle:

• „@claude review this MR“
• „@claude implement this issue“
• „@claude fix failing tests“
• automatische Review-Kommentare,
• Issue-to-MR-Workflows,
• wiederkehrende Wartungsaufgaben.

Was gut funktioniert

• Governance über Branch Protection und Reviews,
• gute Nachvollziehbarkeit,
• Team-Workflow statt Einzelplatzlösung,
• Automatisierung wiederkehrender Aufgaben,
• besonders interessant für GitLab-basierte Organisationen.

Grenzen

• Setup-Aufwand,
• API-Key-/Provider-/Runner-Konfiguration nötig,
• Sicherheits- und Berechtigungsmodell muss sauber definiert werden,
• nicht ideal als allererster Einstieg.

Einordnung

Sehr relevant für später. Der Start sollte aber lokal erfolgen, damit das Team lernt, wie gute Claude-Code-Aufgaben formuliert, geprüft und eingegrenzt werden.

5. Vergleichstabelle — Welche Option kann was?

6. Der empfohlene Ziel-Workflow für Repositories

Für ein professionelles Team sollte Claude Code nicht als „magischer Autocoder“ eingeführt werden, sondern als kontrollierter Entwicklungsassistent.

Der Ziel-Workflow sieht so aus:

Konzept / Auftrag
   ↓
Planung mit Claude Chat oder Claude Code Plan Mode
   ↓
Lokale Umsetzung mit Claude Code im Repository
   ↓
Review der Diffs
   ↓
Tests / Lint / Build
   ↓
Commit / Branch / Merge Request
   ↓
Menschliches Review
   ↓
Optional: CI/CD-Automation für wiederkehrende Aufgaben

Wichtig ist die Trennung zwischen:

• Denken: Anforderungen, Architektur, Konzepte, Alternativen.
• Planen: Welche Dateien ändern sich? Welche Risiken gibt es? Welche Tests braucht es?
• Umsetzen: Claude Code ändert echte Dateien.
• Prüfen: Mensch + Tests + Git-Diff.
• Automatisieren: Erst später über CI/CD oder MCP-gestützte Workflows.

7. Stufenweise Implementierungsguideline

Die Einführung sollte nicht mit allen Möglichkeiten gleichzeitig starten. Besser ist ein gestuftes Vorgehen.

Stufe 1 — Lokaler Einzelplatz-Workflow

Ziel: Claude Code sicher im Repository nutzen.

Setup

• Claude Code CLI installieren oder VS-Code-Extension nutzen.
• Ein bekanntes, nicht kritisches Projekt auswählen.
• Claude Code im Repo-Root starten.
• Zunächst nur lesen und analysieren lassen.
• Danach kleine Änderungen durchführen lassen.

Erster sinnvoller Prompt

Lies zuerst das Projekt. Erstelle mir eine Architekturübersicht:
- Frontend
- Backend
- Auth
- Datenmodell
- Build-Befehle
- Test-Befehle
- wichtige Ordner
- mögliche Risiken

Ändere noch keine Dateien.

Danach

Erstelle eine CLAUDE.md für dieses Repository.
Sie soll enthalten:
- Projektüberblick
- Stack
- Architekturregeln
- Coding Conventions
- Test- und Build-Befehle
- No-Gos
- Sicherheitsregeln
- Hinweise für zukünftige Claude-Code-Sessions

Zeige mir den Vorschlag zuerst, bevor du die Datei anlegst.

Ergebnis dieser Stufe

• Claude kann das Projekt erklären.
• Das Team versteht, wie Claude Code arbeitet.
• Erste CLAUDE.md liegt vor.
• Kleine Änderungen können kontrolliert durchgeführt werden.

Stufe 2 — Projektregeln mit CLAUDE.md

Ziel: Claude bekommt dauerhaft projektspezifische Regeln.

CLAUDE.md ist eine Markdown-Datei im Repository. Sie wird von Claude Code zu Beginn einer Session gelesen und enthält wichtige Projektkonventionen.

Typische Inhalte

# Projektkontext

Dieses Projekt ist Teil von OLYMP / PRIM.

## Stack

- Frontend: React, TypeScript, Tailwind
- Backend: Flask oder Node/Express
- Auth: Keycloak
- Datenbank: PostgreSQL / MongoDB / projektabhängig

## Regeln

- Vor Änderungen immer bestehende Patterns suchen.
- Keine neuen Libraries ohne Rückfrage hinzufügen.
- Bestehende Komponenten bevorzugen.
- Keine Secrets lesen oder ausgeben.
- Vor Commit Tests ausführen.
- Änderungen immer als Diff erklären.

Nutzen

• Claude muss nicht jedes Mal neu instruiert werden.
• Team-Konventionen werden explizit.
• Onboarding wird leichter.
• Review-Qualität steigt.

Ergebnis dieser Stufe

Claude arbeitet nicht mehr nur mit generischem Wissen, sondern mit den konkreten Regeln des Projekts.

Stufe 3 — Standardisierte Arbeitsmodi

Ziel: Wiederkehrende Prompts und Arbeitsmuster etablieren.

Nicht jede Aufgabe sollte direkt umgesetzt werden. Für größere Aufgaben empfiehlt sich ein Vier-Schritt-Muster:

1. Explore — Projekt und betroffene Dateien lesen.
2. Plan — Umsetzungsplan erstellen.
3. Implement — Dateien ändern.
4. Verify — Tests ausführen und Diff erklären.

Beispiel: Feature-Entwicklung

Wir wollen ein Kundenprofil-Modul ergänzen.

Arbeite in vier Schritten:
1. Untersuche zuerst bestehende Modul-Patterns.
2. Erstelle einen Umsetzungsplan mit betroffenen Dateien.
3. Warte auf Freigabe.
4. Setze danach um, führe Tests aus und erkläre den Diff.

Beispiel: Bugfix

User berichten, dass der Login nach Session-Timeout fehlschlägt.
Untersuche den Auth-Flow, insbesondere Token Refresh und Keycloak-Integration.
Ändere zunächst nichts. Gib mir zuerst Hypothesen und relevante Dateien.

Ergebnis dieser Stufe

Das Team arbeitet mit Claude Code kontrolliert statt impulsiv. Claude springt nicht sofort in Änderungen, sondern untersucht und plant zuerst.

Stufe 4 — Skills für wiederkehrende Workflows

Ziel: Wiederkehrende Aufgaben als Skills standardisieren.

Skills sind wiederverwendbare Arbeitsanweisungen. Sie eignen sich, wenn bestimmte Prozesse immer wieder vorkommen.

Für PRIM/OLYMP wären zum Beispiel sinnvoll:

Beispiel Skill-Idee: review-before-commit

Der Skill könnte Claude anweisen:

• alle geänderten Dateien zu prüfen,
• Architekturverstöße zu suchen,
• Sicherheitsrisiken zu nennen,
• fehlende Tests zu markieren,
• eine Commit Message vorzuschlagen,
• aber nichts ohne Freigabe zu committen.

Ergebnis dieser Stufe

Claude Code wird berechenbarer. Wiederkehrende Qualitätssicherungs- und Entwicklungsabläufe müssen nicht jedes Mal neu erklärt werden.

Stufe 5 — MCP gezielt ergänzen

Ziel: Externe Systeme anbinden, wenn sie echten Mehrwert liefern.

MCP sollte nicht pauschal eingeführt werden. Jede MCP-Integration sollte eine klare Frage beantworten:

Welchen Kontext oder welche Aktion braucht Claude, die nicht im Repository liegt?

Sinnvolle MCP-Kandidaten

Beispiel: Figma → Code

Nutze den Figma-Link als Kontext.
Analysiere das Layout, suche im Repo nach bestehenden Komponenten und baue die Ansicht mit vorhandenen Design Tokens nach.
Erstelle zuerst einen Plan und ändere noch keine Dateien.

Beispiel: GitLab-Issue → Merge Request

Lies das GitLab-Issue, identifiziere betroffene Bereiche im Repo, erstelle einen Umsetzungsplan und schlage einen Branch-Namen vor.

Ergebnis dieser Stufe

Claude arbeitet nicht mehr nur mit Repo-Wissen, sondern kann gezielt Kontext aus externen Systemen verwenden.

Stufe 6 — CI/CD-Integration

Ziel: Wiederkehrende Teamaufgaben automatisieren.

Wenn lokale Nutzung stabil funktioniert, kann Claude in GitHub Actions oder GitLab CI/CD eingebunden werden.

Typische Workflows

• automatisierte Merge-Request-Reviews,
• Issue-to-MR-Umsetzung,
• Testfehler analysieren,
• Dokumentation aktualisieren,
• kleinere Refactorings vorbereiten,
• Security- oder Architekturchecks durchführen.

Beispiel-Kommandos im Teamworkflow

@claude review this MR

@claude implement this issue as a new branch

@claude investigate the failing pipeline and propose a fix

Voraussetzungen

• klare Branch-Regeln,
• Reviewpflicht,
• begrenzte Rechte,
• saubere Secrets-Verwaltung,
• definierte Trigger,
• klare CLAUDE.md,
• gute Testabdeckung.

Ergebnis dieser Stufe

Claude wird Teil des Entwicklungsprozesses, nicht nur persönlicher Assistent einzelner Entwickler:innen.

8. Best Practices für die tägliche Nutzung

1. Erst lesen lassen, dann ändern lassen

Für neue Repositories oder größere Aufgaben sollte Claude zuerst verstehen, nicht sofort implementieren.

Guter Prompt:

Untersuche zuerst die relevanten Dateien. Ändere noch nichts. Gib mir danach eine kurze Einschätzung und einen Plan.

2. Bestehende Patterns referenzieren

Claude sollte nicht aus dem Nichts bauen.

Guter Prompt:

Suche zuerst nach bestehenden Komponenten, die ähnlich funktionieren. Verwende deren Pattern und erkläre mir, welche du übernommen hast.

3. Kleine, klare Aufgaben geben

Schlecht:

Baue das ganze Kundenmodul.

Besser:

Erstelle zunächst nur die Listenansicht für Kundenprofile. Nutze bestehende Table-Komponenten. Noch keine Detailseite und keine Backend-Änderungen.

4. Diffs immer prüfen

Claude sollte keine unkontrollierte Schreibmaschine sein. Jede Änderung sollte über Diff, Tests und Review laufen.

5. Tests explizit verlangen

Guter Prompt:

Führe nach der Änderung die relevanten Tests aus. Wenn Tests fehlschlagen, analysiere die Ursache und frage vor größeren Folgeänderungen nach.

6. No-Gos in CLAUDE.md festhalten

Zum Beispiel:

• keine neuen Dependencies ohne Rückfrage,
• keine Secrets lesen,
• keine Migration ohne explizite Freigabe,
• keine Auth-Logik ändern ohne Plan,
• keine globalen Design Tokens ändern ohne Review,
• keine automatischen Commits ohne Bestätigung.

7. Claude als Junior+Pair behandeln, nicht als unkontrollierten Autopiloten

Claude kann sehr schnell sehr viel ändern. Genau deshalb braucht es klare Grenzen, gute Aufgabenstellung und Review.

9. Typische Stolperfallen und Grenzen

Stolperfalle 1 — Zu große Aufgaben

Wenn Claude zu viel auf einmal machen soll, steigt die Wahrscheinlichkeit, dass es falsche Annahmen trifft oder unnötig viele Dateien ändert.

Besser: Aufgaben schneiden.

Stolperfalle 2 — Kein Projektkontext

Ohne CLAUDE.md muss Claude jedes Mal neu erraten, wie das Projekt funktioniert.

Besser: Projektregeln dokumentieren.

Stolperfalle 3 — Neue Libraries statt bestehender Patterns

Claude kann dazu neigen, externe Libraries vorzuschlagen, wenn es keinen Hinweis auf vorhandene Komponenten bekommt.

Besser: „Suche zuerst nach bestehenden Patterns“ als Standardregel.

Stolperfalle 4 — Lokale Umgebung unterschätzen

Cloud-Workflows sind praktisch, aber sie kennen nicht automatisch lokale .env, lokale Datenbanken, Docker-Compose-Setups oder interne Services.

Besser: Lokal arbeiten, wenn lokale Umgebung relevant ist.

Stolperfalle 5 — MCP zu früh einführen

MCP klingt mächtig, kann aber auch Komplexität erzeugen.

Besser: Erst Claude Code im Repo stabil nutzen. Dann gezielt MCP für Figma, GitLab, Datenbanken oder interne Tools ergänzen.

Stolperfalle 6 — Keine Review-Governance

Claude sollte nicht direkt in main schreiben oder ungeprüft produktive Änderungen ausrollen.

Besser: Branches, Diffs, Tests, Reviews.

10. Empfehlung zum Start

Für PRIM/OLYMP oder ein ähnliches Entwicklungssetup empfiehlt sich folgende Reihenfolge:

1. VS Code Extension als Standard für Entwickler:innen einführen
2. CLI als Power- und Fallback-Weg verstehen
3. Desktop Code Tab für visuelle Steuerung testen
4. In jedem wichtigen Repo eine CLAUDE.md anlegen
5. Kleine, kontrollierte Aufgaben durchführen
6. Wiederkehrende Workflows als Skills standardisieren
7. MCP erst für echte externe Kontexte einsetzen
8. GitLab CI/CD später für Team-Automation ergänzen

Die empfohlene Startkonfiguration lautet:

VS Code Extension oder CLI
+ Claude Code im Repo-Root
+ CLAUDE.md im Repository
+ Git-Branch pro Aufgabe
+ Diff-Review
+ Tests/Lint/Build vor Merge

Erst danach folgen:

Skills
+ MCP
+ GitLab CI/CD
+ eigene PRIM/OLYMP-Automationen

Abschluss

Claude Code verändert den Entwicklungsprozess nicht dadurch, dass es „ein bisschen besseren Autocomplete“ liefert. Der eigentliche Unterschied ist, dass Claude Code projektweit arbeiten kann: Es liest, plant, ändert, testet und erklärt.

Damit verschiebt sich die Rolle des Menschen.

Weniger Zeit geht in mechanische Umsetzung. Mehr Zeit geht in:

• klare Aufgabenstellung,
• Architekturentscheidungen,
• Review,
• Qualitätssicherung,
• Produktlogik,
• Team-Konventionen.

Die wichtigste Erkenntnis bleibt:

Für Code-Repositories ist Claude Code selbst der Kern. Der erste professionelle Schritt ist ein lokaler Repo-Workflow mit klarer CLAUDE.md, kleinen Aufgaben, Diffs, Tests und Review.

Wenn dieser Ablauf sitzt, können Figma, GitLab, Datenbanken, Slack, interne APIs und eigene PRIM-/OLYMP-Tools schrittweise angebunden werden. Dann wird aus Claude Code nicht nur ein Coding-Assistent, sondern ein integrierter Bestandteil des Entwicklungsprozesses.