Vibe Coding im Team: Das stabile Setup für gemeinsame Prototypen

Für ein kleines Team ist dieses Setup meistens stabil genug:

1. Ein gemeinsames Git-Repository als Single Source of Truth
2. Projektkontext im Repo, nicht nur in Obsidian oder Nextcloud
3. CLAUDE.md im Root als kurze Arbeitsanweisung für den Agenten
4. Geteilte Skills im Repo, z. B. unter .claude/skills/
5. Ein Design-System an einer Stelle, z. B. docs/design-system.md oder src/design/tokens.ts
6. Branches oder Worktrees für parallele Arbeit
7. Kleine Pull Requests, damit ihr Änderungen prüfen und zusammenführen könnt

Das Ziel ist nicht „mehr Technik“. Das Ziel ist: Jede Person und jeder AI-Agent arbeitet mit demselben Kontext, ohne sich gegenseitig Dateien kaputtzumachen.

Tools wie Nextcloud oder Obsidian sind gut für Notizen, Recherche und gemeinsames Denken. Für Code und Prototypen reichen sie aber nicht als einzige Quelle.

Ein Prototyp besteht aus Dateien, Komponenten, Zuständen, Abhängigkeiten und kleinen Änderungen. Dafür brauchst du Versionierung:

• Wer hat was geändert?
• Welche Änderung gehört zu welchem Use Case?
• Was funktioniert noch, was ist kaputt?
• Wie kommt eine Änderung sicher in den gemeinsamen Stand?
• Wie geht ihr zurück, wenn ein Experiment schiefgeht?

Genau dafür sind Git und ein gehostetes Repository auf GitHub oder GitLab gebaut.

Viele Teams teilen nur den Code. Für AI-Arbeit ist das zu wenig.

In euer Repo gehören auch die Informationen, die der Agent wirklich nutzen soll:

/projekt
  /docs
    design-system.md
    produktidee.md
    nutzerrollen.md
    prototyping-regeln.md
  /.claude
    /skills
      ui-review.md
      component-builder.md
  CLAUDE.md
  README.md
  package.json
  src/

Wichtig: Alles, was für Claude Code oder Cowork verbindlich sein soll, gehört als Markdown ins Repo. Ein Second Brain in Obsidian kann euer menschlicher Denkraum bleiben. Der Agent arbeitet aber zuverlässiger mit klaren Dateien im Projekt.

CLAUDE.md ist nicht der Ort für das ganze Wissen. Es ist eher die Startanweisung.

Gute Inhalte:

• Was ist das Ziel des Prototyps?
• Welche Zielgruppe testet ihr?
• Wo liegen Design-Regeln und Komponenten?
• Welche Dateien darf der Agent nicht anfassen?
• Wie soll er vor größeren Änderungen vorgehen?
• Welche Befehle nutzt ihr zum Starten, Testen und Prüfen?

Die offiziellen Claude-Code-Dokumente zur .claude-Struktur beschreiben, dass projektbezogene Claude-Dateien im Projektordner liegen und über Git mit dem Team geteilt werden können. Genau das ist hier der entscheidende Punkt: Skills und Kontext reisen über das Repo, nicht über Zuruf.

Nicht zwingend.

Ein Claude-Team-Plan kann für Verwaltung, Abrechnung und Teamsteuerung sinnvoll sein. Für das reine Teilen von Projektkontext, Skills und Prototyp-Dateien ist er aber nicht die Voraussetzung.

Wenn eure Skills im Repo liegen, bekommt jede Person nach einem git pull denselben Stand. Lokale persönliche Einstellungen bleiben trotzdem lokal. Geteilte Projektregeln gehören ins Repo, persönliche Vorlieben nicht.

Die goldene Regel lautet: Nie gleichzeitig dieselbe Datei bearbeiten, wenn es vermeidbar ist.

Wenn eine Person am Dashboard-Use-Case arbeitet und eine andere am Onboarding-Use-Case, sollten diese Bereiche möglichst getrennt sein:

src/
  app/
    dashboard/
    onboarding/
  components/
    ui/
    layout/
  features/
    usecase-a/
    usecase-b/

Dann kann jede Person auf einem eigenen Branch arbeiten:

git checkout -b usecase-dashboard
git checkout -b usecase-onboarding

