Dein Infra-Repo: Setup einmal, nutze überall
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 präzises 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. Genau 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.
// 01 / 06Das 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.
// 02 / 06GitHub 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
Infra · Setup-Wartend
Setup-Wartend, geparkt. Enthält Setup-Guides für Tools, die noch nicht aktiv sind. Dokumentiert damit du beim nächsten Einrichten nicht wieder von Null anfängst.
Infra · Setup-Aktiv
Setup-Aktiv, wird auf jedem neuen Gerät als erstes installiert. Skills, Snippets, MCP Configs, Guides. Ein curl-Befehl und alles ist da.
Projekt · saas-app
saas-app, ein echtes Produkt-Repo. Wird deployed, hat Nutzer, wird irgendwann abgeschlossen.
Projekt · blog
blog, statischer Blog oder CMS-Projekt. Normaler Lifecycle, normales Projekt-Repo.
Projekt · landing-page
landing-page, Marketing-Seite für ein Produkt oder eine Dienstleistung.
Projekt · chrome-ext
chrome-ext, Browser Extension. Eigenes Repo, abgegrenzter Scope.
Projekt · api-service
api-service, Backend-Service mit eigener Deployment-Pipeline.
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? Ein paar Möglichkeiten, wie du den Spot taufen kannst:
- 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. - Du nennst es Toolbox, eine Sammlung von Werkzeugen.
Toolbox01,Toolbox02. Klar gegliedert, immer griffbereit. - Du nennst es Basecamp, der Ausgangspunkt bevor du auf ein Projekt losgehst. Alles was du brauchst bevor die eigentliche Arbeit beginnt.
- Du nennst es Vault, wertvolles Wissen, sicher aufbewahrt.
Vault01,Vault02. - Du nennst es Dotfiles, der klassische Dev-Ansatz. Configs, Shell-Aliases, Tool-Settings, versioniert.
- Du nennst es Werkstatt, der Ort wo du arbeitest bevor das fertige Produkt entsteht. Klingt nach Handwerk, nach echtem Können.
// 03 / 06Was 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.
// 04 / 06Der 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.chat, 2026
// 05 / 06Vorher vs. Nachher
Bis zum ersten produktiven Moment
SzenarioZeitWas passiert Ohne Infra-Repo 3–5h Skills suchen, Configs rekonstruieren, Snippets neu anlegen, Guides googlen, und dann? und dann? Mit Infra-Repo 90s curl .../install.sh | bash — Fertig.
// 06 / 06Starten, 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 bei Chester und Jesse, zu lange grübeln statt einfach loszufahren.
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.
Häufige Fragen
Zum Thema: Web Dev for Vibe Coders, Der komplette Guide 2026
// micro-journal
Was richtest du immer wieder neu ein?
Ein Satz reicht. Das Journal bleibt lokal in deinem Browser — kein Konto, kein Server.
notierenMG
Max Götte
SEO Strategist · Founder · while.chat
SEO-Berater aus Bochum. Spezialisiert auf technisches SEO, Local SEO und Generative Engine Optimization für KMU im DACH-Raum. Schreibt über KI-Workflows, Vibe Coding und das, was zwischen Tool und Praxis passiert.
FAQ
Was ist ein Infrastruktur-Repo?
Ein Git-Repo, das dein komplettes Arbeits-Setup enthält: Claude Skills, MCP-Configs, Shell-Aliase, Editor-Settings, Install-Scripts. Auf einem neuen Gerät clonst du das Repo, führst ein Setup-Script aus und hast deinen ganzen KI-Workflow zurück, Claude Code, Cursor, alles wie zuvor.
Was gehört in so ein Repo, was nicht?
Rein: SKILL.md-Dateien, MCP-Server-Configs, Aliases, Settings-JSON, Setup-Scripts. Raus: API-Keys und Secrets (in einen Passwort-Manager), große Datenfiles, projektspezifischer Code. Faustregel: Alles, was Tooling-Konfiguration ist, kommt rein. Alles, was Daten oder Geheimnisse sind, bleibt draußen.
Wie verwalte ich Secrets, ohne sie ins Git zu pushen?
Drei Optionen: 1Password CLI, macOS Keychain oder ein .env-Template, das im Repo liegt, plus ein .env (gitignored), das jedes Gerät selbst befüllt. Setup-Script zieht Secrets per CLI ab, schreibt sie in lokale Files. Niemals Secrets in tracked Files.
Was ist der Unterschied zu einem Dotfiles-Repo?
Ein Infra-Repo ist ein erweitertes Dotfiles-Konzept für das KI-Zeitalter. Klassische Dotfiles: .zshrc, .gitconfig, vim-Config. Infra-Repo zusätzlich: Claude Skills, MCP-Server, Agent-Configs, Toolchain-Versionen. Es geht um mehr als Editor-Settings, nämlich um den kompletten Wissens- und Tooling-Stack.
Wie fange ich an, ohne in Perfektionismus zu verfallen?
Leere README, ein einziges Setup-Script. Beim nächsten Gerätewechsel merkst du, was fehlt, und ergänzt es genau dann. Beim übernächsten Mal: clonen, einmal ausführen, weiterarbeiten. Inkrementell statt vollständig. Das Repo wächst mit deinem Workflow.