Bisher war der Rezept-Planer ein Ein-Personen-Projekt. Sobald weitere Personen mit einsteigen, wird eine Frage wichtig, die in den bisherigen Kapiteln nur am Rande vorkam: Wie sorgt man dafür, dass Claude Code bei jeder Person im Team zu ähnlich passenden Ergebnissen kommt - nicht nur bei einer einzelnen Person, die alle Regeln im Kopf hat?

CLAUDE.md gehört ins Repository

Die gute Nachricht: Die CLAUDE.md aus Kapitel 10 ist eine ganz normale Datei im Projektordner und wird deshalb automatisch mit dem restlichen Code über Git aus Kapitel 24 versioniert und geteilt. Checkt sich eine Kollegin oder ein Kollege das Repository aus und startet dort Claude Code, gelten dieselben Regeln automatisch - Tech-Stack, Konventionen, Testanforderungen, alles, was für den Rezept-Planer in der CLAUDE.md steht.

Was in eine team-geteilte CLAUDE.md gehört

• Objektive Fakten über das Projekt: Tech-Stack, Ordnerstruktur, wie man Tests ausführt.
• Gemeinsam vereinbarte Konventionen: Namensschemata, Commit-Nachrichten-Format, bevorzugte Muster.
• Bewusste Team-Entscheidungen, wie die Kategorie-Beschränkung aus Kapitel 18, damit sie nicht wiederholt neu diskutiert werden.

Nicht hinein gehören dagegen rein persönliche Vorlieben einzelner Personen ("Ich möchte immer auf Deutsch angesprochen werden") - dafür ist, wie in Kapitel 23 gezeigt, die nutzerweite, persönliche Konfiguration der richtige Ort, nicht die geteilte Projektdatei.

Konsistenz im Team

Eine gepflegte, aktuelle CLAUDE.md sorgt dafür, dass Claude Code bei jeder Person im Team von denselben Grundannahmen ausgeht - unabhängig davon, wer gerade eine Anfrage stellt. Das verhindert eine ganz bestimmte Art von Inkonsistenz: dass eine Person versehentlich eine Datenbank vorschlägt, obwohl das Team sich bewusst für eine einfache JSON-Datei entschieden hat, nur weil diese Entscheidung nirgends schriftlich festgehalten war.

CLAUDE.md aktuell halten

Genau wie normaler Code kann eine CLAUDE.md veralten, wenn sie nach einer wichtigen Änderung nicht mitgepflegt wird. Ein einfaches, wirksames Muster: nach einer größeren, team-relevanten Entscheidung direkt fragen, ob die CLAUDE.md angepasst werden sollte - ähnlich wie im Speicher-Beispiel aus Kapitel 23.

> Wir haben uns gerade im Team darauf geeinigt, dass jede neue Route in server.js einen eigenen Test in tests/ bekommen muss, bevor sie gemerged wird. Ergänz das bitte in der CLAUDE.md.

Damit ist Block 5 abgeschlossen: Kontextfenster, Speicher und Teamarbeit. Der letzte Block dieser Serie widmet sich Profi-Tipps zu Kosten, typischen Anfängerfehlern - und einer Zusammenfassung der gesamten Serie.