Claude Code Mastery

Schritt 1: Node.js. Öffne dein Terminal, tippe node --version. Wenn dort v22 oder höher steht, weiter. Falls nicht: Mac brew install node, oder lade es von nodejs.org herunter. Verifizieren: node --version sollte v22.x.x anzeigen.

Schritt 2: VS Code oder Cursor. Lade es von code.visualstudio.com (kostenlos) oder cursor.com herunter. Installieren. Öffnen. Fertig.

Schritt 3: Claude Code CLI. In deinem Terminal: npm install -g @anthropic-ai/claude-code. Verifizieren: claude --version. Erster Start: tippe claude, melde dich an wenn du dazu aufgefordert wirst.

Schritt 4: Docker Desktop. Lade es von docker.com/products/docker-desktop herunter. Installieren. Öffnen. Es läuft im Hintergrund. Verifizieren: docker --version.

Schritt 5: GitHub. Registriere dich auf github.com. Im Terminal: git config --global user.name "Dein Name" und git config --global user.email "deine@email.com". Verifizieren: git --version.

Schritt 6: Supabase. Gehe zu supabase.com, registriere dich kostenlos, erstelle ein Projekt. Gehe zu Settings dann API. Kopiere die Projekt-URL und den Anon Key an einen sicheren Ort.

Schritt 7: Vercel. Gehe zu vercel.com, registriere dich mit GitHub. Das war's erstmal.

Verifiziere alles: node --version, npm --version, git --version, docker --version, claude --version. Alle sollten Versionsnummern zurückgeben.

Erstelle eine Datei namens CLAUDE.md im Root deines Projekts. Das ist das Betriebssystem für Claude Code.

Abschnitt 1: Aktueller Status. In welcher Phase du bist, was fertig ist, was als nächstes kommt. Aktualisiere das nach jedem Commit. Nicht nach jeder Session. Nach jedem Commit. Claude liest das zuerst und es bestimmt, was Claude priorisiert.

Abschnitt 2: Kritische Regeln. Nicht verhandelbare Einschränkungen. "Database First: Migrationen vor Code ausführen." "Keine hardcodierten Farben: CSS Custom Properties verwenden." "i18n immer: Jeder Text über next-intl." Ohne diese trifft Claude vernünftige, aber falsche Entscheidungen.

Abschnitt 3: Source of Truth. Welche Dokumente maßgebend sind. Das verhindert, dass Claude Inhalte erfindet, wenn es ein bestehendes Brief referenzieren sollte.

Abschnitt 4: Kritische Dateien. Dateien, die nicht unbedacht geändert werden sollten. Middleware, Migrationen, Design Tokens. Claude warnt, bevor es diese anfasst.

Abschnitt 5: KI-Agent-Regeln. Was Claude automatisch tut. "Nach jedem Commit: den Current Status aktualisieren." Das verwandelt Claude von einem passiven Tool in ein aktives Projektmitglied.

Test: Öffne Claude Code aus deinem Projektordner. Frage: "An welchem Projekt arbeiten wir?" Claude sollte aus deiner CLAUDE.md antworten. Wenn es das tut, funktioniert die Datei.

MCP 1: Supabase (größter Impact). Claude kann deine Datenbank abfragen, Tabellen inspizieren, RLS-Policies prüfen, Migrationen ausführen. Du hörst auf, SQL von Hand zu schreiben. Setup: npx supabase mcp setup. Es fragt nach deiner Projekt-URL und dem Service Role Key. Test: Frage Claude "Welche Tabellen gibt es in meiner Datenbank?" Es sollte sie auflisten.

Der Unterschied: Vor MCP beschreibst du Claude dein Schema. Nach MCP inspiziert Claude das tatsächliche Schema. Migrationen sind akkurat, weil Claude die Realität sieht, nicht deine Beschreibung.

MCP 2: Context7 (Dokumentation). Claude schlägt aktuelle Docs für jede Library nach. Nicht Trainingsdaten von vor Monaten. Die Docs von heute. Verifizieren: Frage Claude, eine bestimmte API von Next.js oder Supabase nachzuschlagen.

MCP 3: Vercel. Claude prüft den Deployment-Status, setzt Umgebungsvariablen, verwaltet Projekte. Echter Einsatz: "Setze die Supabase URL und den Anon Key als Vercel-Umgebungsvariablen" und Claude erledigt es. Kein Dashboard-Geklicke.

MCP 4: Figma (falls du Figma nutzt). Claude liest Design-Specs aus Figma-Dateien. Komponentengrößen, Farben, Abstände, Typografie. Exakte Werte statt Screenshots abzuschätzen.

Nach dem Setup verifizieren: Frage Claude "Auf welche MCPs hast du Zugriff?" Es sollte sie auflisten und die Verbindung bestätigen.

