Die vollständige Claude Code Einrichtungsanleitung (2026)

Du hast gerade Claude Code installiert. Du hast claude in dein Terminal getippt und... es funktioniert. Es kann deine Dateien lesen, Befehle ausführen, Code schreiben. Ziemlich cool.

Aber hier ist das Ding: Du nutzt gerade 90% seiner Leistung nicht.

In unserer Analyse von über 800 Konfigurationen auf jeanclaudecode.ai liegt der Durchschnittsscore bei 3.2 von 10. Die meisten Leute installieren Claude Code, schreiben vielleicht ein paar Zeilen Anweisungen, und hören auf. Zehn Minuten Setup trennen einen einfachen Chatbot von einem echten Coding-Partner.

Lass uns das jetzt beheben.

Die eine Datei, die alles ändert

Erstelle eine Datei namens CLAUDE.md im Root deines Projekts. Das war's. Das ist das Wichtigste, was du heute tun wirst.

touch CLAUDE.md

CLAUDE.md ist das Erste, was Claude beim Sessionstart liest. Stell es dir wie ein Briefing vor — du sagst Claude, mit wem es arbeitet, wie das Projekt aussieht, und was die Regeln sind.

Hier ist eine minimale Version zum Starten. Öffne CLAUDE.md und füge das ein:

# Mein Projekt

## Tech-Stack
- Next.js 15, TypeScript, PostgreSQL

## Befehle
- `npm run dev` — Dev-Server starten
- `npm run test` — Tests ausführen
- `npm run build` — Produktions-Build

## Regeln
- Immer Tests laufen lassen bevor du sagst, eine Aufgabe ist erledigt
- Nie Dateien in src/legacy/ ändern

Fünf Zeilen Tech-Stack. Drei Befehle. Zwei Regeln. Das reicht für den Anfang.

Probier es jetzt aus. Öffne Claude Code und frage: „Lies meine CLAUDE.md und sag mir, was für ein Projekt das ist." Claude sollte dir dein Projekt beschreiben. Wenn ja, alles klar. Wenn nicht, prüfe ob die Datei im Projektstamm liegt (nicht in einem Unterordner).

Du hast Claude gerade etwas gegeben, das 68% der Setups nicht haben: grundlegendes Projektwissen.

Ausbau: Die CLAUDE.md der Top-Setups

Diese Minimaldatei funktioniert. Aber die Setups mit Score 7+ in unserer Analyse gehen weiter. Hier ist, was sie hinzufügen — und warum jeder Abschnitt wichtig ist.

Architektur-Abschnitt (in 78% der Top-Setups)

Claude weiß nicht, wo deine Dateien liegen. Ohne Karte rät es — und rät falsch. Füge das hinzu:

## Architektur
- src/app/ — App Router Seiten und API-Routen
- src/lib/ — Geteilte Utilities und Datenbank-Client
- src/components/ — React-Komponenten (kolokierte Tests)

Wenn du jetzt sagst „erstelle eine neue API-Route", legt Claude sie in src/app/api/ ab, statt sich einen zufälligen Ort auszudenken.

Konventionen-Abschnitt (65% der Top-Setups)

Du hast Vorstellungen davon, wie Code aussehen soll. Claude kennt sie nicht, wenn du sie nicht aussprichst:

## Konventionen
- Imperative Commit-Messages, Kleinschreibung, kein Punkt
- Eine Komponente pro Datei, nur Named Exports
- Alle API-Routen validieren Eingaben mit Zod-Schemas

Sei konkret. „Schreib sauberen Code" gibt Claude nichts. „Verwende Zod für alle API-Eingabevalidierung" gibt ihm eine klare Regel.

Bekannte Probleme (nur 34% der Top-Setups — die größte verpasste Chance)

Diesen Abschnitt überspringen die meisten, und er spart dir die meiste Frustration:

## Bekannte Probleme
- Der Stripe-Webhook-Handler braucht `raw` Body-Parsing — express.json() Middleware nicht auf /api/webhooks/stripe verwenden
- Safari unterstützt `structuredClone` in Workers nicht — Polyfill in src/lib/clone.ts verwenden
- Die CI-Umgebung hat 4 GB RAM — Tests die das überschreiten, scheitern lautlos (OOM)

Jedes Mal wenn Claude einen Fehler macht, den du schon kennst, trag ihn hier ein. Mit der Zeit wird dieser Abschnitt zum wertvollsten Teil der Datei — ein lebendiges Protokoll von „tritt nicht auf diese Mine."

