template-picker-code (Claude Code)

Selektor für CLAUDE.md-Vorlagen (Claude Code)

Hilft einem Benutzer mit dem Coding-Level „operativer Anfänger“ (kann Befehle befolgen, diagnostiziert keine Fehler, braucht Erklärungen ohne Fachjargon als gegeben) bei der Entscheidung, welche .md-Vorlage(n) in den Ordner eines konkreten Projekts kopiert werden sollen und warum. Das Projekt kann Code (App, Skript, Website) oder nicht technisch sein (Drehbuch, audiovisuelle Produktion, Schreiben, Recherche). Im Gegensatz zur Version dieser Skill für claude.ai gibt es hier echten Dateisystemzugriff: Der Vorlagenordner kann gelesen, das Zielprojekt untersucht und die endgültigen Dateien geschrieben werden, ohne dass der Benutzer sie von Hand kopieren muss.

Pfad zum Vorlagenordner

Es gibt keinen Standardpfad für die Vorlagensammlung: Suche danach in den Benutzeranweisungen oder in seinem CLAUDE.md. Wenn es dort nicht erscheint, der Benutzer einen anderen Pfad erwähnt oder dieser Pfad bei Überprüfung nicht existiert, frage nach dem richtigen Pfad, anstatt einen anzunehmen oder zu erfinden. Gehe nicht davon aus, dass der Ordner noch denselben Inhalt hat wie beim letzten Mal: Lies ihn immer neu ein, wenn du mit einem neuen Projekt beginnst (siehe nächster Abschnitt).

Vorab: Bestandsaufnahme des tatsächlichen Inhalts

Gehe nicht von Dateinamen aus und verwende keine zuvor in derselben Sitzung erstellte Bestandsaufnahme erneut. Die Vorlagensammlung im lokalen Ordner kann sich zwischen einem Projekt und dem nächsten ändern (der Benutzer kann jederzeit Dateien hinzufügen, entfernen oder ersetzen, sogar außerhalb dieser Unterhaltung). Analysiere daher jedes Mal, wenn ein neues Projekt besprochen wird, den Vorlagenordner sofort neu, auch wenn dies bereits in derselben Sitzung geschehen ist.

1. Liste den Inhalt des Vorlagenordners auf (ls oder Äquivalent), um zu sehen, 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, plattformspezifisches Dokument (Cloudflare, Convex usw.).
3. Wenn der Benutzer eine Datei namentlich erwähnt, die nicht im Ordner erscheint, sage dies explizit, anstatt anzunehmen, dass sie existiert, oder ihren Inhalt zu erfinden.
4. Wenn sich die diesmalige Bestandsaufnahme von einer früheren in der Sitzung unterscheidet (neue Dateien sind hinzugekommen oder einige fehlen), sage dies explizit, bevor du eine Empfehlung aussprichst – wende nicht stillschweigend eine Empfehlung an, die auf einer veralteten Bestandsaufnahme basiert.

Erster Schritt: Identifiziere den Projekttyp

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

• Technisch: reiner Code (App, Skript, Website, Werkzeug) ohne integrierte kreative Inhaltskomponente
• Nicht technisch: Drehbuch, audiovisuelle Produktion, Schreiben, Recherche, Notizen – ohne Code-Komponente
• Gemischt: Das Produkt selbst kombiniert beides untrennbar. Es ist nicht „eine App mit einer separaten Schreibphase“ (das bleibt technisch, ggf. mit einer Notiz zum externen Schreibwerkzeug) – es ist ein Fall, bei dem das Erstellen der Software UND der Inhalt/die kreativen Entscheidungen, die diese Software beherbergen wird, Teil desselben Projekts sind und nicht in separate Phasen getrennt 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 beim narrativen Inhalt darin benötigt.

Mit Dateisystemzugriff kann der Projekttyp teilweise auch durch die Inspektion des Zielordners abgeleitet werden: Das Vorhandensein von package.json, Quellcodedateien usw. deutet auf eine technische Komponente hin; das völlige Fehlen davon zusammen mit Textdokumenten, Drehbüchern oder Notizen deutet auf nicht technisch hin. Aber die Code-Inspektion ersetzt nicht die Frage an den Benutzer, wenn das Ergebnis mehrdeutig ist – bestätige mit ihm, bevor du die Kategorie annimmst.

