So erstellst du die perfekte CLAUDE.md (inkl. Template)

# ~/.claude/CLAUDE.md (Global)
- Verwende immer TypeScript
- Schreibe Tests mit Jest

# ~/projekt/CLAUDE.md (Projekt)
- Schreibe Tests mit Vitest  # Überschreibt Jest

# Resultat für Claude:
- Verwende immer TypeScript (von global)
- Schreibe Tests mit Vitest (von projekt)

# Terminal
mkdir -p ~/.claude
touch ~/.claude/CLAUDE.md

# Globale Entwickler-Präferenzen

## Allgemeine Regeln
- Bevorzuge TypeScript über JavaScript
- Schreibe Code auf Englisch, Kommentare auf Deutsch
- Verwende moderne ES6+ Syntax
- Keine console.log() in Production-Code

## Code-Qualität
- Schreibe sauberen, lesbaren Code
- Verwende aussagekräftige Variablennamen
- Halte Funktionen klein (max. 20 Zeilen)
- DRY-Prinzip befolgen

## Fehlerbehandlung
- Immer try-catch bei async/await
- Niemals Fehler verschlucken
- Aussagekräftige Fehlermeldungen

## Git
- Commit-Messages auf Deutsch
- Conventional Commits Format nutzen
- Niemals direkt auf main pushen

Erstelle eine CLAUDE.md für dieses Projekt. Analysiere das Projekt dafür umfassend, um nichts zu vergessen. Nutze folgende Vorlage:"

# [Projekt Name]

[Ein-Satz-Beschreibung des Projekts]

## Tech Stack
- **Framework**: [z.B. Next.js, React, Vue]
- **Sprache**: [z.B. TypeScript, Python]
- **Datenbank**: [z.B. PostgreSQL, MongoDB]
- **Styling**: [z.B. Tailwind, CSS Modules]
- **Testing**: [z.B. Jest, Vitest, Pytest]

## Projektstruktur
```
src/
├── [wichtige ordner]/   # [Beschreibung]
├── [weitere ordner]/    # [Beschreibung]
└── [config dateien]     # [Beschreibung]
```

## Entwicklung
```bash
[install befehl]         # Dependencies installieren
[dev befehl]            # Entwicklungsserver
[build befehl]          # Production Build
[test befehl]           # Tests ausführen
```

## Code-Standards
- [Standard 1, z.B. "TypeScript strict mode"]
- [Standard 2, z.B. "ESLint Regeln befolgen"]
- [Standard 3, z.B. "Keine any Types"]
- [Standard 4, z.B. "Tests für neue Features"]

## Projektspezifische Regeln
- [Regel 1, z.B. "API calls nur über services/"]
- [Regel 2, z.B. "Styling nur mit Tailwind"]
- [Regel 3, z.B. "Komponenten müssen typed sein"]

## Wichtige Hinweise
- [Hinweis 1, z.B. "Production secrets in .env.production"]
- [Hinweis 2, z.B. "Keine direkten DB queries"]
- [Hinweis 3, z.B. "Rate limiting beachten"]

## Häufige Fehler vermeiden
- NICHT: [Häufiger Fehler]
- NICHT: [Weiterer Fehler]
- IMMER: [Best Practice]
- IMMER: [Weitere Best Practice]

# KI-Blog Projekt

Next.js 15 Blog mit TypeScript, fokussiert auf KI und SEO-Themen.

## Tech Stack
- **Framework**: Next.js 15.3.3 mit App Router
- **Sprache**: TypeScript 5.x (strict mode)
- **Styling**: Tailwind CSS v4 mit PostCSS
- **UI**: Radix UI + shadcn/ui Komponenten
- **Datenbank**: PostgreSQL mit Prisma ORM

## Projektstruktur
```
src/
├── app/              # Next.js App Router
│   └── blog/         # Blog-Posts (WICHTIG: Keine /blog/ URL!)
├── components/       # React Komponenten
│   └── ui/          # shadcn/ui Komponenten
├── lib/             # Utilities und Services
└── types/           # TypeScript Types
```