Oder ihr nutzt Git Worktrees, damit jede Person oder jeder Agent eine eigene Arbeitskopie hat. Die offiziellen Claude-Code-Worktree-Dokumente erklären dieses Muster für parallele Claude-Code-Sessions: Jede Session arbeitet isoliert in einer eigenen Working Copy, teilt aber dieselbe Git-Historie und denselben Remote.

Der wichtigste Teamfehler ist nicht „kein Tool“. Der wichtigste Fehler ist ein schlechter Arbeitsschnitt.

Schneidet nicht so:

• Person A verändert heute alle Komponenten
• Person B verändert gleichzeitig dieselben Komponenten
• Person C lässt den Agenten das ganze Layout umbauen

Schneidet besser so:

• Eine Person hält die UI-Basis sauber: Layout, Navigation, Design-Tokens
• Eine Person baut Use Case 1
• Eine Person baut Use Case 2
• Gemeinsame Komponenten werden nur bewusst geändert
• Jede Änderung kommt als kleiner Pull Request zurück

Für Prototyping ist ein vertikaler Schnitt oft besser als ein technischer Schnitt. Also nicht „du machst Frontend, ich mache Backend“, sondern: „du machst den kompletten Onboarding-Flow, ich mache den kompletten Dashboard-Flow“.

Damit der Prototyp wie ein Produkt wirkt, braucht ihr eine einzige Design-Quelle.

Legt zum Beispiel fest:

• Farben und Tokens
• Schriftgrößen
• Spacing
• Button-Varianten
• Card-Layout
• Formularzustände
• leere Zustände
• Namenskonventionen für Komponenten

Diese Regeln gehören nicht nur in Figma oder Obsidian. Sie müssen für den Agenten im Repo lesbar sein, zum Beispiel in docs/design-system.md oder direkt im Code.

Wenn jemand einen neuen Screen baut, lautet die Agenten-Anweisung nicht „mach es schön“, sondern:

Baue den Screen mit den vorhandenen Komponenten und halte dich an docs/design-system.md. Wenn eine neue Komponente nötig ist, schlage sie zuerst vor, bevor du sie baust.

So kann euer Ablauf aussehen:

1. Gemeinsames Repo erstellen.
2. Grundstruktur, Design-Regeln und CLAUDE.md anlegen.
3. Jede Person klont das Repo lokal.
4. Jede Person erstellt einen Branch oder Worktree für ihren Use Case.
5. Jede Person baut kleine, testbare Schritte.
6. Änderungen werden per Pull Request zusammengeführt.
7. Vor Nutzertests wird ein gemeinsamer Stand deployed oder lokal gemeinsam geprüft.
8. Feedback aus den Tests landet wieder in Issues oder Markdown-Notizen im Repo.

Parallelität klingt effizient, ist aber nicht immer der nächste Schritt.

Arbeitet zuerst gemeinsam an einem einzigen Strang, wenn:

• die Produktidee noch sehr unklar ist
• das UI-Konzept noch nicht steht
• ihr noch keine Komponentenbasis habt
• niemand im Team Git sicher nutzen kann
• der Prototyp noch aus einem einzigen großen Screen besteht

In diesem Fall ist das bessere Setup: Eine Person baut, eine Person reviewt, eine Person hält Kontext und Design-Regeln aktuell. Erst wenn die Basis stabil ist, teilt ihr in Use Cases auf.

Für euer Szenario ist das stabilste Setup:

GitHub-Repo + Projektkontext im Repo + CLAUDE.md + .claude/skills/ + klare Use-Case-Branches oder Worktrees.

Obsidian und Nextcloud bleiben euer Denkraum. GitHub oder GitLab wird die technische Wahrheit. Claude Teams ist optional, aber nicht nötig, um Skills und Kontext zu teilen.

• Vibe Coding: Deine erste App ohne Programmierkenntnisse bauen

• Claude Teams einrichten: Projekte, DNA und Rollen für dein Team

• Claude Skills und Plugins lokal speichern und mit Codex nutzen

• Claude Code für Nicht-Technische: Dateien verwalten, automatisieren und Apps bauen

• Obsidian-Backup für dein Second Brain: Sync, OneDrive, Google Drive und Git richtig einrichten