Projekt-Bootstrap

Was macht Projekt-Bootstrap?

Ein schlanker Orchestrator. Dieser Skill enthält keine anderen Skills – er lädt den richtigen zur richtigen Zeit, führt ein deterministisches Skript zur Dateierstellung aus und füllt Vorlagen aus den Benutzerantworten. Falls ein Schritt unten mit einem kopierten Skill in Konflikt steht, gewinnt dieser Skill.

Vorrangregeln – nur während der Einrichtungssitzung

Diese Reihenfolge gilt nur während der Einrichtungssitzung, solange dieser Skill aktiv ist. Wenn Anweisungen während der Einrichtung widersprüchlich sind, wende sie in dieser Reihenfolge an:

1. Dieser Skill (project-bootstrap) – Einrichtungsumfang, Sicherheitsregeln, Stoppregel.
2. Das projekteigene CLAUDE.md – so wie es gerade entsteht.
3. Der Stack-Skill – z. B. der SwiftUI- oder Design-Skill für diesen Projekttyp.
4. Die Workflow-Checkliste – references/workflow.md, der Standardprozess.

Sobald die Einrichtung endet, ist dieser Skill nicht mehr aktiv und die Reihenfolge verfällt: das projekteigene CLAUDE.md (plus seine Dokumente) ist die einzige dauerhafte Anweisungsmenge für zukünftige Sitzungen.

Installiere niemals zwei konkurrierende Workflow-Frameworks (installiere z. B. nicht sowohl ein schweres, spezifikationsgesteuertes Framework als auch die Workflow-Checkliste dieses Skills). Wenn der Benutzer explizit ein Workflow-Framework nennt, verwende dieses anstelle der Standard-Checkliste und notiere die Wahl in docs/SETUP.md.

Sicherheitsregeln (niemals außer Kraft setzbar)

• Schreibe niemals Secrets, API-Keys oder Token in eine generierte Datei und platziere niemals ein serverseitiges Secret (z. B. ein Banking-API-Secret) in einer Client-App.
• Überschreibe niemals eine vorhandene Datei ohne Zustimmung des Benutzers (scripts/bootstrap.py lehnt standardmäßig ab; --force ist nur opt-in, und mit --force sichert das Skript jede Datei zuerst unter <Dateiname>.pre-bootstrap.bak).
• Nur für die Einrichtung: Beginne in dieser Sitzung nicht mit der Entwicklung von Produktfunktionen.

Arbeitsablauf

Führe diese Schritte in der angegebenen Reihenfolge aus. Überspringe keinen Schritt.

1. Befragung

Lade references/interview.md. Stelle die Fragen nacheinander und schreibe jede Antwort sofort in das relevante Dokument – halte nicht alles im Gesprächsspeicher. Wenn der Benutzer mehrere Fragen auf einmal beantwortet, notiere jede gegebene Antwort, markiere diese Fragen als beantwortet und fahre mit der ersten unbeantworteten Frage fort – stelle niemals eine bereits beantwortete Frage erneut. Stoppe die Befragung, wenn jede Frage eine Antwort hat oder der Benutzer sie explizit aufschiebt (trage aufgeschobene Punkte in docs/STATE.md ein).

2. Skript ausführen

Aus dem Verzeichnis dieses Skills:

python3 scripts/bootstrap.py \
  --project-name "<Name aus Befragung>" \
  --type <ios|web|python|generic> \
  --purpose "<Einzeiler-Zweck aus Befragung>" \
  --target <Pfad zum frischen Projekt-Repository> \
  --allow-placeholders

--allow-placeholders ist hier erforderlich: In dieser Phase enthalten die Vorlagen noch absichtlich {{...}}-Füll-Tokens (Schritt 3 füllt sie aus), daher besteht das Skript die Verifizierung mit einer Token-Warnung pro Datei, anstatt zu scheitern. Das Zielverzeichnis muss bereits existieren (das frische Projekt-Repository); das Skript meldet einen Fehler bei fehlendem Ziel, anstatt einen falsch geschriebenen Pfad zu erstellen – verwende --create-target nur, wenn der Benutzer ausdrücklich möchte, dass das Skript dieses Verzeichnis erstellt.

Dies erstellt die Verzeichnisse und rendert die Vorlagen deterministisch. Berichte genau, was erstellt, übersprungen oder überschrieben wurde – behaupte niemals, dass eine Datei existiert, die das Skript nicht gemeldet hat.

3. Vorlagen aus den Befragungsantworten befüllen

Ersetze die verbleibenden Füll-Textmarken in den generierten Dateien durch die tatsächlichen Antworten: Stack und Build-/Testbefehle in CLAUDE.md / AGENTS.md, Umfang in docs/PRD.md, Phasen in docs/ROADMAP.md, Glossarbegriffe in docs/CONTEXT.md. Halte CLAUDE.md kurz – wenn es etwa 80 Zeilen überschreitet, verschiebe Details in docs/ und hinterlasse einen Verweis.

