Ein wiederverwendbares Engineering-Setup für neue Projekte - professioneller Prozess ab Commit eins, ganz ohne Lock-in.
DevBlueprint ist ein wiederverwendbares Engineering-Setup für neue Projekte, extrahiert aus einem echten Produktiv-Codebase und stack-agnostisch gemacht. Ein Befehl scaffoldet Git-Workflow, Quality Gate, Code-Konventionen und KI-Assistenten-Leitplanken in ein Zielverzeichnis. Dokumentations-first: die Ausgabe sind reine Dateien, die man besitzt und editiert - kein Runtime, kein Lock-in. Man kann DevBlueprint danach löschen, und nichts bricht.
Jedes neue Projekt startet ohne Prozess: Git-Workflow, Quality Gate, Konventionen und KI-Leitplanken werden jedes Mal neu erfunden oder ganz weggelassen - gerade im Solo-Betrieb. Mit mehreren parallelen KI-Sessions kommt ein zweites Problem dazu: die Chats wechseln sich gegenseitig den Branch weg. Fertige Frameworks und Template-Repos lösen das nur um den Preis dauerhafter Bindung.
Alles - die Idee, die Extraktion des Prozesses aus einem echten Produktiv-Codebase, die stack-agnostische Kern-Doku, die Bash-CLI, die neun Stack-Varianten, das Bats-Test-Setup und die Agent-Integration (CLAUDE.md, --json, Setup-Skill).
DevBlueprint trennt einen stack-agnostischen Kern von dünnen Stack-Overlays. core/ hält die Quelle der Wahrheit - Git-Workflow, Engineering-Standards, Konventionen, Quality-and-Testing und die CLAUDE.md-Templates. Neun Varianten fügen nur das Stack-Spezifische hinzu: die konkreten Gate-Befehle, einen CI-Workflow, .gitignore und die Worktree-Konfiguration. Eine Bash-CLI scaffoldet, prüft und aktualisiert das Setup.
core/ ist die stack-agnostische Quelle der Wahrheit und wird in jedes Projekt kopiert; variants/ overlayen nur das Stack-Spezifische. Die Ausgabe sind reine Dateien im Zielprojekt - es gibt keinen Runtime und keine Abhängigkeit auf DevBlueprint selbst.
Ein geteiltes Setup als Framework oder Template-Repo bindet jedes Projekt dauerhaft an sich - Updates werden zur Abhängigkeit, Abweichungen zum Kampf gegen das Werkzeug.
Dokumentations-first: die Ausgabe sind reine Dateien, die das Projekt besitzt und frei editiert. Es gibt keinen Runtime; nach dem Scaffolding kann DevBlueprint gelöscht werden, ohne dass etwas bricht.
Mehrere Assistenten-Chats an einem Repo wechseln sich gegenseitig den Branch weg - Arbeit landet auf dem falschen Stand oder geht verloren.
Ein Worktree pro Task über ein einziges wt-Skript: jede Aufgabe bekommt ihr eigenes Verzeichnis mit eigenem Branch (von develop), der Haupt-Klon bleibt auf master. Sessions kollidieren nicht mehr.
Der Prozess soll überall gleich sein, aber die konkreten Quality-Gate-Befehle, CI und Ignorierregeln unterscheiden sich je nach Stack fundamental.
core/ hält den agnostischen Kern, variants/ overlayen nur das Stack-Spezifische. Eine neue Variante entsteht, indem man einen Ordner kopiert und Gate, wt.conf und CI anpasst - sie taucht danach automatisch in devblueprint list auf.
Eine Text-CLI ist für Menschen gebaut; ein Agent muss den Zustand zuverlässig parsen und vor jedem Schreibzugriff bestätigen können.
list, doctor und version liefern --json (doctor exitet weiterhin bei Fehlern non-zero), eine intake.yml plus plan (== init --dry-run) zeigt exakt die geplante Ausgabe, und ein /devblueprint-setup-Skill interviewt, schreibt die Intake-Datei und scaffoldet erst nach Bestätigung.
Begonnen als Agenten-Projekt-Kit mit CLI-Gerüst, erster Doku und CI. Fünf Commits legen die Basis, bevor das Konzept überarbeitet wird.
In einem konzentrierten Arbeitstag zum dokumentations-first Engineering-Kit umgebaut: Kern-Doku, der Worktree-basierte Workflow, neun Stack-Varianten, die CLI-Befehle (detect, --json, intake + plan, update), die Bats-Test-Suite und der Agent-Setup-Skill. 112 der 117 Commits fallen auf diesen Tag - inklusive Dogfooding des Setups auf dem eigenen Repo.