CLAUDE.md Generator
Lies die Codebasis. Schreibe eine CLAUDE.md, die Claude genau das sagt, was es braucht: nicht mehr, nicht weniger.
Wichtige Regel: Eine gute CLAUDE.md ist unter 100 Zeilen lang. Sie enthält nur Informationen, die Claude nicht aus dem Lesen des Codes selbst ableiten kann. Schreibe die Datei nicht automatisch: Zeige immer zuerst den Entwurf an und warte auf die Zustimmung des Benutzers.
Code-Snippet-Regel: Füge niemals Inline-Codebeispiele in die CLAUDE.md ein. Verwende stattdessen Verweise wie datei.ts:42. Code in der CLAUDE.md verschwendet Tokens und wird schnell veraltet.
Schritt 1: Modus erkennen
Bestimme, welcher der drei Modi ausgeführt werden soll:
create: Es existiert keine CLAUDE.md. Schreibe eine von Grund auf neu. update: Eine CLAUDE.md existiert. Verbessere sie, ohne benutzerdefinierte Inhalte zu verwerfen. audit: Bewerte alle CLAUDE.md-Dateien im Projekt mit A-F und gib einen Qualitätsbericht aus. Wenn der Benutzer "audit", "prüfen", "überprüfen" oder "benoten" für meine CLAUDE.md sagt, führe den Audit-Modus aus.
# Finde ALLE CLAUDE.md-Speicherorte
find . -name "CLAUDE.md" -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null
ls ~/.claude/CLAUDE.md 2>/dev/null && echo "Globale CLAUDE.md gefunden"
ls .claude.local.md 2>/dev/null && echo ".claude.local.md gefunden"
Wenn mehrere CLAUDE.md-Dateien gefunden werden: Liste sie auf. Frage: "CLAUDE.md gefunden in [Speicherorte]. Soll ich alle aktualisieren oder nur [root]?"
Schritt 2: Audit-Modus (überspringe zu Schritt 3, wenn create/update)
Bewerte jede gefundene CLAUDE.md mit A-F anhand dieser Tabelle:
| Kriterium | Was zu prüfen ist |
|---|---|
| Befehle | Build-/Test-/Lint-Befehle vorhanden und ausführbar? |
| Architektur | Nicht offensichtliche Struktur erklärt? |
| Nicht offensichtliche Muster | Stolperfallen, generierte Dateien, Umgebungsvariablen-Reihenfolge dokumentiert? |
| Prägnanz | Unter 100 Zeilen? Kein offensichtlicher Füllstoff? |
| Aktualität | Befehle stimmen noch mit aktueller package.json/Makefile überein? |
| Handlungsfähigkeit | Kann ein neuer Beitragender dem folgen, ohne Fragen zu stellen? |
Bewertung: 90-100 = A, 70-89 = B, 50-69 = C, 30-49 = D, 0-29 = F
Präsentiere als Tabelle:
## CLAUDE.md Audit-Bericht
| Datei | Punktzahl | Note | Hauptprobleme |
|-------|-----------|------|---------------|
| ./CLAUDE.md | 72 | B | Stolperfallen-Abschnitt fehlt, Testbefehl veraltet |
| ./packages/api/CLAUDE.md | 45 | D | Keine Befehle, 340 Zeilen (zu lang), veraltete Architekturnotizen |
**Gesamt: B (72/100)**
Gefundene Probleme:
- ./packages/api/CLAUDE.md: 340 Zeilen: deutlich über dem 100-Zeilen-Ziel
- ./packages/api/CLAUDE.md: Testbefehl verweist auf `jest`, aber package.json verwendet `vitest`
- ./CLAUDE.md: Kein Stolperfallen-Abschnitt: der wertvollste Abschnitt fehlt
Nach dem Bericht frage: "Soll ich eines davon beheben? (alle / nur root / angeben)"
Wenn der Benutzer mit Ja antwortet, fahre für jede zu behebende Datei mit Schritt 3 fort.
Schritt 3: Projektstruktur scannen
# Projekttyp und Paketmanager
ls package.json yarn.lock pnpm-lock.yaml bun.lockb requirements.txt pyproject.toml Cargo.toml go.mod 2>/dev/null
# Verzeichnisstruktur der obersten Ebene
find . -maxdepth 2 -type d \
| grep -v node_modules | grep -v .git | grep -v __pycache__ \
| grep -v ".next" | grep -v dist | grep -v build | sort
Schritt 4: Build- und Testbefehle extrahieren
# npm/yarn/pnpm/bun Skripte
cat package.json 2>/dev/null \
| python3 -c "
import sys, json
d = json.load(sys.stdin)
for name, cmd in d.get('scripts', {}).items():
print(f'{name}: {cmd}')
"
# Python, Go, Rust Makefiles
cat Makefile 2>/dev/null | grep -E "^[a-z].*:" | head -20
# Go
cat go.mod 2>/dev/null | head -5
# Rust
cat Cargo.toml 2>/dev/null | grep -E "^\[" | head -10
Identifiziere die genauen Befehle für: build, test (alle), test (einzelne Datei/Name), dev-server, lint/typecheck. Notiere alle erforderlichen Umgebungsvariablen, um sie auszuführen.
Schritt 5: Codestil und Stolperfallen finden
# Import-Aliase (am häufigsten übersehen)
python3 -c "
import json, sys
try:
d = json.load(open('tsconfig.json'))
paths = d.get('compilerOptions', {}).get('paths', {})
if paths: print('Import-Aliase:', json.dumps(paths, indent=2))
except: pass
" 2>/dev/null
# Erforderliche Umgebungsvariablen
cat .env.example 2>/dev/null | grep -v "^#" | grep -v "^$" | head -20
# Automatisch generierte Dateien (dürfen nicht bearbeitet werden)
find . -path "*/node_modules" -prune -o -name "*.ts" -print \
| xargs grep -l "DO NOT EDIT\|@generated\|Generated by" 2>/dev/null | head -5
# Test-Setup-Anforderungen
cat jest.config.js jest.config.ts vitest.config.ts 2>/dev/null | head -30
# Datenbank-/Migrations-Setup
ls migrations/ prisma/ drizzle/ db/ 2>/dev/null
Was zählt als Stolperfalle (diese einfügen, alles andere weglassen):
- Dateien, die automatisch generiert werden (dürfen nicht bearbeitet werden)
- Umgebungsvariablen, die VOR Tests erforderlich sind
- Nicht standardmäßige Import-Alias-Mappings
- Testbefehle, die einen laufenden Dienst erfordern
- Bekannte absichtliche Eigenheiten (Workarounds, keine Fehler)
Schritt 6: CLAUDE.md-Entwurf mit Gemini erstellen
Fasse alle Ergebnisse zusammen und generiere den Entwurf:
cat > /tmp/claude-md-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Schreibe eine CLAUDE.md-Datei für ein Softwareprojekt. Regeln: (1) Maximal 100 Zeilen insgesamt. (2) Füge nur das ein, was Claude nicht aus dem Lesen des Codes ableiten kann. (3) Keine Inline-Codebeispiele: Verwende stattdessen Verweise wie datei.ts:42. (4) Abschnitte: Befehle, Codestil (nur nicht-standardmäßige), Testen (nur wenn Setup erforderlich), Stolperfallen (erforderlich: was Leute stolpern lässt). Überspringe jeden Abschnitt, der nichts nicht Offensichtliches zu sagen hat. (5) Alle Befehle in Codeblöcken. (6) Bevorzugte Reihenfolge: kurze Projektübersicht (1-2 Sätze, nur wenn nicht offensichtlich), Befehle, Architektur (nur nicht offensichtliche Struktur), Codestil, Testen, Stolperfallen. (7) Verwende keine Gedankenstriche. (8) Gib nur den Inhalt der CLAUDE.md aus, keinen Kommentar."
}]
},
"contents": [{
"parts": [{
"text": "PROJEKTANALYSE_HIER"
}]
}],
"generationConfig": {
"temperature": 0.3,
"maxOutputTokens": 2048
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/claude-md-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Ersetze PROJEKTANALYSE_HIER mit den Ergebnissen aus Schritt 3-5.
Für große Projekte (50+ Dateien): Füge am Ende der CLAUDE.md einen @path-Zeiger anstelle von Inline-Details ein:
## Erweiterte Referenz
Siehe @docs/ai-context/architecture.md für die vollständige Modulkarte.
Siehe @docs/ai-context/testing.md für Details zum Integrationstest-Setup.
Schreibe die referenzierten Dateien nach docs/ai-context/ mit den Details, die nicht in 100 Zeilen passen würden.
Schritt 7: Selbst-QA
Bevor du den Entwurf präsentierst, überprüfe:
- Unter 100 Zeilen (zählen:
echo "$CONTENT" | wc -l) - Keine Inline-Codebeispiele (nur
datei.ts:42-Verweise oder Shell-Befehle) - Alle Befehle in Codeblöcken und so ausführbar
- Stolperfallen-Abschnitt mit mindestens einem echten Eintrag vorhanden
- Kein Abschnitt, der nur offensichtliche Dinge aus den Dateien sagt
- Keine Gedankenstriche
- Keine Marketingwörter oder Füllphrasen ("Dieses Projekt verwendet React, um...")
- Import-Aliase dokumentiert, falls vorhanden
- Automatisch generierte Dateien mit "nicht bearbeiten" markiert, falls vorhanden
Wenn eine Überprüfung fehlschlägt, überarbeite vor der Präsentation.
Schritt 8: Entwurf präsentieren und auf Genehmigung warten
Schreibe die Datei niemals ohne Benutzerfreigabe.
Präsentiere den Entwurf in einem Codeblock:
## Entwurf CLAUDE.md ([N] Zeilen)
[vollständiger Entwurfsinhalt hier]
---
In CLAUDE.md schreiben? (ja / zuerst bearbeiten / abbrechen)
Wenn der Benutzer ja sagt: Schreibe die Datei, bestätige dann: "CLAUDE.md geschrieben ([N] Zeilen). Abschnitte: [Liste der ##-Überschriften]."
Wenn der Benutzer zuerst bearbeiten sagt: Wende seine Bearbeitungen an, zeige den Entwurf erneut.
Wenn der Benutzer abbrechen sagt: Stoppe.
Was NICHT aufgenommen werden soll
- Sprach-/Framework-Version ("Dies ist ein TypeScript-Projekt")
- Wie das Framework funktioniert (Claude kennt bereits React, FastAPI, etc.)
- Liste aller Abhängigkeiten
- Stilregeln, die der Linter bereits durchsetzt (Einrückungsgröße, Anführungszeichen-Stil)
- Inhalt, der die README.md dupliziert
- Inline-Codebeispiele oder mehrzeilige Schnipsel
- Alles, was für jedes Projekt mit dem gleichen Stack identisch wäre