Jedes neue Projekt beginnt mit demselben Ritual: leeres Repo anlegen, dann Ordnerstruktur, Konventionen und Workflow-Dateien aus dem letzten Projekt zusammensuchen — und die Hälfte vergessen. Eine Claude-Code-Vorlage kann diesen Reflex umdrehen: Statt mit nichts zu starten und mühsam aufzubauen, startet man mit allem — und lässt ein Interview löschen, was das Projekt nicht braucht.
Genau so arbeitet das offene DI²-Starter-Kit: Die Vorlage liefert jeden Skill und jede Rule, ein /init-Interview erfasst die Rahmenbedingungen des Projekts, schreibt sie in eine zentrale Datei — und schneidet den Klon danach auf exakt diesen Stack zu. Dieser Artikel erklärt das Prinzip hinter dieser Claude-Code-Vorlage, „maximal starten, subtraktiv zuschneiden“, und wo seine Grenze liegt.
Das Wichtigste vorab:
- Maximal statt minimal: Die Vorlage bleibt vollständig — zugeschnitten wird der Klon, nicht die Vorlage.
- Das
/init-Interview: rund zehn Fragen zu den Stack-Achsen (Runtime, UI, Backend, Datenbank, Auth, Deploy, CI, …), bevor irgendetwas gelöscht wird. stack.mdals Single Source of Truth: eine Datei trägt den Stack; die Skills lesen sie, statt Annahmen zu treffen.- Die Pruning-Matrix: welche Antwort welche Dateien entfernt — bis
/initsich am Ende selbst löscht. - Die ehrliche Grenze: wann sich der Maximal-Ansatz lohnt und wann das leere Repo besser bleibt.
Voraussetzung: Claude Code; die Beispiele stammen aus dem offenen DI²-Starter-Kit auf GitHub. SQL-Kenntnisse sind für diesen Artikel nicht nötig.
Inhalt
- Zwei Wege, ein Projekt zu starten
- Das Interview: /init fragt, bevor es löscht
- stack.md: die einzige Wahrheit über den Stack
- Die Pruning-Matrix: was wann gelöscht wird
- Wann Maximal, wann leer
- FAQ
- Verwandte Artikel
Zwei Wege, ein Projekt zu starten
Der Reflex bei Projekt-Vorlagen geht zum Minimalismus: so wenig wie möglich vorgeben, denn jede vorgegebene Datei ist eine Meinung, die vielleicht nicht passt. Der Preis dieses Reflexes zeigt sich beim dritten, vierten, fünften Projekt: Man baut dieselbe Struktur jedes Mal neu auf — und was dabei vergessen wird, meldet sich nicht. Die fehlende Security-Regel wirft keinen Fehler, der fehlende QA-Schritt bricht keinen Build. Das Versäumnis fällt erst auf, wenn es etwas gekostet hat.
Der Maximal-Ansatz dreht das Problem um. Die Vorlage liefert alles: jeden Workflow-Skill, jede Konventions-Datei, den kompletten Regelsatz für Datenbank, Deployment und CI. Beim Aufsetzen wird nicht aufgebaut, sondern gelöscht — und Löschen ist die leichtere Operation. Wer löscht, entscheidet am vollständigen Bild: Die Kandidatenliste steht sichtbar vor einem, jede Datei ist eine Ja/Nein-Frage. Wer aufbaut, muss sich an das Fehlende erinnern — und gegen das Vergessen gibt es keine Checkliste, wenn die Checkliste selbst das ist, was fehlt.
Die Asymmetrie gilt auch nach dem Aufsetzen: Ein Klon kann jederzeit weiter zuschneiden, wenn sich eine Rule als unnötig herausstellt. Der umgekehrte Weg — ein gelöschtes Skill wieder hereinholen — heißt: aus der Vorlage zurückkopieren. Deshalb bleibt die Vorlage selbst maximal; zugeschnitten wird immer nur der Klon.
Zwischen den beiden Extremen liegt eine dritte, etablierte Familie: parametrisierte Generatoren wie Cookiecutter, Copier oder Yeoman — die klassische Antwort auf wiederkehrenden Projekt-Boilerplate; auch GitHub-Template-Repositories gehören in diese Nachbarschaft. Auch Generatoren stellen Fragen, arbeiten aber additiv: Aus Platzhaltern und Bedingungen rendern sie genau das Projekt, das die Antworten beschreiben, und die Vorlage bleibt eine Schablone mit Templating-Syntax. Der Maximal-Ansatz unterscheidet sich an zwei Stellen: Jede Datei im Klon liegt von Anfang an in ihrer endgültigen Form vor — lesbar, diff-bar, ohne Template-Schicht, die gepflegt werden will. Und der Zuschnitt passiert nicht zur Erzeugungszeit im Generator, sondern als nachvollziehbare Lösch-Historie im Git-Log des Klons. Wer eine gepflegte Cookiecutter-Vorlage hat, verliert mit ihr nichts; der Maximal-Ansatz spart vor allem die Templating-Schicht.
Dass dieses Muster ausgerechnet bei einem geführten Agenten wie Claude Code gut funktioniert, hat zwei Gründe. Erstens ist der Zuschnitt selbst ein Ablauf mit Fragen, Regeln und Checkpoints — genau die Sorte Arbeit, die ein Agent entlang einer Anleitung zuverlässig ausführt, für die ein Mensch beim Dateien-Kopieren aber keine Geduld hat. Zweitens hat totes Gerüst in einem Claude-Code-Projekt einen messbaren Preis: Rules laden bei jedem Session-Start vollständig in den Kontext (Stand der Mechanik: Juli 2026) — ein nicht zutreffender Regelsatz kostet also jede einzelne Session, wie der Schwester-Artikel über Skills vs. Rules im Detail zeigt. Löschen ist hier keine Ordnungsliebe, sondern Kontext-Hygiene.
Das Interview: /init fragt, bevor es löscht
/init ist im Starter-Kit ein einmaliger Bootstrap-Skill, und er beginnt mit einer Vorprüfung: Er liest .claude/rules/stack.md und prüft, ob dort noch {{PLACEHOLDER}}-Werte stehen. Stehen dort keine mehr, ist das Projekt bereits initialisiert — /init bricht ab, statt ein laufendes Projekt zu beschneiden. Der uninitialisierte Zustand ist damit maschinell erkennbar, nicht Konvention im Kopf.
Danach kommt das Interview, in zwei Teilen. Zuerst die Produkt-Vision — Kernproblem, Zielnutzer, Muss-Features — in zwei, drei Sätzen für die PRD-Datei; die Detailarbeit übernimmt später der reguläre Workflow. Dann die Rahmenbedingungen des Stacks, Achse für Achse:
Runtime? python-3.12
UI? none
Backend? ja — fastapi
Datenbank? postgres
Test-Gerüst? behalten
Auth? none
Deploy? docker-ssh-vps + github-actions
CI? github-actions
Env-Stages? dev,prod
Feature-Prefix? feat
Dazu leitet /init die konkreten Build-, Test-, Run- und Audit-Kommandos für die gewählte Runtime ab und lässt sie bestätigen. Die Reihenfolge ist der Kern des Designs: erst erfassen, dann löschen. Jede Antwort wird festgehalten, bevor die erste Datei fällt — denn die Antworten sind es, die die Pruning-Matrix im nächsten Schritt steuert. Und für die unsicheren Fälle gilt eine klare Vorfahrtsregel: Wer eine Achse nicht beantworten kann, behält den zugehörigen Teil — die Asymmetrie vom Anfang entscheidet den Zweifel.
stack.md: die einzige Wahrheit über den Stack
Die Antworten landen nicht in der Konversation, sondern in einer Datei: .claude/rules/stack.md. Sie trägt eine Profil-Tabelle mit den Stack-Achsen, den Kommando-Block und freie Notizen — nach dem Interview etwa so:
| runtime | python-3.12 |
| ui | none |
| backend | fastapi |
| database | postgres |
| migrations | plain-sql |
| auth | none |
| deploy | docker-ssh-vps + github-actions |
| ci | github-actions |
lint: ruff check .
test: pytest
run: uvicorn app.main:app
audit: pip-audit
Diese Datei ist der Dreh- und Angelpunkt des ganzen Ansatzes, aus zwei Richtungen. Nach innen ist sie die Single Source of Truth für die Skills: Die stack-neutralen Skills des Kits — Architektur-Entwurf, Backend-Implementierung, Review, Deploy, Update-Check, Security-Sweep — nennen keine Sprache, kein Framework und keinen Hosting-Anbieter im eigenen Text. Sie lesen stack.md zur Ausführungszeit und richten sich nach dem, was dort steht. Ein einziger Ort trägt den Stack; ändert er sich, ändert er sich einmal.
Nach außen steuert sie den Zuschnitt: Steht auf einer Achse none, wird der zugehörige Werkzeug-Teil nicht etwa ignoriert, sondern entfernt. stack.md dokumentiert also nicht nur, was das Projekt ist — sie begründet, was im Klon fehlt. Wer ein Jahr später fragt „warum haben wir kein /deploy-Skill?“, findet die Antwort in einer Tabellenzeile: deploy: none.
Die Bündelung hat eine Kehrseite, die dazugehört: stack.md ist auch ein Single Point of Failure. Steht dort ein falscher oder veralteter Wert — eine Datenbank, die das Projekt längst gewechselt hat, ein Test-Kommando, das es nicht mehr gibt —, arbeiten alle Skills, die die Datei lesen, mit derselben falschen Annahme. Der Fehler wirkt zentral, genau wie die Wahrheit. Wer den Stack ändert, muss die Datei mitziehen; das ist der Preis der einen Quelle.
Die Pruning-Matrix: was wann gelöscht wird
Der eigentliche Zuschnitt folgt einer festen Matrix — jede Interview-Antwort hat definierte Konsequenzen. Die wichtigsten Zeilen:
| Antwort | Entfernt wird |
|---|---|
ui: none | die Skills /ux und /frontend, der UI-Regelbaum, cookies.md |
backend: none | das Skill /backend, die Backend-Rule |
database: none | der komplette SQL-Regelbaum, der db/-Verzeichnisbaum, die DB-Jobs der CI |
database: postgres | der mssql/-Regelbaum — nur der passende SQL-Dialekt bleibt |
auth: none | das Skill /auth |
deploy: none | das Skill /deploy, die Infrastruktur-Rule, die SSH-Deploy-Workflows |
ci: none | der komplette .github/workflows/-Baum |
| immer | /init löscht sich am Ende selbst — ein Bootstrap läuft nur einmal |
Drei Eigenschaften der Matrix sind bemerkenswerter als ihre einzelnen Zeilen.
Gelöscht wird per git rm, nach Rückfrage. Der Klon ist ein Git-Repository; jede Entfernung ist ein nachvollziehbarer, revertierbarer Schritt in der Historie — kein stilles Wegräumen. Vor dem Löschen zeigt /init die Liste der Kandidaten und holt ein Ja ein; danach zeigt er die verbleibenden Skills und Rules zur Kontrolle.
Ein Kern bleibt immer stehen. Feature-Spezifikation, Architektur, QA, Review, Bug-Erfassung, Update-Check und Security werden nie entfernt, ebenso die Grundregeln des Projekts samt stack.md. Die Matrix schneidet den Stack-abhängigen Rand zu, nicht den Workflow-Kern.
Für nicht mitgelieferte Varianten gilt „portieren statt stapeln“. Das Kit liefert genau einen UI-Regelsatz und zwei SQL-Dialekte mit. Braucht ein Projekt eine andere Variante — ein anderes Frontend-Framework, einen dritten SQL-Dialekt —, wird der mitgelieferte Regelbaum kopiert, angepasst und das Original entfernt. Es liegen nie zwei Varianten nebeneinander im Kontext, aus demselben Grund, aus dem überhaupt gelöscht wird.
Dass gelöscht wird, ist dabei eine Designentscheidung, kein Naturgesetz. Claude Code kennt mit paths:-gebundenen Rules auch einen Mittelweg zwischen „immer geladen“ und „weg“: Eine solche Rule lädt erst, wenn eine Datei angefasst wird, die zu ihrem Pfadmuster passt. Andere Vorlagen können mit Deaktivieren oder Lazy-Laden gut fahren. Das Kit verzichtet bewusst darauf und entfernt Unzutreffendes ganz — was im Klon liegt, gilt; was nicht gilt, liegt nicht im Klon. Für diese Vorlage ist Löschen der einfachere und robustere Weg.
Der letzte Punkt der drei Eigenschaften zeigt sich am konkretesten an der Datenbank-Zeile: Bei database: none verschwindet der komplette db/-Baum — genau der Verzeichnis-Deploy-Ansatz, den der Schwester-Artikel über das SQL-Schema-Deployment ohne Migrations-Tool beschreibt. Bei database: postgres bleibt er vollständig stehen, samt passendem Regelbaum. Die Matrix entscheidet nicht über Feature-Flags, sondern über Dateien.
Wann Maximal, wann leer
Der Maximal-Ansatz hat eine Voraussetzung und eine Grenze — beides gehört offen auf den Tisch.
Die Voraussetzung: Das Pruning muss verlässlich sein. Bleibt nach dem Zuschnitt totes Gerüst stehen — Rules für eine Datenbank, die es nicht gibt, ein Skill für ein Deployment, das nie stattfindet —, dann ist der Maximal-Start schlechter als das leere Repo: Die nicht zutreffenden Rules laden jede Session mit in den Kontext, und die toten Skills stiften Verwirrung, weil sie Fähigkeiten versprechen, die das Projekt nicht hat. Das Kit sichert das über die Matrix und die Kontroll-Liste am Ende ab — aber die Eigenschaft muss eine Vorlage erst einmal haben, bevor der Ansatz trägt.
Die Grenze verläuft am Wiederholungs-Charakter. Der Maximal-Ansatz lohnt sich, wenn Projekt-Starts wiederkehren und einen gemeinsamen Workflow-Kern haben: gleiche Spezifikations-Schritte, gleiche Review-Praxis, wechselnde Stacks. Dann amortisiert sich die Vorlage mit jedem Klon, und das Interview ist billiger als jedes händische Zusammensuchen. Das leere Repo bleibt besser für das Wegwerf-Skript, das Ein-Datei-Experiment und den Fall, dass ein eigener Workflow schlicht noch nicht existiert — wer die Konventionen einer fremden Claude-Code-Vorlage unbesehen übernimmt, übernimmt fremde Meinungen als Projektgesetz.
Und ein Reife-Hinweis gehört dazu: Die Vorlage-Form des Kits ist jung. Die Konventionen darin sind im DI²-Projekt im täglichen Gebrauch entstanden und erprobt — die Verpackung als selbst-zuschneidende Vorlage ist es noch nicht. Wer sie einsetzt, übernimmt eine durchdachte Idee, kein über Jahre abgehangenes Framework.
FAQ
Zwei Dinge, die man auseinanderhalten muss. Claude Code bringt ein eingebautes /init mit, das den vorhandenen Code analysiert und daraus eine CLAUDE.md erzeugt. Das Starter-Kit liefert dagegen einen eigenen /init-Skill: ein einmaliges Bootstrap-Interview, das Vision und Stack erfasst, stack.md und CLAUDE.md füllt und danach die nicht benötigten Skills und Rules löscht.
Für wiederkehrende Projekt-Starts spricht die Asymmetrie für maximal: Löschen ist eine Entscheidung am vollständigen Bild, Aufbauen verlangt, sich an das Fehlende zu erinnern — und Vergessenes meldet sich nicht. Maximal trägt aber nur, wenn der Zuschnitt verlässlich passiert; ohne Pruning ist die Maximal-Vorlage nur Ballast.
Die Single Source of Truth für den Tech-Stack eines Projekts aus dem Starter-Kit: eine Datei unter .claude/rules/ mit einer Profil-Tabelle (Runtime, UI, Backend, Datenbank, Auth, Deploy, CI, …) und den Build-, Test-, Run- und Audit-Kommandos. Die stack-neutralen Skills lesen sie zur Ausführungszeit, statt Sprache oder Framework im eigenen Text festzuschreiben.
Genauso wie beim Aufsetzen, nur ohne Interview: nicht benötigte Skills und Rules per git rm entfernen — die Git-Historie behält sie, und die Vorlage hält das Original für den Fall bereit, dass etwas zurückkopiert werden muss. Wichtig ist die Richtung: lieber im Zweifel behalten und später löschen als umgekehrt.
Nein — „vollständig starten, subtraktiv zuschneiden“ funktioniert mit jeder Projekt-Vorlage. Seinen größten Hebel hat er aber dort, wo ungenutzte Dateien laufend etwas kosten: In Claude Code laden Rules bei jedem Session-Start in den Kontext, dort ist der Zuschnitt unmittelbar Kontext-Ersparnis und nicht nur Aufgeräumtheit.
Verwandte Artikel
- Ein Claude-Code-Projekt mit Entwicklungsworkflow und Datenbank aufsetzen — der Überblick über das Setup, dessen Startpunkt diese Vorlage ist.
- Skills vs. Rules in Claude Code — die Ladelogik, die erklärt, warum Löschen Kontext spart.
- SQL-Schema deployen ohne Migrations-Tool — der
db/-Baum, über den die Datenbank-Zeile der Pruning-Matrix entscheidet. - Das offene DI²-Starter-Kit auf GitHub — die Maximal-Vorlage samt
/init-Skill und Pruning-Matrix zum Nachlesen.