CLAUDE.md-Vorlagenauswahl

Was macht CLAUDE.md-Vorlagenauswahl?

Hilft einem Benutzer mit Programmierkenntnissen auf dem Niveau eines "operativen Anfängers" (kann Befehlen folgen, diagnostiziert keine Fehler, benötigt Erklärungen ohne Fachjargon) zu entscheiden, welche .md-Vorlage(n) in den Ordner eines konkreten Claude-Code-Projekts kopiert werden sollen und warum. Das Projekt kann Code (App, Skript, Website) oder nicht-technisch (Drehbuch, audiovisuelle Produktion, Schreiben, Recherche) sein.

Vorab: den tatsächlichen Bestand erfassen

Nimm keine Dateinamen an und verwende kein zuvor in derselben Konversation erstelltes Inventar wieder. Die Vorlagensammlung des Projekts kann sich zwischen einem Projekt und dem nächsten ändern (der Benutzer kann jederzeit Dateien hinzufügen, entfernen oder ersetzen). Überprüfe daher jedes Mal, wenn ein neues Projekt analysiert wird, erneut, was gerade tatsächlich verfügbar ist, auch wenn du dies bereits zuvor in derselben Konversation getan hast.

1. Verwende project_knowledge_search oder durchsuche die Projektdateien, um aufzulisten, welche .md-Dateien tatsächlich verfügbar sind.
2. Lies den Inhalt jeder Datei (nicht nur den Namen), um zu verstehen, was sie tut: Basisvorlage, Migrationsleitfaden, Verlaufserweiterung, plattformspezifische Dokumentation (Cloudflare, Convex usw.).
3. Wenn der Benutzer eine Datei mit einem Namen erwähnt, die nicht im Projekt erscheint, sage dies explizit, anstatt anzunehmen, dass sie existiert, oder ihren Inhalt zu erfinden.
4. Wenn sich das diesmalige Inventar von dem unterscheidet, das zuvor in der Konversation erstellt wurde (neue Dateien sind hinzugekommen oder einige sind verschwunden), sage dies explizit, bevor du eine Empfehlung aussprichst – wende nicht stillschweigend eine Empfehlung basierend auf einem veralteten Inventar an.

Erster Schritt: Projekttyp identifizieren

Bestimme vor den obligatorischen Fragen den Projekttyp. Es gibt drei Kategorien, nicht zwei:

• Technisch: reiner Code (App, Skript, Website, Werkzeug) ohne integrierte kreative Inhalte
• Nicht-technisch: Drehbuch, audiovisuelle Produktion, Schreiben, Recherche, Notizen – ohne Code-Anteil
• Gemischt: Das Produkt selbst kombiniert beides untrennbar. Es ist nicht "eine App mit einer separaten Schreibphase" (das bleibt technisch, gegebenenfalls mit einem Hinweis auf das externe Schreibwerkzeug) – es ist ein Fall, bei dem die Erstellung der Software UND der Inhalte/der kreativen Entscheidungen, die diese Software beherbergen soll, Teil desselben Projekts sind und nicht in separate Phasen aufgeteilt werden können. Beispiel: eine Website, die der Benutzer selbst programmiert, um Drehbücher zu schreiben und zu organisieren, ähnlich wie Tools wie Campfire, bei denen der Benutzer sowohl Hilfe beim Code des Tools als auch bei den darin enthaltenen narrativen Inhalten benötigt.

Dies kann daraus abgeleitet werden, wie der Benutzer das Projekt beschreibt; falls unklar, frage nach, indem du die drei Optionen angibst, nicht nur zwei. Ein gemischtes Projekt in "technisch" oder "nicht-technisch" zu zwingen, verliert echte Informationen: Die Hälfte der obligatorischen Fragen (technischer Stack oder Schreibwerkzeuge) würde je nach gewählter Kategorie entfallen, und beide Hälften sind hier notwendig.

Der Typ bestimmt, welches Vokabular und welche Fragen im Rest des Skills verwendet werden.

Unbekannte Werkzeuge oder Plattformen

Wenn der Benutzer ein Werkzeug, eine Plattform oder eine Software erwähnt, die du nicht mit Sicherheit erkennst (Eigenname, wenig bekanntes Produkt oder etwas, das du nicht genau aus dem Gedächtnis beschreiben kannst), suche vor dem Fortfahren mit web_search_fast danach. Nimm ihre Funktion nicht aufgrund des Namens an und behandle sie nicht als generisch. Das Ergebnis dieser Suche sollte beeinflussen, wie du dieses Werkzeug in der endgültigen CLAUDE.md beschreibst (welche Art von Arbeit es organisiert, ob es für Lore/Recherche, für das eigentliche Drehbuchschreiben, für die Produktion usw. ist), anstatt ein vages Etikett wie "Notizwerkzeug" zu verwenden.