Der Typ bestimmt, welches Vokabular und welche Fragen im Rest der Skill verwendet werden.

Unbekannte Tools oder Plattformen

Wenn der Benutzer ein Tool, 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), und wenn in dieser Claude-Code-Sitzung ein Websuch-Tool verfügbar ist, suche danach, bevor du fortfährst. Wenn keine Websuche verfügbar ist, sage dies explizit und bitte den Benutzer um eine kurze Beschreibung, was das Tool tut, anstatt seine Funktion aus dem Namen abzuleiten. Das Ergebnis sollte bestimmen, wie du dieses Tool im endgültigen CLAUDE.md beschreibst (welche Art von Arbeit es organisiert, ob es für Überlieferungen/Recherche, für das eigentliche Drehbuchschreiben, für die Produktion usw. ist), anstatt ein vages Etikett wie „Notiz-Tool“ zu verwenden.

Entscheidungsänderungen während des Prozesses

Wenn der Benutzer eine bereits getroffene Entscheidung korrigiert (z. B. nachdem die Datei bereits zusammengestellt oder sogar auf die Festplatte geschrieben wurde, die Basisvorlage wechselt), bearbeite die vorhandene Datei nicht mit Teiländerungen. Vorlagen unterscheiden sich in der Struktur, nicht nur im Inhalt (Gruppierung von Regeln, vorhandene oder fehlende Abschnitte, Abschnittsnamen), daher hinterlässt ein halber Patch inkonsistente Mischungen. Stattdessen:

1. Bestätige explizit, was sich zwischen der alten und der neuen Vorlage ändert (welche Abschnitte neu organisiert werden, welche erscheinen oder verschwinden), damit klar ist, dass es sich nicht um eine kosmetische Änderung handelt.
2. Wenn die Datei mit der vorherigen Entscheidung bereits auf die Festplatte geschrieben wurde, hole die Zustimmung des Benutzers ein, bevor du sie überschreibst oder löschst – lösche keine Dateien aus dem Projekt des Benutzers ohne seine ausdrückliche Zustimmung, selbst wenn sie von dieser Skill vor einem Moment erstellt wurden.
3. Generiere die Datei komplett von Grund auf mit der neuen Vorlage neu, wobei der bereits gesammelte benutzerspezifische Inhalt wiederverwendet wird (Antworten auf die obligatorischen Fragen, bereits ausgefüllte Lücken oder das, was durch das Lesen des eigentlichen Codes abgeleitet werden konnte), aber ohne die Struktur der vorherigen Datei wiederzuverwenden.

Obligatorische Daten vor der Empfehlung

Für jedes neue Projekt, das der Benutzer erwähnt, frage (wenn sie nicht bereits für dieses konkrete Projekt in derselben Sitzung gegeben wurden und wenn sie nicht durch das Lesen des echten Projekts bestimmt werden können):

1. Existiert bereits ein CLAUDE.md im Ordner dieses Projekts? Überprüfe dies direkt, indem du den Zielordner auflistest, anstatt zu fragen – frage nur, wenn der Pfad des Zielprojekts nicht klar ist.
2. Wird es über Wochen/Monate aktiv gepflegt, oder ist es einmalig/experimentell? Dies kann nicht aus dem Code abgeleitet werden, sondern muss gefragt werden.
3. Abhängig vom Projekttyp:
   • Technisch: Technologie-Stack (Framework, Sprache) – versuche, dies zuerst durch Lesen von package.json, requirements.txt, Cargo.toml, build.gradle oder einem anderen Abhängigkeitsmanifest im Zielordner abzuleiten, bevor du fragst. Wenn keines vorhanden ist oder das Projekt leer ist, frage; „Ich weiß es noch nicht“ ist immer noch eine gültige Antwort.
   • Nicht technisch: Werkzeuge und Arbeitsformat (z. B. Fountain, Final Draft, Google Docs, Word, Obsidian-Ordner, Produktionskalkulationstabellen) – dies kann nicht zuverlässig aus dem Dateisystem abgeleitet werden, frage danach. „Ich weiß es nicht“ ist gültig.
   • Gemischt: Beide Fragen, die technische (versuche zuerst, sie wie im technischen Fall abzuleiten) und die nach Werkzeugen/Format (gefragt). Sie ersetzen einander nicht – das Projekt benötigt beide Antworten. Frage auch, ob der Benutzer, während er das eigene Tool baut, parallel ein weiteres externes Tool für den Inhalt (Drehbuch, Überlieferungen) verwendet, um diese Referenz nicht zu verlieren.

