Ein leeres Repo und Claude Code, Anthropics Coding-Agent im Terminal — mehr braucht es nicht, um loszulegen. Und genau das ist das Problem: Das Modell schreibt sofort Code, aber von Haus aus sorgt nichts dafür, dass vorher eine Spezifikation entsteht, hinterher ein Review stattfindet oder das Datenbank-Schema reproduzierbar deployt wird. Wer ein Claude-Code-Projekt aufsetzt, entscheidet deshalb weniger über Tooling als über einen Prozess — die Frage ist nicht, ob die KI coden kann, sondern nach welchem Ablauf sie arbeitet.
Dieser Artikel zeigt ein vollständiges Setup dafür im Überblick: das offene DI²-Starter-Kit — ein fester, nummerierter Entwicklungsworkflow von den Requirements bis zum Deploy, ein deploybarer Datenbank-Teil und eine Vorlage, die sich beim Aufsetzen selbst zuschneidet. Entstanden ist es nicht am Reißbrett, sondern als Destillat aus einem laufenden Projekt.
Das Wichtigste vorab:
- Das Grundgerüst: Konventionen liegen als Rules, Werkzeuge als Skills in
.claude/— und der Unterschied zwischen beiden entscheidet, was jede Session kostet. - Der Workflow: elf nummerierte Phasen von
/initbis/deploy, quer dazu der Bug-Loop; jede Feature-Spec ist der Vertrag, gegen den die Phasen arbeiten. - Der Datenbank-Teil: Plain-SQL mit Verzeichnis-Konvention, idempotent deploybar, in der CI gegen eine Wegwerf-Datenbank getestet.
- Die Design-Entscheidung: maximal starten und per
/init-Interview zuschneiden, statt leer beginnen und aufbauen. - Die bewussten Auslassungen: keine Hooks, keine Subagents — Einfachheit ist Teil des Designs.
- Offen auf GitHub: das Kit ist als Starter-Kit forkbar (MIT-Lizenz).
Voraussetzung: Claude Code und ein Editor; für den Datenbank-Teil optional ein PostgreSQL (lokal oder im Container). Die Beispiele stammen aus dem offenen DI²-Starter-Kit auf GitHub. Stand der Mechanik: Juli 2026.
Inhalt
- Das Grundgerüst: was in .claude/ liegt
- Der Workflow: von Requirements bis Deploy
- Der Datenbank-Teil: Plain-SQL, deploybar und getestet
- Die Design-Entscheidung: maximal starten, dann zuschneiden
- Was das Kit bewusst weglässt
- Ein neues Projekt mit dem Starter-Kit aufsetzen
- FAQ
- Verwandte Artikel
Das Grundgerüst: was in .claude/ liegt
Ein Claude-Code-Projekt aufzusetzen beginnt auf der obersten Ebene mit vier Verzeichnissen — .claude/, docs/, features/ und db/:
.claude/
├── rules/ lädt automatisch: Konventionen, Security-Regeln, SQL-Regelbaum — und stack.md
└── skills/ lädt auf Abruf: ein Ordner pro Workflow-Phase, aufrufbar als /requirements, /qa, …
docs/ PRD, Bug-Erfassung, Knowledge-Base
features/ INDEX.md + eine Spec pro Feature — der Arbeitsstand des Projekts
db/ der Datenbank-Teil: Schemas, Deploy-Skripte, Tests
Die Zweiteilung unter .claude/ ist die wichtigste Mechanik des Grundgerüsts. Rules — die CLAUDE.md und jede Datei unter .claude/rules/ — sind bei jedem Session-Start vollständig im Kontext, dem Arbeitsgedächtnis des Modells: die Verfassung des Projekts, die ungefragt gilt. Skills sind Werkzeuge auf Abruf: Im Kontext liegt zunächst nur ihre Beschreibungszeile, der Inhalt lädt erst beim Aufruf. Eine Sonderrolle in den Rules hat stack.md: Sie ist die maßgebliche Quelle für den Tech-Stack — Runtime, UI, Datenbank, Deploy, CI samt der Build- und Test-Kommandos; die CLAUDE.md trägt davon nur eine Kurzzusammenfassung. Die Skills bleiben dadurch stack-neutral; sie lesen den Stack zur Laufzeit, statt ihn im eigenen Text festzuschreiben.
Wie sich die beiden Ladewege im Detail unterscheiden — und was ein überfüllter Rules-Ordner jede Session an Kontext kostet — zieht der Artikel Skills vs. Rules in Claude Code auseinander.
Der Workflow: von Requirements bis Deploy
Das Herz des Setups ist ein nummerierter Ablauf: elf Phasen, von 0 bis 10, jede als eigenes Skill.
0 /init → 1 /requirements → 2 /architecture → [3 /ux] → [4 /backend] → [5 /frontend]
→ 6 /qa → 7 /review → 8 /check-updates → 9 /security → 10 /deploy
Getrieben wird der Ablauf von Specs: /requirements schreibt pro Feature eine Spezifikation mit User-Stories und Akzeptanzkriterien, und features/INDEX.md führt den Status aller Features — die eine Übersicht, an der sich jede spätere Phase orientiert. Gegen diese Spec arbeitet der Rest der Kette: /architecture entwirft das technische Design, /qa testet gegen die Akzeptanzkriterien, /review prüft den Diff gegen Spec und Konventionen. An einem kleinen Feature durchgespielt sieht das so aus:
/requirements Spec feat-0001-csv-import.md — User-Stories + Akzeptanzkriterien
/architecture Entwurf: Staging-Tabelle plus COPY-Import; kein UI → /ux entfällt
/backend Implementierung gegen die Spec
/qa Test gegen die Akzeptanzkriterien der Spec
/review Diff-Prüfung gegen Spec und Konventionen
Die eckigen Klammern in der Kette markieren Phasen, die nicht jedes Projekt braucht: Ein API-Dienst ohne Oberfläche kennt kein /ux und kein /frontend; der Zuschnitt beim Aufsetzen entfernt sie gleich ganz. Und Phase 0 fällt aus der Reihe: /init läuft genau einmal, beim Aufsetzen — dazu gleich mehr.
Zwei Eigenschaften halten den Ablauf im Zaum. Erstens springt keine Phase von selbst zur nächsten: Jeder Übergang wird vom Menschen ausgelöst; das Kit nennt das Human-in-the-Loop. Zweitens ist /security als Gate gesetzt: Vor einem Produktions-Deploy steht der projektweite Security-Audit, nicht danach. Quer zu allen Phasen laufen /bug (erfasst und schließt Bugs unter docs/bugs/, jederzeit), /auth (bei Auth-Projekten) und /help — das beantwortet die Frage „wo stehe ich gerade, was kommt als Nächstes“.
Der Datenbank-Teil: Plain-SQL, deploybar und getestet
Was dieses Setup von typischen Claude-Code-Vorlagen unterscheidet: Es hat einen echten Datenbank-Teil. Unter db/ liegt ein vollständiges, lauffähiges PostgreSQL-Beispiel — Tabellen mit Audit-Spalten, Prozeduren, Trigger, eine View, Seed-Daten, dazu Deploy-Skripte und Tests für die Datenbank-Objekte. Getragen wird das nicht von einem Migrations-Tool, sondern von einer Verzeichnis-Konvention: Objekt-Dateien in fester Nummerierung, idempotent formuliert, ein Apply-Runner spielt sie in definierter Reihenfolge ein; einmalige, datenabhängige Schritte laufen als Run-once-Transitions mit. In der CI wird jeder Schema-Stand gegen eine Wegwerf-Datenbank hochgezogen und getestet, bevor er ein reales Environment erreicht. Der Verzicht auf ein Migrations-Tool ist dabei eine bewusste Entscheidung dieses Setups, keine Universal-Empfehlung: Wo ein Team bereits ein etabliertes Migrations-Tool im Einsatz hat, gibt es keinen Grund zu wechseln.
Die Konventionen, nach denen diese SQL-Objekte geschrieben sind — Naming, Ausrichtung, Objekt-Skelette — liegen als Regelbaum unter .claude/rules/sql/ und sind der Gegenstand des Schwester-Überblicks KI-gestützte SQL-Entwicklung mit Claude Code mit seinen Vertiefungen zu Tabellen, Prozeduren und Funktionen.
Wie der Deploy ohne Flyway oder Liquibase im Detail funktioniert — Idempotenz, Run-once-Transitions, die Log-Tabelle schema_apply_log, der Runner und die CI-Absicherung — beschreibt SQL-Schema deployen ohne Migrations-Tool.
Die Design-Entscheidung: maximal starten, dann zuschneiden
Die Vorlage liefert alle vierzehn Skills und jeden Regelbaum mit — auch die Teile, die ein konkretes Projekt nie brauchen wird. Zugeschnitten wird beim Aufsetzen: /init ist ein einmaliges Bootstrap-Interview. Es erfasst zuerst die Produkt-Vision und die Rahmenbedingungen des Stacks — Runtime, UI, Backend, Datenbank, Auth, Deploy, CI — und schreibt die Vision in die CLAUDE.md, das Stack-Profil in die stack.md. Danach entfernt es, was die Antworten ausschließen: Kein UI heißt, /ux und /frontend fallen samt UI-Regelbaum weg; keine Datenbank heißt, der komplette db/-Baum verschwindet. Am Ende löscht /init sich selbst — ein Bootstrap läuft nur einmal.
Warum Löschen statt Aufbauen? Weil es die leichtere Operation ist: Wer löscht, entscheidet am vollständigen Bild: Jede Datei ist eine Ja/Nein-Frage. Wer aufbaut, muss sich an das Fehlende erinnern, und Vergessenes meldet sich nicht. Dazu kommt die Kontext-Rechnung: Nicht zutreffende Rules würden sonst jede einzelne Session mitladen.
Das Interview, die Rolle der stack.md als Single Source of Truth und die vollständige Pruning-Matrix — welche Antwort welche Dateien entfernt — beschreibt Maximal-Vorlage statt leeres Repo.
Was das Kit bewusst weglässt
Ein Überblick ist erst mit dem vollständig, was fehlt — und beim Starter-Kit fehlt einiges mit Absicht.
Keine Hooks. Claude Code kann Shell-Kommandos an Ereignisse binden, die dann automatisch ausgeführt werden — vor einem Tool-Aufruf, nach einer Änderung, beim Session-Start. Das Kit verzichtet darauf: Was passiert, passiert sichtbar im Dialog und steht in den Rules, wo es der Mensch liest und das Modell befolgt. Das kostet Automatisierungsgrad, spart aber die schwer nachvollziehbare Schicht zwischen Absicht und Ausführung.
Keine Subagents. Claude Code kann Teilaufgaben an separate Agenten mit eigenem Kontext abgeben. Auch hier hält das Kit die Arbeit im Hauptkontext, wo der Mensch sie sieht und lenken kann. Es ist dieselbe Entscheidung, die schon die Phasen-Übergänge nutzer-initiiert hält.
Kein App-Skelett. Es gibt kein src/: Das Kit ist keine Next.js-, Python- oder Sonstwas-Vorlage. Das Anwendungsgerüst entsteht durch den Workflow gegen den Stack, den das Projekt im Interview gewählt hat.
Genau eine Variante pro Geschmacksfrage. Ein UI-Regelsatz (React/Tailwind/shadcn), zwei SQL-Dialekte (PostgreSQL und SQL Server) — mehr Varianten liegen nicht nebeneinander. Braucht ein Projekt eine andere, gilt: portieren statt stapeln — den mitgelieferten Regelbaum kopieren, anpassen, das Original entfernen.
Diese Auslassungen gehören zur Einordnung: Das Kit ist kein Framework mit Vollständigkeitsanspruch, sondern ein meinungsstarkes Setup aus einem echten Projekt. Wo eine Meinung nicht passt, ist sie in Markdown-Dateien austauschbar — genau dafür liegt alles offen.
Zur ehrlichen Einordnung gehört auch die Gegenrechnung: Der Workflow kostet pro Feature echten Zusatzaufwand: Spec, QA und Review sind eigene Schritte, keine Nebenwirkungen. Für ein Wegwerf-Skript oder einen schnellen Prototyp ist das Setup überdimensioniert; dort bleibt das leere Repo die bessere Wahl. Und die Struktur trägt nur mit Disziplin: Wer Phasen regelmäßig überspringt, hat am Ende die Ordner, aber nicht den Prozess. Wofür man den Aufwand eintauscht, zeigt die Gegenüberstellung:
| Leeres Repo | Starter-Kit | |
|---|---|---|
| Anforderungen | im Chat-Verlauf | Spec pro Feature, versioniert |
| Reihenfolge | ad hoc | elf nummerierte Phasen |
| Konventionen | pro Session neu erklärt | Rules, automatisch geladen |
| Review und QA | auf Zuruf | eigene Phasen, Security als Gate |
| Datenbank | Handarbeit | db/-Baum, idempotent und CI-getestet |
Ein neues Projekt mit dem Starter-Kit aufsetzen
Das Kit liegt öffentlich auf GitHub, MIT-lizenziert. Für ein neues Projekt gibt es zwei gleichwertige Wege: das Repository als GitHub-Template verwenden („Use this template“) oder das mitgelieferte Kopier-Skript laufen lassen (new-project.ps1 beziehungsweise new-project.sh). Beide Wege erzeugen ein Repository mit frischer Git-Historie. Ein direkter git clone des Templates ist als Projekt-Start tabu: Er schleppt die Historie und den Upstream-Bezug des Templates mit, die im neuen Projekt nichts verloren haben.
1: gh repo create mein-projekt --template marcusbelz/di2-starter-kit --private --clone
Danach das neue Projekt in Claude Code öffnen, /init aufrufen, das Interview beantworten — und mit /requirements das erste Feature spezifizieren. Ab dort trägt der nummerierte Workflow.
Zur Herkunft gehören zwei Transparenz-Hinweise. Erstens die Abstammung: Das Kit ist die generalisierte, produktfreie .claude/-Werkzeugkiste des DI²-Projekts. Dieses stammt seinerseits vom AI Coding Starter Kit von AlexPEClub (MIT) ab; die Attribution ist im Repository dokumentiert. Zweitens die Entstehung: Die Texte im Kit sind von Claude geschrieben, unter menschlicher Regie — jede Datei beauftragt, geprüft und abgenommen; das README legt diesen Arbeitsmodus offen. Und eine ehrliche Reife-Einordnung: Die Konventionen sind im DI²-Projekt im täglichen Gebrauch entstanden und erprobt; die Verpackung als selbst-zuschneidende Vorlage ist jung. Wer das Kit einsetzt, übernimmt ein durchdachtes Setup, kein über Jahre abgehangenes Framework.
FAQ
Mit einer Vorlage, die Prozess und Konventionen mitbringt: ein neues Repository aus dem Template erzeugen (GitHub „Use this template“ oder Kopier-Skript — kein direkter git clone), in Claude Code /init aufrufen und das Interview zu Vision und Tech-Stack beantworten. Danach schneidet sich das Projekt selbst zu, und /requirements spezifiziert das erste Feature — ab dort führt der nummerierte Workflow bis zum Deploy.
Nur .claude/ mit Rules und Skills ist Konvention von Claude Code selbst. Alles Weitere — docs/, features/, db/ — ist eine Entscheidung des Setups. Genau dort liegt aber der Unterschied zwischen „das Modell schreibt Code“ und „das Projekt hat einen Prozess“: Specs, Bugs und Schema-Stände brauchen einen festen Ort, sonst existieren sie nur im Chat-Verlauf.
Rules laden bei jedem Session-Start vollständig in den Kontext und gelten ungefragt; Skills laden auf Abruf und laufen auf Kommando. Die Entscheidungsregel: Was immer gelten muss, wird Rule — was als Ablauf ausgeführt wird, wird Skill. Die Ladelogik im Detail steht in Skills vs. Rules in Claude Code.
Als eigenen db/-Baum im Repository: Objekt-Dateien in Verzeichnis-Konvention, idempotent formuliert, ein Runner spielt sie ein, die CI testet jeden Stand gegen eine Wegwerf-Datenbank. Ein Migrations-Tool braucht es dafür nicht — wie das funktioniert, zeigt SQL-Schema deployen ohne Migrations-Tool.
Nein. Die Workflow-Skills nennen keine Sprache und kein Framework — sie lesen den Stack zur Laufzeit aus stack.md, die /init beim Aufsetzen füllt. Stack-spezifisch sind nur die Regelbäume für UI und SQL-Dialekt; der Zuschnitt behält davon genau die Variante, die das Projekt gewählt hat.
Die Bausteine sind an die Claude-Code-Mechanik gebunden: Rules und Skills unter .claude/ mit ihrer unterschiedlichen Ladelogik gibt es dort nativ, ebenso die Slash-Aufrufe der Phasen. Die Ideen dahinter — Specs als Vertrag, nummerierte Phasen, Security vor dem Deploy — sind werkzeugneutral: Wer mit Cursor oder Copilot arbeitet, kann den Prozess übernehmen, müsste die Vorlage aber selbst portieren.
Verwandte Artikel
- Maximal-Vorlage statt leeres Repo — ein Claude-Code-Setup, das sich per /init selbst zuschneidet — die Design-Entscheidung „maximal starten, dann zuschneiden“ im Detail.
- Skills vs. Rules in Claude Code — die Ladelogik hinter dem Grundgerüst.
- SQL-Schema deployen ohne Migrations-Tool — der Datenbank-Teil in der Tiefe.
- KI-gestützte SQL-Entwicklung mit Claude Code — der Schwester-Überblick: die SQL-Konventionen, die im Kit als Regelbaum liegen.
- SQL-Tiefe hinter dem Regelbaum: Postgres-Tabellen-Konventionen, PL/pgSQL-Prozeduren-Konventionen, PL/pgSQL-Funktions-Konventionen.
- Das offene DI²-Starter-Kit auf GitHub — Vorlage, Workflow-Skills und Datenbank-Teil zum Forken.