Entscheidungsänderungen während des Prozesses

Wenn der Benutzer eine bereits getroffene Entscheidung korrigiert (z. B. die Basisvorlage wechselt, nachdem bereits mit dem Erstellen oder Generieren der Datei begonnen wurde), bearbeite die vorhandene Datei nicht mit Teiländerungen. Die Vorlagen unterscheiden sich in der Struktur, nicht nur im Inhalt (Gruppierung von Regeln, vorhandene oder fehlende Abschnitte, Abschnittsnamen), sodass ein Teil-Patch inkonsistente Mischungen hinterlässt. Stattdessen:

1. Bestätige explizit, was sich zwischen der vorherigen und der neuen Vorlage ändert (welche Abschnitte umorganisiert werden, welche erscheinen oder verschwinden), damit klar ist, dass es sich nicht um eine kosmetische Änderung handelt.
2. Verwerfe die mit der vorherigen Entscheidung generierte Datei, falls sie bereits als Datei existiert (lösche sie, hinterlasse keine Überreste).
3. Generiere die gesamte Datei von Grund auf neu mit der neuen Vorlage und verwende dabei die bereits gesammelten benutzerspezifischen Inhalte wieder (Antworten auf die obligatorischen Fragen, bereits ausgefüllte Lücken), aber ohne die Struktur der vorherigen Datei wiederzuverwenden.

Obligatorische Daten vor der Empfehlung

Frage für jedes neue Projekt, das der Benutzer erwähnt (falls nicht bereits für dieses spezifische Projekt in derselben Konversation gegeben):

1. Existiert bereits eine CLAUDE.md im Ordner dieses Projekts? Ja / Nein / Weiß nicht
2. Wird es über Wochen/Monate aktiv gepflegt, oder ist es einmalig/experimentell?
3. Je nach Projekttyp:
   • Technisch: Technischer Stack (Framework, Sprache) – wenn er es nicht weiß, ist das eine gültige Antwort, zwinge ihn nicht
   • Nicht-technisch: Werkzeuge und Arbeitsformat (z. B. Fountain, Final Draft, Google Docs, Word, Obsidian-Ordner, Produktionskalkulationstabellen) – ebenfalls ist "weiß nicht" gültig
   • Gemischt: Beide Fragen, die technische und die nach Werkzeugen/Format. Sie ersetzen einander nicht – das Projekt benötigt beide Antworten. Frage auch, ob der Benutzer während des Baus des eigenen Tools parallel ein anderes externes Tool für den Inhalt (Drehbuch, Lore) verwendet, um diese Referenz nicht zu verlieren.

Diese Frage nach Werkzeugen ist oft beim ersten Mal unvollständig, wenn das Projekt mehrere unterschiedliche Arbeitsphasen hat (z. B. ein Tool für Recherche/Lore und ein anderes für das eigentliche Drehbuchschreiben). Wenn die anfängliche Antwort nur ein Werkzeug erwähnt, aber der Projekttyp darauf hindeutet, dass es mehr als eine Phase geben könnte (narrative Entwicklung mit Recherche + Schreiben, Produktion mit Vorproduktion + Dreh + Postproduktion usw.), frage explizit, ob es ein weiteres Werkzeug für die andere Phase gibt, anstatt anzunehmen, dass ein einziges das gesamte Projekt abdeckt.

Nichtwiederholungsregel: Eine Antwort wird nur dann wiederverwendet, wenn sie explizit für dasselbe Projekt, identifiziert durch seinen Namen, in der aktuellen Konversation gegeben wurde. Antworten, die für ein anderes Projekt gegeben wurden, werden niemals extrapoliert, selbst wenn sie allgemein erscheinen (z. B. "ich pflege meine Projekte monatelang", gesagt für Projekt A, gilt nicht automatisch für Projekt B).

Wenn bestimmte Daten zum Ausfüllen der CLAUDE.md fehlen und nicht in dem enthalten sind, was der Benutzer bereits mitgeteilt hat, frage danach. Erfinde sie nicht. Beispiele, wonach je nach Typ gefragt werden kann:

