Neues Gerät. Alles weg. Dein KI-Workflow, deine Skills, deine Configs — irgendwo, aber nicht hier. Du fängst wieder von vorne an. Und dann... und dann... und dann.

„Dude, where’s my car?“ ist nicht nur ein Film aus dem Jahr 2000. Es ist ein exaktes Abbild des Gefühls, wenn du nach einem Gerätewechsel zum dritten Mal deine Entwicklungsumgebung neu einrichtest.

— Quasi Zitat, Chester / Jesse, 2000

Der Film hat einen berühmten Running-Gag: „And then? And then? AND THEN?“ — eine endlose Kette ohne Befriedigung. Exakt so fühlt sich Setup ohne Infrastruktur-Repo an.

Schritt 1
Skills neu installieren
Wo hatte ich die nochmal?
Und dann?
MCP Configs suchen
Irgendwo in einer Notion-Seite
Und dann?
Snippets neu anlegen
Aus dem Gedächtnis
Und dann?
3–5h später produktiv
Für Setup. Nicht für Arbeit.

Mit einem Infrastruktur-Repo endet diese Kette nach einem einzigen Befehl. Kein „and then“ mehr.

1. Das Problem — und mit KI wird es größer, nicht kleiner

Früher war ein Gerätewechsel schmerzhaft, aber überschaubar. Git konfigurieren, ein paar Tools installieren — 20 Minuten. Das waren andere Zeiten.

Heute — wenn du mit Claude Code, Agent-Teams, MCP-Servern und Custom Skills arbeitest — hast du eine Umgebung aufgebaut, in der Monate an Iterationen stecken. Skills die sich bewährt haben. Kontext-Snippets die automatisch feuern. Verbindungen zu GitHub, Supabase, Vercel, direkt aus dem Chat heraus.

Und das alles lebt lokal. Auf einem Gerät. Nirgendwo sonst.

Kurzfassung:

Ein Infrastruktur-Repo ist ein privates GitHub-Repo ohne eigentliches Projekt — nur für Setup-Scripts, Skills, Configs und Guides. Alles was du brauchst um in 90 Sekunden wieder produktiv zu sein. Einen Befehl ausführen, alles drin.

2. GitHub als Parkplatz

Stell dir deine GitHub-Repo-Liste als Parkplatz vor. Die meisten Spots belegen Projekte — Apps, Websites, Tools, die gebaut und deployed werden. Aber ganz hinten, ein paar reservierte Spots: die Infrastruktur.

Da parkst du dein Setup. Nicht ein Produkt. Nicht etwas für Nutzer. Nur das Werkzeug, das alle anderen Projekte erst möglich macht.

Beispiel-Aufstellung — klick auf ein Repo

InfraSetup-Wartend
InfraSetup-Aktiv
Projektsaas-app
Projektblog
Projektlanding-page
Projektchrome-ext
Projektapi-service
Klick auf einen Spot für Details.
Infrastruktur-Repo
Projekt-Repo

Du kannst so viele Infrastruktur-Repos anlegen wie sinnvoll ist — manche trennen nach aktiv und wartend, andere nach Tool-Typ oder Gerät. Der Name ist dabei völlig frei.

Wie nennst du deinen Infrastruktur-Spot?

Du nennst es Parkplatz — weil du Infrastruktur dort abstellst bis du sie brauchst. Repos heißen Parkplatz01, Parkplatz02. Beim nächsten Setup weißt du sofort: das ist der Startpunkt.

3. Was steckt drin?

Eine bewährte Aufteilung: ein Repo für aktive Setups, eines für Dinge die noch nicht eingerichtet sind aber bereits dokumentiert werden.

Setup-Wartend/   # geparkt — wartet auf Credentials oder Zeit
├── README.md             # Was hier liegt und warum
└── supabase-mcp.md       # Guide — bereit wenn es so weit ist

Setup-Aktiv/    # wird auf jedem Gerät installiert
├── install.sh            # Ein Befehl. Alles drin.
├── CLAUDE.md
├── skills/
│   ├── marketing-team/SKILL.md
│   ├── developer-team/SKILL.md
│   ├── anti-ai-slop/SKILL.md
│   └── deploy-checklist/SKILL.md
├── setup/
│   └── github-mcp.sh
└── guides/
    └── mcp-tier-liste.md

Der entscheidende Teil: install.sh. Neues Gerät, ein curl-Befehl — Skills aktiv, Snippets konfiguriert, MCP eingetragen. 90 Sekunden.

4. Der Mehrwert — und der ist nicht technisch

01
Wissen wird portabel
Was du über deinen Workflow gelernt hast lebt nicht mehr nur auf einem Gerät. Versioniert, abrufbar, teilbar.
02
Warten wird dokumentiert
Tools die noch nicht aktiv sind aber kommen werden — fertig erklärt. Kein „wie hatte ich das konfiguriert?“
03
Anfangen wird trivial
Neues Gerät, ein Befehl. Der mentale Aufwand für Setup fällt weg. Das verändert wie oft du einfach startest.

Der dritte Punkt klingt klein. Er ist es nicht. Wenn Setup kein Thema mehr ist, fängst du häufiger an. Du probierst mehr aus. Du arbeitest auf dem neuen Rechner sofort — anstatt Tage mit „ich richte das nachher ein“ zu verlieren.

Im Film findet Jesse am Ende sein Auto. Der Weg dahin ist chaotisch, absurd und vollständig unnötig. So ist Setup ohne Infrastruktur-Repo. Du findest deinen Workflow am Ende — aber warum so?

— Lose Metapher, while.coffee, 2026

5. Vorher vs. Nachher

Ohne Infra-Repo
3–5h
bis zum ersten produktiven Moment
Skills suchen — Configs rekonstruieren — Snippets neu anlegen — Guides googlen — und dann? und dann?
Mit Infra-Repo
90s
bis zum ersten produktiven Moment
curl .../install.sh | bash
Fertig.

6. Starten — ohne Perfektionismus

Das häufigste Problem: Das Infrastruktur-Repo wird nie angelegt weil man erst alles perfekt dokumentieren will. Das ist der gleiche Fehler wie Chester und Jesse — zu lange grübeln statt einfach zu fahren.

Starte mit einer leeren README und einem einzigen Script. Der Rest kommt von selbst — sobald du beim nächsten Gerätewechsel merkst was du vermisst. Und genau dann schreibst du es auf. Beim übernächsten Mal: Repo, einmal ausführen, weiterarbeiten.

And then? Einfach arbeiten.

Hey Mann, wo ist mein Auto?

Im Infra-Repo. Ein Befehl entfernt. Genau da wo du es gelassen hast.