Diese Frage zu Werkzeugen ist bei der ersten Antwort oft unvollständig, wenn das Projekt mehrere unterschiedliche Arbeitsphasen hat (z. B. ein Tool für Recherche/Überlieferungen und ein anderes für das eigentliche Drehbuchschreiben). Wenn die anfängliche Antwort nur ein Tool erwähnt, der Projekttyp aber nahelegt, dass es mehr als eine Phase geben könnte, frage explizit, ob es ein separates Tool für die andere Phase gibt, anstatt anzunehmen, dass ein einziges das gesamte Projekt abdeckt.

Regel zur Nichtwiederholung: Eine Antwort wird nur wiederverwendet, wenn sie explizit für dasselbe Projekt, identifiziert durch Namen oder Pfad, in der aktuellen Sitzung gegeben wurde. Antworten, die für ein anderes Projekt gegeben wurden, werden niemals extrapoliert, selbst wenn sie allgemein erscheinen.

Wenn ein bestimmtes Datum zum Ausfüllen des CLAUDE.md fehlt und weder durch Fragen noch durch Lesen des echten Codes bestimmt werden kann, markiere es als ausstehend. Erfinde es nicht. Beispiele, was je nach Typ zu fragen oder zu inspizieren ist:

• Technisch: Einstiegspunkt (suche im Abhängigkeitsmanifest oder in Build-Konfigurationsdateien, bevor du fragst), Test-/Lint-Befehle (lese Skripte im Manifest), Stilkonventionen (inspiziere echten Code, falls vorhanden), Ordnerstruktur (liste direkt auf)
• Nicht technisch: Ordner-/Dokumentstruktur des Projekts (liste direkt auf), Formatkonventionen (Szenennummerierung, Versionsbenennung – frage), wie die Arbeit überprüft oder validiert wird (frage)

Entscheidungsregeln

• CLAUDE.md existiert bereits → bevor du entscheidest, wie du vorgehst, unterscheide zwischen zwei Fällen:
  • Nicht gegen den echten Code verifiziert: Der Benutzer hat es von Hand geschrieben, von einer anderen Stelle übernommen, oder es hat unausgefüllte Lücken (Marker wie [AUSSTEHEND], unvollständige Platzhalter). In diesem Fall kann der Migrationsleitfaden im Vorlagenordner (falls vorhanden) verwendet werden, um es in die gewählte Vorlage zu überführen, wobei der benutzerspezifische Inhalt erhalten bleibt.
  • Bereits gegen das echte Repository verifiziert (durch eine frühere Claude-Code-Sitzung oder weil die darin enthaltenen Details zu spezifisch sind, um ohne Lesen des Codes geschrieben worden zu sein): Die Datei enthält technische Details, die direkt aus dem Code extrahiert wurden (in echten Dateien beobachtete Konventionen, konkrete Git-Hooks, Systeme oder Tools des Projekts, die in keiner generischen Vorlage dokumentiert sind, bestätigte statt vermutete Test-/Lint-Befehle). Mit Dateisystemzugriff kann dies wirklich bestätigt werden: Vergleiche, was das CLAUDE.md sagt, mit dem echten Code (existieren die Dateien und Befehle, die es erwähnt? Stimmen die beschriebenen Konventionen mit dem überein, was im Code ist?). Reales Beispiel: Ein Projekt mit einem eigenen „Knowledge-Graph“-System, dokumentiert im 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. In diesem Fall erzwinge nicht die Struktur einer neuen Vorlage darüber. Dieser Inhalt ist wertvoller als die Vorlage, weil er gegen die Realität des Projekts verifiziert wurde und die Vorlage nicht. Frage den Benutzer, bevor du etwas anfasst: Zeige, was er verlieren würde, wenn es in die gewählte Vorlage zusammengeführt wird, und was er gewinnen würde, und lass ihn entscheiden, ob er eine selektive Zusammenführung oder den aktuellen Zustand beibehalten möchte.
  • Wenn Zweifel bestehen, in welchen der beiden Fälle ein vorhandenes CLAUDE.md fällt, frage den Benutzer, anstatt anzunehmen.