Jetzt die Berechtigungen (damit Claude aufhört, für jede Kleinigkeit nachzufragen)

Standardmäßig fragt Claude bei jedem Shell-Befehl um Erlaubnis. Jedes. Einzelne. Mal. Das nervt schnell.

Die Lösung: Eine Einstellungsdatei erstellen, die Claude sagt, was es ohne Nachfrage tun darf.

mkdir -p .claude

Erstelle jetzt .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm run test*)",
      "Bash(npm run build)",
      "Bash(npm run lint*)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)"
    ]
  }
}

Die allow-Liste sagt „mach einfach, frag nicht." Die deny-Liste sagt „mach das nie, auch wenn ich es versehentlich sage."

Wichtig: Setze nie "Bash(*)" in die Allow-Liste. Das gibt Claude vollen Shell-Zugriff ohne Leitplanken. Sei präzise bei dem, was erlaubt ist.

Probier Claude Code jetzt aus. Bitte es, den Git-Status zu prüfen oder Tests zu starten. Siehst du, wie es einfach... macht? Kein Berechtigungs-Popup. Dieser Flow ist das, was Setups die aufgegeben werden von Setups trennt, die tatsächlich täglich genutzt werden.

Rules hinzufügen, die sich automatisch aktivieren

Du fragst dich vielleicht: „Soll ich alle meine Coding-Konventionen in CLAUDE.md packen?" Könntest du. Aber es gibt einen schlaueren Weg.

Rules sind Markdown-Dateien, die sich aktivieren je nachdem an welchen Dateien Claude arbeitet. Wenn Claude eine .tsx-Datei bearbeitet, lädt es deine Frontend-Regeln. Wenn es eine Migrationsdatei berührt, lädt es deine Datenbank-Regeln. Wenn es an CSS arbeitet, verschwendet es keine Zeit mit deinen SQL-Konventionen.

Erstelle das Rules-Verzeichnis:

mkdir -p .claude/rules

Hier ist eine Frontend-Rule. Speichere sie als .claude/rules/frontend.md:

---
globs: ["*.tsx", "*.jsx", "*.css"]
---

- Named Exports verwenden, keine Default-Exports
- Jede Komponente muss eine zugehörige .test.tsx Datei haben
- Nur CSS Modules — keine Inline-Styles außer für dynamische Werte
- Alle Bilder brauchen Alt-Text (Barrierefreiheitsanforderung)

Und eine Datenbank-Rule — speichere als .claude/rules/database.md:

---
globs: ["*.sql", "**/migrations/**", "**/prisma/**"]
---

- Bestehende Migrationsdateien nie ändern
- Alle Queries müssen parametrisierte Eingaben verwenden — nie String-Konkatenation
- Rollback-Logik in jeder Migration einbauen

Die globs-Zeile oben ist der Auslöser. Wenn Claude eine Datei liest oder bearbeitet, die diesem Muster entspricht, wird die Rule automatisch geladen. Keine verschwendeten Tokens, wenn es nicht relevant ist.

Schau dir an, was du gebaut hast

So sollte dein Projekt jetzt aussehen:

dein-projekt/
├── CLAUDE.md                          # Dein Projekt-Briefing
├── .claude/
│   ├── settings.json                  # Berechtigungen (committed, im Team geteilt)
│   └── rules/
│       ├── frontend.md                # Aktiviert für .tsx, .jsx, .css
│       └── database.md                # Aktiviert für .sql, Migrationen
├── .gitignore
└── src/
    └── ...

Noch eine Sache — füge diese Zeile zu deiner .gitignore hinzu:

# Claude Code lokale Einstellungen
.claude/settings.local.json

Die settings.local.json-Datei ist für persönliche Präferenzen (wie dein bevorzugtes Modell). Die gehört nicht in die Versionskontrolle. Die normale settings.json? Die committen — das ist geteilte Team-Konfiguration.

Alles überprüfen

Öffne Claude Code und probiere das:

> Lies meine CLAUDE.md und sag mir, was für ein Projekt das ist. Welche Rules siehst du?

Claude sollte dein Projekt beschreiben, die gefundenen Rules in .claude/rules/ auflisten und die Berechtigungen aus settings.json bestätigen. Wenn ja, bist du fertig. Wenn etwas fehlt, prüfe ob deine Dateien am richtigen Ort liegen.

Du kannst auch dein Setup mit unserem Analyzer bewerten — er prüft alle vier Ebenen (CLAUDE.md, Settings, Rules, Verzeichnisstruktur) und sagt dir genau, was funktioniert und was fehlt.

