Wie ich neue Websites in Minuten launche

Ein neues Webprojekt zu starten bedeutete früher mehrere Stunden Boilerplate: Design-System- Submodule einrichten, projektspezifische CLAUDE.md-Anweisungen von Grund auf schreiben, Produkt-Ordnerstruktur anlegen, TypeScript-Pfade konfigurieren, Tokens verdrahten. Jedes Mal, wenn ich einen Schritt vergessen habe, fiel es mir mitten im Build auf — ein fehlender Submodule-Pfad, eine vergessene ESLint-Regel, ein Produkt-Ordner, der nicht der Konvention entsprach.

Ich habe /init-project gebaut, um das komplett zu eliminieren. Ein Befehl, ausgeführt vom Workspace-Root, und ein neues Projekt ist mit allem aufgesetzt — bereit für den ersten Feature-Commit.

Was init-project macht

/init-project ist ein Claude Code Skill, der das vollständige Projekt-Bootstrap orchestriert. Er nimmt Projektname, Typ und optionale Brand entgegen und delegiert dann sequenziell an drei spezialisierte Skills. Jeder Skill übernimmt eine Ebene des Setups und liest die Workspace-CLAUDE.md, um die einzuhaltenden Konventionen zu verstehen.

Der Orchestrator erledigt die Arbeit nicht selbst — er koordiniert. Das hält jeden Skill fokussiert, testbar und unabhängig verbesserbar. Wenn ich einen Bug im Design-System- Setup behebe, profitiert jedes zukünftige Projekt, ohne den Orchestrator anzufassen.

Die drei Skills

create-claude-md

Dieser Skill generiert die CLAUDE.md des Projekts — die Datei, die Claude Code sagt, wie in dieser spezifischen Codebase gearbeitet werden soll. Er liest die CLAUDE.md-Dateien von drei aktiven Projekten, extrahiert die zutreffenden Patterns (Branch-Benennung, Import-Regeln, Testing-Konventionen, Design-System-Integration) und synthetisiert eine neue, auf den Projekttyp zugeschnittene.

Das Ergebnis ist kein Template mit ausgefüllten Lücken. Es ist ein kontextbewusstes Dokument, das die tatsächlichen Tools, Pfade und Konventionen referenziert, die das Projekt verwenden wird. Wenn ich im neuen Projekt anfange zu arbeiten, kennt Claude Code bereits den Stack, die Regeln und die Fallstricke.

setup-design-system

Dieser Skill bindet das gemeinsame Design-System als Git-Submodule in das Projekt ein. Er konfiguriert die TypeScript-Pfad-Aliase, fügt das Submodule zur ESLint-Ignore-Liste hinzu, richtet die Token-Bridge in globals.css ein und installiert die Peer- Dependencies, die Design-System-Komponenten benötigen.

Das Design-System ist ein Monorepo mit Web- und Native-Komponenten, gemeinsamen Tokens und einem Storybook-Setup. Jedes Projekt konsumiert dieselben Komponenten und Tokens — visuelle Konsistenz kommt aus der Infrastruktur, nicht aus Disziplin.

init-product-folder

Dieser Skill erstellt das product/-Verzeichnis mit der Standardstruktur: Vision- Dokument, PRD-Template, Roadmap, Business-Model-Canvas und Ordner für Ideen, Tickets und Operations. Er befüllt den initialen Inhalt aus dem Projekt-Brief, falls einer existiert.

Der Produkt-Ordner erfasst, warum das Projekt existiert und was es werden soll. Ihn von Tag eins zu haben bedeutet, dass Produktentscheidungen dokumentiert sind, bevor die erste Zeile Code geschrieben wird.

Was das in der Praxis bedeutet

Vom Ausführen von /init-project bis zu einem deployfähigen Projekt mit verdrahtetem Design-System, vollständigen Projektanweisungen und einer Produkt-Wissensbasis vergehen unter fünf Minuten. Jedes Projekt auf sebb.pro — einschließlich Kundenseiten — wurde so aufgesetzt.

Die Konsistenz ist wichtiger als die Geschwindigkeit. Jedes Projekt folgt denselben Konventionen, hat dieselbe Ordnerstruktur und integriert das Design-System auf die gleiche Weise. Wenn ich zwischen Projekten wechsle, gibt es keinen kognitiven Overhead durch unterschiedliche Setups. Wenn ich einen Mitarbeiter onboarde, ist die CLAUDE.md bereits da.

Was als nächstes kommt

Der Init-Workflow endet aktuell auf der Code-Ebene. Drei Erweiterungen stehen auf der Roadmap:

Automatisiertes Vercel-Setup — Erstellung des Vercel-Projekts, Verknüpfung des GitHub-Repos und Konfiguration der Umgebungsvariablen als Teil des Init-Flows.

Sentry-Integration — Ausführung des Sentry-Wizards und Konfiguration des DSGVO-konformen Error-Tracking-Setups, das jedes Projekt braucht.

CI/CD-Pipeline — Generierung des GitHub-Actions-Workflows für Lint, Type-Check, Test und Build — wird aktuell manuell aus bestehenden Projekten kopiert und angepasst.

Jede Erweiterung folgt dem gleichen Muster: ein fokussierter Skill, den der Orchestrator zum richtigen Zeitpunkt in der Sequenz aufruft. Die Infrastruktur ist dafür ausgelegt — einen neuen Init-Schritt hinzuzufügen bedeutet, einen neuen Skill zu schreiben, nicht die Pipeline umzubauen.