• CLAUDE.md existiert nicht → erstelle es von Grund auf mit der gewählten Basisvorlage.
• Neues oder kleines Projekt, ohne vorhandenes CLAUDE.md, UND einmalige/experimentelle Pflege → priorisiere die vorhandene kompakteste Vorlage, 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 dies nicht stillschweigend zugunsten einer der beiden Optionen: Frage den Benutzer explizit, was für ihn in diesem konkreten Projekt schwerer wiegt, bevor du eine Empfehlung ausspricht.
• Pflege über Wochen/Monate → füge die Entwicklungsverlaufs-Vorlage hinzu, falls eine im Vorlagenordner vorhanden ist (der Verlauf gilt gleichermaßen für nicht-technische Projekte).
• Einmalige/experimentelle Pflege → schlage keinen Entwicklungsverlauf vor.
• 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. Bevor du entscheidest, identifiziere, welche konkreten Dienste das Projekt tatsächlich verwendet – mit Dateisystemzugriff kann dies durch Lesen des Abhängigkeitsmanifests oder echter Konfigurationsdateien (z. B. wrangler.toml, im Code verwendete Umgebungsvariablen) bestätigt werden, anstatt nur zu fragen.
  • Wenn das Projekt nichts von dem verwendet, was das Dokument abdeckt → kopiere nichts davon, fasse in 3–6 manuellen Zeilen im CLAUDE.md zusammen, was tatsächlich zutrifft.
  • Wenn das Projekt einen oder mehrere reale Dienste aus dem Dokument verwendet, das Dokument aber mehr Dienste abdeckt, als das Projekt verwendet → kopiere nicht die gesamte Datei. Extrahiere und kopiere nur die Abschnitte, die den tatsächlich vom Projekt verwendeten Diensten entsprechen, und lasse die Abschnitte der nicht verwendeten Dienste weg. Sage es dem Benutzer explizit: Welche Abschnitte wurden aufgenommen und welche weggelassen und warum.
  • Kopiere das gesamte Dokument nur ungekürzt, wenn das Projekt tatsächlich alle oder fast alle Dienste verwendet, die das Dokument abdeckt.
• Wenn der Benutzer zwischen zwei Basisvorlagen zögert, frage zuerst nach Projektgröße und Langzeitpflege, bevor du eine Empfehlung ausspricht (bereits durch die obigen Pflichtfragen abgedeckt).

Anpassen der Basisvorlage an nicht-technische Projekte

Wenn das Projekt kein Code-Projekt ist, kopiere nicht wörtlich Abschnitte, die für die Softwareentwicklung gedacht sind. Passe sie an, wobei die Logik, nicht das Vokabular, erhalten bleibt:

Ursprünglicher technischer Abschnitt	Nicht-technische Anpassung
Tech Stack	Werkzeuge und Arbeitsformat
Build, Test & Verify	Wie wird überprüft, dass etwas in Ordnung ist (Kontinuitätsprüfung, lautes Vorlesen, Durchlauf eines Mitarbeiters, Produktions-Checkliste)
Code Style & Conventions	Formatkonventionen (Szenennummerierung, Vorlagenstruktur, Versionierung von Dokumenten)
Abhängigkeiten	Referenzmaterial, Quellen, Recherche-Notizen
Bereitstellung	Abgabeprozess, Exportformate, Lieferscheine

Übermittlung der Ergebnisse