Die Fehler, die Setups runterziehen

Nach der Analyse Hunderter Setups sind hier die Muster, die konsistent niedrige Scores bekommen:

Vage Anweisungen. „Schreib sauberen Code" und „folge Best Practices" geben Claude null brauchbare Information. Vergleich: „validiere Eingaben korrekt" (nutzlos) vs „Verwende Zod für alle API-Eingabevalidierung" (umsetzbar).

Keine Berechtigungsliste. Jeder Tool-Aufruf braucht manuelle Bestätigung, der Entwickler wird frustriert, gibt Claude Code auf und kommt zum Schluss, dass es nicht produktiv ist. Fünf Minuten settings.json verhindern das komplett.

Alles in CLAUDE.md gestopft. Deine Datenbank-Konventionen interessieren nicht, wenn Claude CSS bearbeitet. Verschiebe dateispezifische Anweisungen in Rules-Dateien — das hält den Kontext fokussiert und spart Tokens.

Kein Architektur-Abschnitt. Ohne Dateikarte legt Claude Dateien in falsche Verzeichnisse, verwendet falsche Import-Pfade und generiert Code, der nicht zu deinem Projekt passt. Ein 5-Zeilen-Architektur-Abschnitt verhindert das.

Kein .gitignore für lokale Einstellungen. Teammitglieder überschreiben gegenseitig ihre Präferenzen, oder schlimmer, API-Schlüssel landen in der Versionskontrolle.

Wie geht's weiter

Du hast ein solides Fundament. Deine CLAUDE.md informiert Claude über dein Projekt, deine Settings halten es produktiv, und deine Rules halten es auf Kurs.

Bereit für mehr? Hier geht's weiter:

• Automatisiere die langweilige Arbeit — Hooks die Code automatisch formatieren, Skills die mehrstufige Workflows per Slash-Befehl starten, und wann du was einsetzt
• Verbinde Claude mit deinen Tools — MCP-Server die Claude deine Datenbank abfragen lassen, GitHub-Issues durchsuchen und Sentry-Fehler direkt holen
• Halte deine Rechnung unter Kontrolle — echte Kostenzahlen, der /compact-Trick, und wann sich Opus lohnt

Häufig gestellte Fragen

Wo sollte CLAUDE.md liegen — im Projektstamm oder im .claude-Verzeichnis?

Im Projektstamm. Claude Code sucht CLAUDE.md zuerst im Root deines Arbeitsverzeichnisses. Du kannst auch ~/.claude/CLAUDE.md für globale Anweisungen erstellen, die für alle Projekte gelten. Wenn beide existieren, werden beide geladen — global zuerst, dann projektspezifisch.

Kann das ganze Team eine CLAUDE.md teilen?

Ja, und das sollte es auch. CLAUDE.md gehört in euer Repository. Es ist geteilter Kontext — Projektarchitektur, Konventionen, Befehle. Für persönliche Präferenzen (wie das bevorzugte Modell oder eigene Aliases) gibt es .claude/settings.local.json, die gitignored bleibt.

Wie lang sollte CLAUDE.md sein?

Die besten Setups in unserer Analyse liegen zwischen 100 und 500 Zeilen. Unter 100 fehlt wahrscheinlich wichtiger Kontext (Architektur, Konventionen, bekannte Probleme). Über 500 enthält wahrscheinlich Stoff, der in Rules-Dateien gehört. Das Ziel sind fokussierte, hochwertige Anweisungen.

Funktioniert Claude Code ohne all dieses Setup?

Technisch ja, aber schlecht. Ohne CLAUDE.md hat Claude kein Wissen über deine Projektstruktur, Konventionen oder Einschränkungen. Es generiert trotzdem Code, aber legt Dateien an falsche Stellen, verwendet falsche Muster und ignoriert projektspezifische Regeln. Unsere Daten zeigen: unkonfigurierte Setups erzielen durchschnittlich 1.8/10. Setup ist nicht optional, wenn du echte Produktivitätsgewinne willst.

Wie oft sollte ich CLAUDE.md aktualisieren?

Immer wenn sich dein Projekt ändert: neue Konventionen, neue Tools, neue bekannte Probleme. Eine gute Gewohnheit: jedes Mal wenn Claude einen Fehler macht der sich nicht wiederholen sollte, einen Eintrag unter „Bekannte Probleme" hinzufügen. Mit der Zeit wird CLAUDE.md so zu einem lebenden Dokument, das dieselben Fehler verhindert — und das ist einer der wertvollsten Einsatzzwecke der Datei.