Erstelle den Skills-Ordner: mkdir -p .claude/skills. Skills sind Markdown-Dateien, die Claude liest wenn sie relevant sind. Auto-Skills werden bei Keyword-Erkennung ausgelöst. Manuelle Skills werden mit /skill-name aufgerufen.

Skill 1: critical. Erstelle .claude/skills/critical/SKILL.md. Schreibe deine nicht verhandelbaren Regeln: Database First, Migrationen vor Code ausführen. Keine hardcodierten Farben, CSS-Variablen verwenden. Alle Eingaben bei POST/PUT/PATCH validieren. Niemals Secrets committen. Build vor dem Committen ausführen. Füge einen Lessons-Learned-Abschnitt hinzu. Jeder Produktionsfehler wird zu einer neuen Regel hier.

Skill 2: page-build. Erstelle .claude/skills/page-build/SKILL.md. Deine Build-Konventionen: das Dateistruktur-Muster für neue Seiten, Abstands-Standards, Typografie-Regeln, Test-Anforderungen, die Commit-Checkliste.

Skill 3: eod (End of Day). Erstelle .claude/skills/eod/SKILL.md. Die Abschluss-Routine: CLAUDE.md-Status aktualisieren, geänderte Dateien stagen, mit aussagekräftiger Message committen, pushen, Zusammenfassung für morgen ausgeben.

Verifizieren: Frage Claude "Auf welche Skills hast du Zugriff?" Dann testen: "Ich möchte eine neue Seite bauen." Claude sollte automatisch deinen page-build-Mustern folgen.

Die wichtigste Erkenntnis: Skills sind Anweisungen, keine Dokumentation. Schreibe sie als Befehle: "CSS Custom Properties verwenden" nicht "Das Projekt verwendet CSS Custom Properties."

Schritt 0: Prüfe deine Umgebung. Wenn du zwischen Projekten wechselst, führe dein Check-Script aus, um zu bestätigen, dass Supabase, Vercel und Git auf das richtige Projekt zeigen. Dauert 3 Sekunden. Verhindert das "Ich habe eine Migration auf der falschen Datenbank ausgeführt"-Desaster.

Schritt 1: Öffne dein Projekt in VS Code. Öffne das Terminal. Tippe claude. Claude Code startet und liest automatisch deine CLAUDE.md. Es liest auch deine Skills, kennt also deine Muster und Regeln.

Schritt 2: Prüfe den Status. Frage Claude: "Was ist unser aktueller Status?" Es liest CLAUDE.md und sagt es dir. Wenn der Status falsch ist, korrigiere ihn jetzt.

Schritt 3: Prüfe was als nächstes kommt. "Was sind die nächsten Deliverables?" Claude liest deine Roadmap oder CLAUDE.md und listet sie auf. Jetzt wisst ihr beide, woran ihr arbeitet.

Drei Schritte. Zwei Minuten. Claude hat den vollen Kontext.

Kommst du nach einer längeren Pause zurück? Claude holt trotzdem perfekt auf. CLAUDE.md hat den Status. Die Restart-Datei hat die Notizen der letzten Session. Der Setup-Info-Skill hat die Umgebungskonfiguration. Claude liest alle drei automatisch. Nichts geht verloren.

Schritt 1: Planen vor dem Bauen. Tippe nicht "baue ein Kontaktformular." Tippe: "Ich brauche ein Kontaktformular. Bevor du Code schreibst, plane den Ansatz. Welche Komponenten? Welche API-Route? Welche Validierung? Welche Tests?" Claude schlägt vor. Du passt an. Die Qualität beim ersten Versuch steigt von 80% auf 95%.

Schritt 2: In kleinen Teilen bauen. Nicht das ganze Feature auf einmal. "Baue die Formular-Komponente." Dann "Füge Validierung hinzu." Dann "Erstelle die API-Route." Dann "Füge E-Mail-Versand hinzu." Jedes Teil ist klein genug zum Reviewen, Testen und Zurücksetzen.

Schritt 3: Unterwegs testen. Nach dem Formular-Bau: "Schreibe einen Playwright-Test, der verifiziert, dass das Formular auf allen Locales rendert und Pflichtfelder validiert." Sofort ausführen. Was fehlschlägt reparieren, bevor du weitergehst.

Schritt 4: Zweiter Durchgang. Nachdem das Feature fertig ist: "Überprüfe alles, was du gerade gebaut hast. Prüfe auf fehlende Fehlerbehandlung, inkonsistente Benennung, hardcodierte Strings, Accessibility-Probleme, Mobile-Layout-Probleme." Claude findet immer etwas. Jetzt reparieren.

Schritt 5: Committen. Spezifische Dateien stagen, nicht git add -A. Aussagekräftige Message. CLAUDE.md-Status aktualisieren.