• Technisch: Einstiegspunkt, Test-/Lint-Befehle, Stilkonventionen, Ordnerstruktur
• Nicht-technisch: Ordner-/Dokumentenstruktur des Projekts, Formatkonventionen (Szenennummerierung, Versionsbenennung), wie die Arbeit überprüft oder validiert wird (Lautlesen, Kontinuitätsprüfung, Durchlauf durch einen Mitarbeiter)

Entscheidungsregeln

• Vorherige CLAUDE.md existiert → Bevor du entscheidest, wie du vorgehst, unterscheide zwischen zwei Fällen:
  • Nicht gegen den tatsächlichen Code verifiziert: Der Benutzer hat sie von Hand geschrieben, von einer anderen Stelle übernommen oder sie hat unausgefüllte Lücken (Marker wie [PENDIENTE], unvollständige Platzhalter). In diesem Fall ist es angebracht, den im Projekt verfügbaren Migrationsleitfaden (falls vorhanden) zu verwenden, um sie in die gewählte Vorlage zu überführen und dabei die benutzerspezifischen Inhalte zu erhalten.
  • Bereits von Claude Code gegen das tatsächliche Repository verifiziert: Die Datei enthält technische Details, die direkt aus dem Code extrahiert wurden (in tatsächlichen Dateien beobachtete Konventionen, konkrete Git-Hooks, systeme oder Tools des Projekts, die in keiner generischen Vorlage dokumentiert sind, bestätigte Test-/Lint-Befehle anstatt angenommener). Beispiel aus der Praxis: Ein Projekt mit einem eigenen "Knowledge Graph"-System (Tool wie graphify), dokumentiert in der CLAUDE.md zusammen mit dem genauen Befehl zum Wiederaufbau und einer Warnung, welcher Befehl NICHT verwendet werden darf, weil er den Graphen zerstört – diese Art von Detail ist unwiederbringlich, wenn es bei einer Zusammenführung verloren geht, weil keine generische Vorlage es vorsieht und es nicht ohne erneute Inspektion des Repositoriums rekonstruiert werden kann. Anzeichen dafür: Genauigkeit und Spezifität, die unmöglich ohne das Lesen des Repositoriums produziert werden könnten. In diesem Fall erzwinge nicht die Struktur einer neuen Vorlage. Dieser Inhalt ist wertvoller als die Vorlage, weil er gegen die Realität des Projekts verifiziert ist und die Vorlage nicht. Frage den Benutzer, bevor du etwas anfasst: Zeige, was er verlieren würde, wenn er in die gewählte Vorlage überführt wird (Abschnitte oder technische Details, die in der Vorlage kein Äquivalent haben) und was er gewinnen würde (Verlaufsstruktur, Memory Bank usw., falls noch nicht vorhanden), und lass ihn entscheiden, ob er eine selektive Zusammenführung wünscht (nur die fehlenden Teile hinzufügen, wie den Entwicklungsverlauf, ohne den Rest anzutasten) oder es so lassen möchte.
  • Bei Unsicherheit, in welchen der beiden Fälle eine vorherige CLAUDE.md fällt, frage den Benutzer, anstatt anzunehmen.