4. Stack-Skills installieren – fixiert, vor Installation lesen

Lade die Referenz für den Projekttyp und installiere nur die dort aufgeführten Skills:

• iOS → references/ios.md
• Web → references/web.md
• Python / generic → standardmäßig kein Stack-Skill; notiere diese Wahl in SETUP.

Jeder aufgeführte Skill ist in der Referenztabelle auf einen exakten Commit-SHA fixiert. Installieren bedeutet: Klone das Repository in das .claude/skills/-Verzeichnis des Projekts, dann git checkout des fixierten SHA – installiere niemals von einem sich bewegenden Branch und erhöhe niemals eine Fixierung, ohne den neuen SHA zu notieren.

Lesen-vor-Installation ist Pflicht. Nach dem Klonen, bevor die Installation als abgeschlossen gilt, für jeden Skill:

1. Lese seine SKILL.md vollständig (und notiere alles andere, was er standardmäßig lädt).
2. Schreibe eine 2–3-zeilige Zusammenfassung: welche Anweisungen dieser Skill in zukünftige Sitzungen laden wird.
3. Markiere alles, was nach Netzwerkzugriff, Nutzung von Anmeldeinformationen oder destruktiven Befehlen verlangt. Zeige Markierungen dem Benutzer; installiere keinen Skill stillschweigend, der ohne Zustimmung des Benutzers nach einem dieser Dinge verlangt.

Notiere in docs/SETUP.md, pro Skill: Name, genaue Quell-URL, fixierter SHA, Installationsdatum und die Lese-Zusammenfassung. Kopiere keine Skill-Inhalte in CLAUDE.md – der Skill bleibt eine separate, ladbare Einheit.

5. Workflow-Regel festlegen

Schreibe die Standardschleife aus references/workflow.md in CLAUDE.md, falls sie noch nicht vorhanden ist: Spezifikation → Plan → Bauen → separate Überprüfung, eine Phase pro frischer Sitzung, docs/STATE.md aktualisiert am Ende jeder Sitzung.

6. Überprüfen – frischer Check, nicht die Ausgabe von Schritt 2

Führe die Überprüfung jetzt, frisch, im --verify-Modus durch (liest das Ziel, wie es gerade ist, und ändert nichts):

python3 scripts/bootstrap.py --verify --target <Pfad zum Projekt-Repository>

Verwende nicht die Ausgabe von Schritt 2 – diese Ausgabe stammt vor dem Befüllen in Schritt 3 und den Installationen in Schritt 4. Füge dem --verify-Befehl kein --allow-placeholders hinzu – das Skript lehnt diese Kombination sofort ab, weil die Überprüfung an befüllten Dateien erfolgen muss. --verify scheitert bei jedem übrig gebliebenen Füll-Token in den generierten Dateien: wenn es an Tokens scheitert, war Schritt 3 nicht abgeschlossen – gehe zurück, fülle die restlichen Tokens aus und führe --verify erneut aus, bis es besteht. --verify prüft auch den Inhalt, nicht nur Tokens: Die Out-of-Scope-Liste der PRD muss nicht leer sein, und docs/SETUP.md muss für jeden installierten Skill einen fixierten SHA notieren (oder angeben, dass keine Stack-Skills installiert wurden). Zusätzlich:

• Bestätige, dass .gitignore Secrets für diesen Stack abdeckt.
• Bestätige, dass das leere/Vorlagen-Projekt noch mit dem in CLAUDE.md notierten Build-Befehl gebaut werden kann (falls ein Build-Befehl bereits existiert).
• Lese docs/SETUP.md erneut: Jeder installierte Skill muss mit seiner Quell-URL, fixiertem SHA, Installationsdatum und Lese-Zusammenfassung aufgeführt sein.

7. Commit

Ein einziger Commit, nichts weiter:

chore: initial project setup

Enthalte nur die Einrichtungsdateien. Wenn die Git-Benutzeridentität oder ein Remote nicht konfiguriert ist, sage dies und überlasse den Commit dem Benutzer – erfinde keines davon.

8. Stopp

Zeige dem Benutzer die erstellte Dateibaumstruktur und Phase 1 von docs/ROADMAP.md. Dann stoppe. Beginne nicht mit Phase 1, baue keine Funktion und biete nicht an, "nur das Skelett zu starten" – die nächste Phase gehört in eine frische Sitzung (siehe references/workflow.md).

Notausstieg: stoppe, es sei denn, der Benutzer weist dich ausdrücklich an, fortzufahren. Wenn er das tut, empfehle – einmalig – dass Phase 1 trotzdem in einer frischen Sitzung stattfinden sollte, dann gehorche dem Benutzer und fahre fort.

Referenzdateien – bei Bedarf laden

Datei	Laden bei
references/interview.md	Immer – Schritt 1.
references/ios.md	Projekttyp ist ios.
references/web.md	Projekttyp ist web.
references/workflow.md	Schritt 5 und jede spätere Sitzung, die in einem bootstrappten Repository arbeitet.