Ein Kontaktformular dauert so 45-60 Minuten. Ohne den Prozess dauert es genauso lang, aber mit mehr Bugs, ohne Tests und mit hardcodierten Strings, die man später extrahieren muss.

Der schnelle Check (2 Minuten, vor jedem Commit): npm run build. Keine Fehler bedeutet, der Code kompiliert. Dann: npx playwright test. Alle Tests bestehen. Wenn etwas fehlschlägt, repariere es vor dem Commit. Niemals mit bekannten Fehlern committen.

Der gründliche Check (10 Minuten, am Phasenende):

1. Hardcodierte Werte. Durchsuche src/ nach Hex-Farben, hardcodierten Strings, Pixelwerten die Tokens sein sollten.

2. TypeScript-Qualität. Suche nach: any-Type (sollte ein echter Typ sein), console.log (vor dem Commit entfernen), TODO-Kommentare (tracken).

3. Sicherheits-Basics. Validiert jede API-Route die Eingaben? Gibt es Secrets in committeten Dateien? Hat jede neue Tabelle RLS?

4. i18n-Vollständigkeit. Gibt es rohe englische Strings in Komponenten? Haben alle drei Locale-Dateien die gleichen Keys?

5. Build und Test. npm run build ohne Fehler. npx playwright test alles bestanden. Localhost öffnen und visuell prüfen.

Automatisiere das: Erstelle einen Phase-Check-Skill, der alle fünf durchführt. Oder frage Claude: "Führe einen Qualitätscheck auf der Codebase durch." Claude macht alle fünf Checks.

Schritt 1: CLAUDE.md-Status aktualisieren. "Aktualisiere den Status: Kontaktseite ist fertig, Insights-Seite ist als nächstes dran."

Schritt 2: Restart-Notizen aktualisieren. "Woran haben wir heute gearbeitet? Welche Entscheidungen haben wir getroffen? Womit sollten wir morgen anfangen?" Speichere das in CLAUDE.md oder einer restart.md-Datei.

Schritt 3: Alles committen. Geänderte Dateien stagen, aussagekräftige Message, pushen.

Schritt 4: Den Push verifizieren. Prüfe, ob er erfolgreich war. Wenn du Vercel nutzt, prüfe ob das Deployment gestartet ist.

Was das verhindert: Verwirrung morgen früh ("Woran habe ich gearbeitet?"), verlorener Kontext ("Warum haben wir Zod statt yup genommen?"), uncommittete Arbeit die über Nacht rumliegt, veraltete CLAUDE.md die Claudes morgen in die Irre führt.

Der kumulative Effekt: Nach einer Woche werden deine Restart-Notizen zu einem Projekttagebuch. Nach einem Monat kannst du jede Entscheidung nachverfolgen. Nach drei Monaten liest ein neues Teammitglied die Geschichte und versteht nicht nur was gebaut wurde, sondern warum.

Skills wachsen aus Fehlern. Du deployst eine Seite mit fehlenden deutschen Übersetzungen. Neue Regel in critical: "Niemals i18n-Änderungen committen, ohne alle drei Locale-Dateien zu verifizieren." Dieser Fehler passiert nie wieder.

Skills wachsen aus Mustern. Du hast fünf Seiten mit der gleichen Struktur gebaut. Der page-build-Skill wird verfeinert: bessere Abstands-Werte, eine Test-Checkliste die fängt, was du tatsächlich übersehen hast.

Skills wachsen aus Recherche. Du entdeckst, dass getSession() dem Client-JWT ohne Überprüfung vertraut. Neue Regel in security: "Immer getUser() für Auth-Checks verwenden." Füge das Warum hinzu, damit du dich an den Grund erinnerst.

Einen neuen Skill Schritt für Schritt bauen: mkdir -p .claude/skills/i18n. Starte mit dem, was du weißt: Jeder Text über useTranslations, Keys in alle drei Locale-Dateien einfügen, Niederländisch informell (je/jij), technische Begriffe auf Englisch belassen, Namespace pro Seite. Starte mit 3 Regeln. Füge mehr hinzu, wenn du lernst.

Monatlicher Review: Lies deine Skills durch. Entferne veraltete Regeln. Fasse Duplikate zusammen. Aktualisiere, was sich weiterentwickelt hat. Gepflegte Skills sind eine lebendige Wissensbasis. Vergessene werden irreführend.

Der kumulative Effekt: Nach drei Monaten hat dein Critical-Skill 20+ Regeln. Das sind 20 Fehler, die nie wieder passieren. Jedes neue Teammitglied erbt all dein hart erkämpftes Wissen ab Tag eins.

Eine Datei pro Seite: e2e/about.spec.ts, e2e/contact.spec.ts. Jede testet vier Dinge.

1. Sie lädt. Alle drei Locales geben 200 zurück. Iteriere durch en, nl, de und verifiziere jede.