## Wichtige Befehle
```bash
npm run dev          # Entwicklungsserver
npm run build        # Production Build
npm run lint         # ESLint ausführen
npm run typecheck    # TypeScript prüfen
```

## Blog-System Regeln
- Blog-Posts in src/app/blog/[slug]/page.tsx
- URLs OHNE /blog/ Prefix (Rewrite in next.config.ts)
- Immer BlogPostConfig für Metadata nutzen
- CodeBlock Komponente für alle Code-Beispiele
- FAQ Items außerhalb der Komponente definieren

## Code-Standards
- Komponenten in PascalCase
- Utilities in camelCase
- Tailwind statt CSS-Module
- Keine neuen Komponenten ohne Check in ui/
- Deutsche Inhalte, englischer Code

## Häufige Fehler vermeiden
- NICHT: Neue README.md erstellen
- NICHT: console.log in Code lassen
- NICHT: Neue UI-Komponenten von Scratch
- IMMER: Bestehende Dateien bearbeiten
- IMMER: TypeScript strict mode

## Git Workflow
- Feature-Branches von main
- PR vor Merge
- Squash Commits beim Merge

## Kontext-Regeln

### Bei Bug-Fixes
- Erst verstehen, dann fixen
- Root cause analysieren
- Regression-Test schreiben
- Changelog updaten

### Bei neuen Features
- Erst Types/Interfaces definieren
- API-First Design
- Tests parallel schreiben
- Documentation-Comments

### Bei Refactoring
- Funktionalität nicht ändern
- Tests müssen grün bleiben
- Schrittweise vorgehen
- Performance messen

## Code-Standards (Detailed)

### Naming Conventions
- Komponenten: PascalCase (UserProfile, NavBar)
- Hooks: camelCase mit 'use' prefix (useAuth, useFetch)
- Utils: camelCase (formatDate, parseJson)
- Constants: SCREAMING_SNAKE_CASE (API_URL, MAX_RETRY)
- Types/Interfaces: PascalCase mit Suffix (UserType, ApiResponse)

### Async Code
```typescript
// IMMER so:
try {
  const data = await fetchData()
  return processData(data)
} catch (error) {
  logger.error('Fetch failed:', error)
  throw new AppError('Data fetch failed', error)
}

// NIEMALS so:
fetchData().then(data => processData(data))
```

### Imports
- Absolute imports für src/ ('@/components/Button')
- Grouped imports (React, Third-party, Local)
- Named exports bevorzugen

## Datei-Locations (WICHTIG!)

### Wo neue Dateien hinkommen:
- React Components → src/components/[name]/[Name].tsx
- API Routes → src/app/api/[route]/route.ts
- Utilities → src/lib/utils/[name].ts
- Types → src/types/[name].types.ts
- Hooks → src/hooks/use[Name].ts
- Tests → [same-folder]/[name].test.ts

### Diese Ordner NICHT anfassen:
- node_modules/ (obvious, aber Claude macht's trotzdem)
- .next/ (Build output)
- dist/ (Build output)
- coverage/ (Test output)

### Bei Unsicherheit:
Frag mich IMMER bevor du neue Dateien erstellst!

# Projekt-Kern (Max 100 Zeilen)

## Must-Know (Top Priority)
- [Nur das Allerwichtigste]
- [Max 10 Punkte]

## Quick Reference
```
npm run dev
npm run build
npm run test
```

## Details siehe:
- Architecture: docs/ARCHITECTURE.md
- API: docs/API.md
- Testing: docs/TESTING.md

# Team Projekt

[... Projekt-Config ...]

---
## Changelog
- 2025-01-25: TypeScript strict mode aktiviert (FH)
- 2025-01-20: Tailwind v4 Update (MK)
- 2025-01-15: Initial version (FH)