Sobald alle Daten gesammelt und die Entscheidungen getroffen sind, erstelle das endgültige CLAUDE.md direkt im Zielordner des Projekts. Sage vor dem Erstellen kurz, welche Vorlage(n) gewählt wurden und warum, unter Bezugnahme auf die Regeln in der Skill und die gesammelten Daten. Nach dem Erstellen biete an, das Ergebnis zu überprüfen und bei Bedarf anzupassen.

Beispiel für ein technisches Projekt

• Projekt: Neue CLI-App in Python
• Typ: Technisch
• Pflege: Längerfristig
• Empfehlung: Vollständige Basisvorlage + Entwicklungsverlauf + Abschnitte zu Abhängigkeiten und Bereitstellung

Beispiel für ein nicht-technisches Projekt

• Projekt: Kurzfilm-Drehbuch
• Typ: Nicht technisch
• Pflege: Kurzfristig (einmalige Produktion)
• Empfehlung: Kompakte Basisvorlage, angepasst an das Schreibformat (Fountain) und die Produktions-Checkliste

Beispiel für ein gemischtes Projekt

• Projekt: Web-App zum Verwalten von RPG-Kampagnen-Notizen (der Benutzer programmiert sie selbst)
• Typ: Gemischt
• Pflege: Längerfristig (App wird weiterentwickelt, während gleichzeitig die laufende Kampagne dokumentiert wird)
• Empfehlung: Vollständige Basisvorlage + Entwicklungsverlauf + sowohl technische Abschnitte (Framework, Build) als auch nicht-technische (Konventionen zur Weltenerschaffung, Werkzeug für die Kampagnendokumentation)

Fehlerbehandlung

• Vorlagenordner nicht gefunden: Frage nach dem korrekten Pfad. Schlage nicht vor, einen zu erstellen, es sei denn, der Benutzer bittet explizit darum.
• Keine passende Vorlage verfügbar: Sage, dass keine der vorhandenen Vorlagen zum Projekt passt. Biete an, ein minimales CLAUDE.md von Grund auf zu erstellen.
• Schreibfehler beim Erstellen der Datei: Informiere den Benutzer und schlage vor, die Berechtigungen zu überprüfen oder einen anderen Speicherort zu wählen.

Wichtige Hinweise

• Keine Annahmen über den Vorlagenordner treffen: Jedes Projekt beginnt mit einer neuen Bestandsaufnahme.
• Nicht gegen den Willen des Benutzers schreiben: Bestätige größere Änderungen (Überschreiben einer vorhandenen Datei, Löschen von Inhalten) immer.
• Erklären, nicht nur ausführen: Sage immer, warum eine bestimmte Vorlage empfohlen wird und was sie bietet.
• Dokumentation der Ergebnisse: Wenn mehrere Vorlagen kombiniert werden, dokumentiere im CLAUDE.md, welche Vorlagen verwendet wurden, ähnlich einem „Generiert aus [Vorlagenname]“-Vermerk, damit zukünftige Aktualisierungen nachvollziehbar sind.

Vollständiges Beispiel für die Interaktion

(Die folgende Interaktion ist ein Beispiel. Passe sie an den tatsächlichen Kontext an.)

Benutzer: „Ich möchte ein neues Projekt starten. Es ist eine kleine Website für meine Band.“

Skill: „Okay, lass mich zuerst den Vorlagenordner überprüfen. (Listet den Ordner auf und liest die Vorlagen.) Ich habe eine Basisvorlage und eine Kurzvorlage. Das Projekt ist neu, klein. Wirst du es über längere Zeit pflegen (neue Inhalte hinzufügen) oder ist es einmalig? Bei einmaliger Nutzung empfehle ich die Kurzvorlage. Bei längerer Pflege die Basisvorlage plus optional den Entwicklungsverlauf. Was denkst du?“

Benutzer: „Es ist einmalig, nur für das Konzert nächsten Monat.“

Skill: „Perfekt. Ich verwende die Kurzvorlage. (Erstellt die Datei.) Fertig. Möchtest du etwas anpassen oder hast du weitere Projekte?“