2. Der Inhalt stimmt. Wichtiger Text erscheint in der richtigen Sprache. Nicht nur "die Seite lädt", sondern "die niederländische Überschrift zeigt den richtigen Text."

3. Sie funktioniert auf Mobil. Kein horizontaler Overflow bei 375px Breite. Prüfe scrollWidth vs clientWidth.

4. Interaktive Elemente funktionieren. Formulare validieren, Navigation öffnet sich, Akkordeons klappen auf.

Wie du Claude nach Tests fragst: nicht "schreibe Tests für Kontakt", sondern "Schreibe Playwright-Tests für die Kontaktseite. Teste: 200-Status alle Locales, Formular-Validierung (leer zeigt Fehler, gültig funktioniert), responsiv bei 375px, korrekte Überschrift pro Locale." Spezifische Anfragen ergeben spezifische Tests.

Die Akkumulation: Nach 10 Seiten hast du 50+ Testfälle. npx playwright test vor einem Commit dauert 30 Sekunden und fängt Regressionen, die du manuell nie finden würdest. Refactoring wird sicher, weil Tests verifizieren, dass nichts kaputtgeht.

Die pragmatische Wahrheit: Teste Verhalten, nicht Aussehen. Designänderungen und Textanpassungen brauchen keine Tests. Formular-Submits und API-Routen schon.

Brauchst du das? Solo-Entwickler, ein Rechner: Nice to have. Mehrere Entwickler: Verhindert "funktioniert auf meinem Rechner." Deployment in Produktion: Deine Dev-Umgebung entspricht der Produktion.

Schritt 1: Erstelle Dockerfile.dev für Entwicklung mit Hot Reload. FROM node:22-alpine, WORKDIR /app, COPY Package-Dateien, RUN npm install, COPY alles, EXPOSE 3000, CMD npm run dev.

Schritt 2: Erstelle docker-compose.yml. Services: Dev-Service der aus Dockerfile.dev baut, Port 3000 mappt, deinen Code als Volume mountet (damit Änderungen sofort sichtbar sind), Umgebungsvariablen aus .env.local übergibt.

Schritt 3: Starte es. docker compose up dev. Öffne localhost:3000. Dein Projekt läuft in Docker. Ändere eine Datei in VS Code. Browser aktualisiert sich. Gleiche Erfahrung wie npm run dev, aber konsistent.

Schritt 4: Stoppe es. docker compose down.

Was gerade passiert ist: Dein Projekt läuft in einem Container mit Node 22 auf Alpine Linux, unabhängig davon, was auf deinem Rechner installiert ist. Ein Kollege klont das Repo, führt docker compose up dev aus, bekommt exakt die gleiche Umgebung.

Das Produktions-Dockerfile nutzt einen Multi-Stage Build: Base, Dependencies, Build, Runner. Die Runner-Stage nutzt einen Non-Root User und ein minimales Image. Frage Claude, eines für dein spezifisches Projekt zu generieren.

Tag 1 vs Tag 30.

CLAUDE.md: Gestartet mit 5 Regeln. Jetzt 15. Jede neue Regel hat einen Fehler verhindert, der einmal passiert ist und nie wieder. Der Current-Status-Abschnitt wurde 40+ Mal aktualisiert. Immer akkurat.

Skills: Gestartet mit 3. Jetzt 8-10. Jeder hat seine Existenz verdient, indem er ein wiederkehrendes Problem gelöst hat. Der Critical-Skill hat 15+ Lessons Learned. Neue Teammitglieder lesen ihn und überspringen die Fehler, die du schon gemacht hast.

Tests: Gestartet mit 0. Jetzt 100+. Jede Seite in allen Locales getestet. Jedes Formular validiert. Refactoring ist sicher, weil Tests Regressionen in 30 Sekunden fangen.

Täglicher Rhythmus: Das Morgenritual dauert 2 Minuten und gibt perfekten Kontext. Bauen folgt einem vorhersehbaren Muster. Qualitätschecks sind automatisch. Der Abendabschluss dauert 5 Minuten und morgen startet exakt da, wo heute aufgehört hat.

Der kumulative Effekt: Jeder Skill macht Claude smarter. Jeder Test macht Refactoring sicherer. Jedes CLAUDE.md-Update macht Kontextladen schneller. Das System hält nicht nur die Qualität. Es hebt das Niveau.

Die ehrliche Wahrheit: Nicht jede Lektion sitzt ab Tag 1. Das Morgenritual braucht eine Woche, bis es automatisch wird. Der zweite Durchgang fühlt sich teuer an, bis er einen Produktions-Bug fängt. Skills fühlen sich wie Overhead an, bis sie zum dritten Mal denselben Fehler verhindern. Gib dem Ganzen 30 Tage.