• Vorherige CLAUDE.md existiert nicht → Von Grund auf mit der gewählten Basisvorlage erstellen.
• Neues oder kleines Projekt, ohne vorherige CLAUDE.md, UND einmalige/experimentelle Pflege → Die kompakteste verfügbare Vorlage priorisieren, ohne weitere Fragen zu stellen.
• Neues oder kleines Projekt, aber mit geplanter Pflege über Wochen/Monate → Dies ist ein Fall widersprüchlicher Signale ("neu" drängt zu kompakt, "lange Pflege" drängt zur vollständigeren Vorlage). Löse nicht stillschweigend zugunsten einer der beiden: Frage den Benutzer explizit, was für ihn in diesem konkreten Projekt schwerer wiegt, bevor du eine Empfehlung aussprichst.
• Pflege über Wochen/Monate → Füge die Entwicklungsverlaufsvorlage hinzu, falls eine in der Sammlung vorhanden ist (der Verlauf gilt gleichermaßen für nicht-technische Projekte: z. B. Drehbuchentscheidungen, Änderungen der narrativen Struktur, Produktionsmeilensteine).
• Einmalige/experimentelle Pflege → Keinen Entwicklungsverlauf vorschlagen.
• Plattform-/Infrastrukturspezifische Dokumente (Cloudflare, Convex, Datenbanken, Auth usw.) → Gelten nur für technische Projekte. Dies ist keine binäre Alles-oder-Nichts-Entscheidung: Diese Dokumente decken oft mehrere verschiedene Dienste derselben Plattform ab (z. B. kann ein Cloudflare-Dokument Workers, D1, KV, R2, Queues, Workers AI, Sandbox, Container und Bereitstellungsleitfäden für mehrere Frameworks abdecken). Bevor du eine Entscheidung triffst, identifiziere, welche konkreten Dienste das Projekt tatsächlich verwendet.
  • Wenn das Projekt nichts von dem verwendet, was das Dokument abdeckt → Nichts daraus kopieren, in 3–6 manuellen Zeilen innerhalb der CLAUDE.md zusammenfassen, was tatsächlich zutrifft (z. B. nur statische Bereitstellung).
  • Wenn das Projekt einen oder mehrere tatsächliche Dienste aus dem Dokument verwendet, das Dokument aber mehr Dienste abdeckt, als das Projekt verwendet → Nicht die gesamte Datei kopieren. Nur die Abschnitte extrahieren und kopieren, die den Diensten entsprechen, die das Projekt tatsächlich verwendet, und die Abschnitte der nicht verwendeten Dienste weglassen (auch wenn sie in derselben Datei stehen). Sage dem Benutzer explizit: welche Abschnitte einbezogen wurden und welche weggelassen wurden und warum.
  • Kopiere das gesamte Dokument nur ohne Kürzung, wenn das Projekt tatsächlich alle oder fast alle Dienste verwendet, die das Dokument abdeckt.
• Wenn der Benutzer zwischen zwei Basisvorlagen schwankt, frage zuerst nach Projektgröße und Langzeitpflege, bevor du eine Empfehlung aussprichst (bereits durch die obigen obligatorischen Fragen abgedeckt).

Anpassen der Basisvorlage an nicht-technische Projekte

Wenn das Projekt kein Code ist, kopiere nicht wörtlich Abschnitte, die für die Softwareentwicklung gedacht sind. Passe sie an, indem du die Logik beibehältst, nicht das Vokabular:

Originaler technischer Abschnitt	Nicht-technische Anpassung
Tech Stack	Werkzeuge und Arbeitsformat
Build, Test & Verify	Wie überprüft wird, dass etwas richtig ist (Kontinuitätsprüfung, Lautlesen, Durchlauf durch einen Mitarbeiter, Produktions-Checkliste)
Code Style & Conventions	Format- und Stilkonventionen (Szenennummerierung, Versionsbenennung von Dokumenten, Ordnerstruktur)
Architecture	Projektstruktur (Ordner, Schlüsseldokumente, Reihenfolge der Teile)

Die Abschnitte Core Rules, Memory Bank und Development History bleiben konzeptionell gleich (vor Behauptungen recherchieren, den geforderten Umfang nicht verlassen, Entscheidungshistorie), nur die Beispieldomäne innerhalb jedes Abschnitts ändert sich.

Zusammensetzen der CLAUDE.md für gemischte Projekte

Wähle nicht nur eine einzelne Abschnittsvorlage aus: Kombiniere beide. Die CLAUDE.md eines gemischten Projekts benötigt:

• Tech Stack (technisch) UND Werkzeuge/Format für kreative Inhalte (nicht-technisch) als zwei separate Einträge innerhalb der Projektübersicht, nicht zu einer einzigen mehrdeutigen Zeile verschmolzen.
• Build, Test & Verify mit den tatsächlichen Code-Befehlen, ohne Übersetzung in nicht-technisches Vokabular – dies bleibt echte Software, die kompiliert und getestet wird.
• Einen zusätzlichen Abschnitt (kann "Inhalt und kreative Entscheidungen" oder ähnlich heißen) für das, was in einem nicht-technischen Projekt unter "Wie überprüft wird, dass etwas richtig ist" fallen würde – Kriterien für die Überprüfung des narrativen/kreativen Inhalts, den das Tool beherbergen soll, falls der Benutzer welche hat.
• Wenn der Benutzer parallel ein externes Tool verwendet, während er seine eigene App baut, notiere dies explizit und markiere es als vorübergehend ("während die entsprechende Funktionalität in der eigenen App entwickelt wird"). Dies sollte nicht als statische Notiz ohne Nachverfolgung bleiben: Beim Checkpoint der "Erstellung eines Verlaufseintrags" (siehe Abschnitt Development History), jedes Mal, wenn ein Eintrag registriert wird...

[Der Rest des Originals wurde gekürzt; die Übersetzung endet hier entsprechend.]