CLAUDE.md Master-Fähigkeit (Erstellen/Aktualisieren/Verbessern)

--- name: claude-md-master description: Master-Skill für den CLAUDE.md-Lebenszyklus - Erstellen, Aktualisieren, Verbessern mit repo-verifizierten Inhalten und Multi-Modul-Unterstützung. Verwenden beim Erstellen oder Aktualisieren von CLAUDE.md-Dateien. --- # CLAUDE.md Master (Erstellen/Aktualisieren/Verbessern) ## Wann verwenden - Der Benutzer bittet darum, CLAUDE.md-Dateien zu erstellen, zu verbessern, zu aktualisieren oder zu standardisieren. ## Kernregeln - Nur Informationen einbeziehen, die im Repo oder in der Konfiguration verifiziert wurden. - Niemals Geheimnisse, Tokens, Anmeldedaten oder Benutzerdaten einbeziehen. - Niemals aufgabenspezifische oder temporäre Anweisungen einbeziehen. - Prägnant halten: Root <= 200 Zeilen, Modul <= 120 Zeilen. - Aufzählungspunkte verwenden; lange Prosa vermeiden. - Befehle müssen kopierbar sein und aus Repo-Dokumenten/Skripten/CI stammen. - Leere Abschnitte überspringen; Füllmaterial vermeiden. ## Pflichteingaben (vor der Generierung analysieren) - Build-/Paketkonfiguration relevant für den erkannten Stack (Root + Module). - Statische Analysekonfiguration, die im Repo verwendet wird (falls vorhanden). - Tatsächliche Modulstruktur und Quellmuster (reale Verzeichnisse/Dateien scannen). - Repräsentative Quellwurzeln pro Modul, um Folgendes zu extrahieren: Paket-/Funktionsstruktur, Schlüsseltypen und verwendete Annotationen. ## Erkennung (schnell + gezielt) 1. Vorhandene CLAUDE.md-Varianten lokalisieren: `CLAUDE.md`, `.claude.md`, `.claude.local.md`. 2. Stack und Einstiegspunkte über minimale Lesevorgänge identifizieren: - `README.md`, relevante `docs/*` - Build-/Paketdateien (siehe Stack-Referenzen) - Laufzeit/Konfiguration: `Dockerfile`, `docker-compose.yml`, `.env.example`, `config/*` - CI: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*` 3. Befehle nur extrahieren, wenn sie in Repo-Skripten/Konfiguration/Dokumenten vorhanden sind. 4. Multi-Modul-Struktur erkennen: - Android/Gradle: `settings.gradle` oder `settings.gradle.kts`-Includes lesen. - iOS: Mehrere Targets/Workspaces in `*.xcodeproj`/`*.xcworkspace` erkennen. - Wenn mehr als ein Modul/Target `src/` oder eine Build-Konfiguration hat, Modul-CLAUDE.md-Dateien planen. 5. Für jedes Modul-Kandidat seine Build-Datei + minimale Dokumentation lesen, um modulspezifischen Zweck, Einstiegspunkte und Befehle zu erfassen. 6. Quellwurzeln scannen auf: - Top-Level-Paket-/Funktionsordner und Schichtkonventionen. - Schlüsselannotationen/-typen in Verwendung (gemäß Stack-Referenz). - Namenskonventionen, die im Codebase verwendet werden. 7. Nicht offensichtliche Workflows/Stolperfallen aus Dokumenten oder Codemustern erfassen. Leistung: - Dateiauflistung + gezielte Lesevorgänge bevorzugen. - Vollständige Dateilesevorgänge vermeiden, wenn ein Abschnitt oder Symbol ausreicht. - Große Verzeichnisse überspringen: `node_modules`, `vendor`, `build`, `dist`. ## Stack-spezifische Referenzen (Muster 2) Die relevante Referenz nur lesen, wenn Erkennungssignale erscheinen: - Android/Gradle → `references/android.md` - iOS/Xcode/Swift → `references/ios.md` - PHP → `references/php.md` - Go → `references/go.md` - React (Web) → `references/react-web.md` - React Native → `references/react-native.md` - Rust → `references/rust.md` - Python → `references/python.md` - Java/JVM → `references/java.md` - Node-Tooling → `references/node.md` - .NET/C# → `references/dotnet.md` - Dart/Flutter → `references/flutter.md` - Ruby/Rails → `references/ruby.md` - Elixir/Erlang → `references/elixir.md` - C/C++/CMake → `references/cpp.md` - Andere/Unbekannt → `references/generic.md` (Fallback, wenn keine spezifische Referenz passt) Wenn mehrere Stacks erkannt werden, mehrere Referenzen lesen. Wenn kein Stack erkannt wird, die generische Referenz verwenden. ## Multi-Modul-Ausgaberichtlinie (obligatorisch, wenn erkannt) - Immer eine Root-`CLAUDE.md` erstellen. - Auch `CLAUDE.md` in jedem bedeutungsvollen Modul-/Target-Root erstellen. - "Bedeutungsvoll" = hat eigene Build-Konfiguration und `src/` (oder Äquivalent). - Nur-Tooling-Verzeichnisse wie `buildSrc`, `gradle`, `scripts`, `tools` überspringen. - Die Moduldatei muss modulspezifisch sein und Duplikate vermeiden: - Zweck, Schlüsselpfade, Einstiegspunkte, Modultests und Modulbefehle (falls vorhanden) einbeziehen. - Gemeinsame Informationen über `@/CLAUDE.md` referenzieren. ## Geschäftsmodul-CLAUDE.md-Richtlinie (alle Stacks) Für Monorepo-Geschäftslogik-Verzeichnisse (`src/`, `lib/`, `packages/`, `internal/`): - `CLAUDE.md` für Module mit >5 Dateien ODER eigenem README erstellen - Nur-Utility-Verzeichnisse überspringen: `Helper`, `Utils`, `Common`, `Shared`, `Exception`, `Trait`, `Constants` - Schichtstruktur nicht erforderlich; Modulinformationen unabhängig von der Architektur bereitstellen - Max. 120 Zeilen pro Modul-CLAUDE.md - Root über `@/CLAUDE.md` für gemeinsame Architektur/Muster referenzieren - Einbeziehen: Zweck, Struktur, Schlüsselklassen, Abhängigkeiten, Einstiegspunkte ## Obligatorische Ausgabeabschnitte (pro Modul-CLAUDE.md) Diese Abschnitte einbeziehen, wenn sie im Codebase erkannt werden (nur überspringen, wenn nicht vorhanden): - **Funktions-/Komponenteninventar**: Top-Level-Verzeichnisse unter der Quellwurzel auflisten - **Kern-/gemeinsame Module**: Utility-, Common- oder Shared-Code-Verzeichnisse - **Navigations-/Routing-Struktur**: Navigationsgraphen, Routen oder Router - **Netzwerk-/API-Schichtmuster**: API-Clients, Endpunkte, Antwort-Wrapper - **DI-/Injektionsmuster**: Module, Container oder Injektions-Setup - **Build-/Konfigurationsdateien**: Modulspezifische Konfigurationen (ProGuard, Manifeste usw.) Siehe Stack-spezifische Referenzen für genaue Muster zur Erkennung und Berichterstattung. ## Aktualisierungsworkflow (muss befolgt werden) 1. Nur gezielte Ergänzungen vorschlagen; Diffs pro Datei zeigen. 2. Vor dem Anwenden von Aktualisierungen um Genehmigung fragen: **Cursor IDE:** Das AskQuestion-Tool mit diesen Optionen verwenden: - id: "approval" - prompt: "Diese CLAUDE.md-Aktualisierungen anwenden?" - options: [{"id": "yes", "label": "Ja, anwenden"}, {"id": "no", "label": "Nein, abbrechen"}] **Claude Code (Terminal):** Die vorgeschlagenen Änderungen ausgeben und fragen: "Genehmigen Sie diese Aktualisierungen? (ja/nein)" Anhalten und auf die Antwort des Benutzers warten, bevor fortgefahren wird. **Andere Umgebungen (Fallback):** Wenn kein strukturiertes Fragetool verfügbar ist: 1. Vorgeschlagene Änderungen klar anzeigen 2. Fragen: "Genehmigen Sie diese Aktualisierungen? Antworten Sie mit 'ja' zum Anwenden oder 'nein' zum Abbrechen." 3. Auf explizite Benutzerbestätigung warten, bevor fortgefahren wird 3. Aktualisierungen anwenden, benutzerdefinierten Inhalt beibehalten. Wenn keine CLAUDE.md existiert, eine neue Datei zur Genehmigung vorschlagen. ## Inhaltsextraktionsregeln (obligatorisch) - Nur aus dem Codebase: - Extrahieren: verwendete Typ-/Klassen-/Annotationsnamen, reale Pfadmuster, Namenskonventionen. - Niemals: hartcodierte Werte, Geheimnisse, API-Schlüssel, geschäftsspezifische Logik. - Niemals: Codeausschnitte in Do-/Do-Not-Regeln. ## Verifizierung vor dem Schreiben - [ ] Jede Regel referenziert tatsächliche Typen/Pfade aus dem Codebase - [ ] Keine Codebeispiele in Do-/Do-Not-Abschnitten - [ ] Muster entsprechen dem, was tatsächlich im Codebase ist (nicht veraltet) ## Inhaltsregeln - Einbeziehen: Befehle, Architekturzusammenfassung, Schlüsselpfade, Tests, Stolperfallen, Workflow-Eigenheiten. - Ausschließen: generische Best Practices, offensichtliche Informationen, unverifizierte Aussagen. - `@path/to/file`-Importe verwenden, um Duplikate zu vermeiden. - Do-/Do-Not-Format ist optional; nur beibehalten, wenn bereits in der Datei verwendet. - Codebeispiele vermeiden, außer kurzen Kopier-Einfüge-Befehlen. ## Strategie für vorhandene Dateien Erkennung: - Wenn `<!-- Generated by claude-md-editor skill -->` existiert → nachfolgender Lauf - Sonst → erster Lauf Erster Lauf + vorhandene Datei: - `CLAUDE.md` → `CLAUDE.md.bak` sichern - `.bak` als Quelle verwenden und nur wiederverwendbare, projektspezifische Informationen extrahieren - Eine neue prägnante Datei generieren und den Marker hinzufügen Nachfolgender Lauf: - Benutzerdefinierte Abschnitte und Formulierungen beibehalten, es sei denn, sie sind veraltet oder falsch - Nur aktualisieren, was mit dem aktuellen Repo-Zustand kollidiert - Fehlende Abschnitte nur hinzufügen, wenn sie echten Mehrwert bieten `.claude.local.md` niemals ändern. ## Ausgabe Nach Aktualisierungen einen prägnanten Bericht ausgeben: ``` ## CLAUDE.md-Aktualisierungsbericht - /CLAUDE.md [ERSTELLT | GESICHERT+ERSTELLT | AKTUALISIERT] - /<modul>/CLAUDE.md [ERSTELLT | AKTUALISIERT] - Sicherungen: alle `.bak`-Dateien auflisten ``` ## Validierungscheckliste - Beschreibung ist spezifisch und enthält Auslösebegriffe - Keine Platzhalter verbleiben - Keine Geheimnisse enthalten - Befehle sind real und kopierbar - Bericht-zuerst-Regel eingehalten - Referenzen sind eine Ebene tief