Claude Code Best Practices fürs Team: 7, die halten

Die Claude Code Best Practices, die für ein Team zählen, sind keine Prompt-Tipps. Es sind sieben Regeln, die auch dann halten, wenn niemand hinsieht: eine kurze CLAUDE.md, die die CI kurz hält, ein gemeinsames Plugin, Permissions und Hooks im Repository, ein Issue zu einem PR, ein Test, der zuerst rot ist, und ein Reviewer, der den Code nicht geschrieben hat. Jede davon erzwingt eine Datei oder ein Check, nicht das Gedächtnis.

So führen wir jedes Repository, und KI schreibt heute unseren gesamten Code. Der Rest dieses Artikels zeigt, wie jede Praxis erzwungen wird, mit den echten Dateien.

Welche Claude Code Praktiken halten im Team?

Einzeltipps leben im Kopf einer Person. Eine Teampraxis braucht einen Ort, an dem sie steht, und einen Check, der merkt, wenn sie bricht:

Lesen Sie die Tabelle auch als Reihenfolge. Die ersten vier kosten einen Nachmittag. Die letzten drei verändern, wie die Arbeit fließt.

1. Warum CLAUDE.md kurz halten, und wie erzwingt man das?

CLAUDE.md und jede immer geladene Regeldatei landen bei jeder Anfrage im Kontext. Der Kostenleitfaden von Anthropic empfiehlt unter 200 Zeilen und Workflow-Anweisungen in Skills, die nur bei Bedarf laden.

"Halten Sie es kurz" hält etwa zwei Wochen. Also zählt unser Validator. Er rechnet CLAUDE.md und alle immer geladenen Regeln zusammen, deshalb liegt seine Grenze bei 300 Zeilen, nicht 200:

# CLAUDE.md + every .claude/rules/*.md that loads on every session
# (rules scoped with `paths:` load only under matching paths and are skipped)
if [ "$total_lines" -gt 300 ]; then
  log_critical "Context budget exceeded: $total_lines lines (max 300)."
fi

Er läuft in der CI jedes Repositorys. In Firmen- und Kunden-Repositorys lässt er den Build scheitern, in Code-Repositorys warnt er.

Die andere Hälfte ist, wohin eine Regel gehört. Der persönliche Arbeitsstil gehört nach ~/.claude. Alles, was das ganze Team befolgen muss, gehört ins Repository.

Wie man Regeln zwischen CLAUDE.md, AGENTS.md und persönlichen Dateien aufteilt, erklärt ausführlich Regeln für KI-Code im Team.

2. Warum ein gemeinsames Plugin statt Kopien?

Früher haben wir unsere Skills für Planung, Umsetzung und Review in jedes Repository kopiert. Innerhalb weniger Wochen liefen die Kopien auseinander, und manche waren leere Stubs. Disziplin hat das nicht gelöst. Ein Plugin schon: wizrd, unser internes Claude-Code-Plugin und CLI (nicht öffentlich). Skills, Agenten und Hooks leben in einem Repository, und jedes andere Repository aktiviert es mit zwei Zeilen in den Settings:

{
  "enabledPlugins": { "wizrd@digitaliko": true },
  "extraKnownMarketplaces": {
    "digitaliko": { "source": { "source": "directory", "path": "services/wizrd" } }
  }
}

Eine Korrektur am Review-Skill erreicht jetzt jede Session beim nächsten Start. Wie wir das Plugin selbst aufbauen, steht in Claude Code Skills und Plugins fürs Team.

3. Warum gehören Permissions ins Repository?

Weil ein deny im Repository jedes allow anderswo schlägt. Claude Code prüft zuerst deny-Regeln, dann ask, dann allow, über alle Settings-Dateien hinweg. Das Team entscheidet also einmal, in .claude/settings.json: deny für .env-Dateien und Schlüssel, ask vor einem Push, einem Merge oder einem Deploy, allow für die Skripte, mit denen der Agent seine eigene Arbeit prüft.

Alles Persönliche bleibt in ~/.claude/settings.json. Die Form und unsere genauen Einträge stehen in Claude Code Permissions: wann ist Skip Permissions sicher?.

4. Warum mit Hooks blockieren statt in CLAUDE.md zu bitten?

Ein Satz in CLAUDE.md ist eine Bitte. An einem Tag im Oktober hat ein Agent eine KI-Attributionszeile in mehrere Pull-Request-Beschreibungen unserer eigenen Repositorys getippt, in einer Session, deren CLAUDE.md genau das in klaren Worten verbot.

Die Lösung war ein PreToolUse-Hook, der jeden git commit-, gh pr- und gh issue-Befehl prüft, auch Dateien, die mit --body-file übergeben werden, und mit Exit 2 endet. Der Kommentar oben im Skript sagt es am besten: "A rule is a request. This is the lock."

Hooks haben ihre eigene Fehlerart: Sie können verstummen und trotzdem bestehen. Die vier Checks, die das finden, stehen in Claude Code Hooks, die still nichts tun.

5. Warum ein Issue zu einem PR?

Eine Agenten-Session vergisst. Ein GitHub-Issue nicht. Jede Aufgabe beginnt als Issue mit der Definition von "fertig", so geschrieben, dass ein Reviewer mit Ja oder Nein antworten kann, und endet als ein Pull Request mit Closes #N.

Das bringt drei Dinge, die eine Chat-Session nicht kann. Der Plan ist sichtbar, bevor die Arbeit beginnt. Zwei Agenten können parallel arbeiten, jeder in seinem eigenen Git-Worktree auf seinem eigenen Branch, ohne sich zu stören. Und die gemergten Pull Requests sind das Changelog, niemand schreibt ein Arbeitsprotokoll.

Der Plan Mode hilft innerhalb der Session. Wo er für ein Team nicht mehr reicht, steht in Claude Code Plan Mode: wann reicht er im Team?.

6. Warum muss der Test zuerst scheitern?

Ein Agent kann Tests schreiben, die bestehen, ob der Code funktioniert oder nicht. Deshalb lässt unser Gate die neuen oder geänderten Tests gegen den Basis-Branch laufen, vor der Korrektur. Bestehen sie auch dort, beweisen sie nichts, und der Pull Request geht zurück. Nur ein Test, der ohne die Änderung rot und mit ihr grün ist, zählt. Den ganzen Mechanismus beschreibt Red-Green-TDD mit KI-Agenten.

7. Warum sollte ein anderer Agent den Code reviewen?

Der Autor-Agent hat sich selbst schon überzeugt. Eine frische Session, die nur den Diff liest, findet, was der Autor übersprungen hat. Unser CI-Reviewer bekommt eine Read-only-Tool-Liste (git diff, git log, gh pr diff, Read, Grep) und eine Review-Checkliste aus dem Repository. Er kommentiert. Er gibt nie frei. Die Branch Protection verlangt einen Menschen, der Merge ist also immer eine menschliche Entscheidung. Einrichtung und Prompt stehen in KI-Code-Review mit Claude Code in der CI.

Wo sollte ein Team anfangen?

Nicht mit allen sieben auf einmal. Die Reihenfolge, die bei uns funktioniert hat:

Die ersten drei dauern in einem bestehenden Repository einen Tag. Die vierte ist eine Gewohnheit, und es braucht einige Wochen Review-Kommentare, bis das Team Issues schreibt, die ein Agent ohne Rückfrage zu Ende bringt.

Wie weit ist Ihr Team heute?

Zählen Sie, was schon in Ihren Repositorys steht, nicht, was die Leute sagen, dass sie tun:

Settings, Hooks, Gate und Review-Workflow können Sie aus unserem Claude Code Production Starter kopieren, MIT-lizenziert.

Möchten Sie diese Praktiken in Ihren Repositorys?

Wir richten sie direkt in den Repositorys eines Teams ein, gemeinsam mit den Entwicklern, im Rahmen von AI-native SDLC für Entwicklerteams. KI schreibt heute unseren gesamten Code, und ein Senior steht für das Ergebnis gerade. Seit 2023 haben wir 15+ Produktionsprojekte geliefert.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Welche der sieben würde in Ihrem Team als Erste brechen, wenn niemand prüft?

Häufige Fragen

Was sind die wichtigsten Claude Code Best Practices?

Für ein Team: CLAUDE.md kurz halten und das Limit erzwingen, Skills und Hooks als ein Plugin teilen, Permissions ins Repository legen, mit Hooks blockieren statt in Prosa zu bitten, ein Issue zu einem PR führen, jede Änderung mit einem Test belegen, der zuerst rot ist, und einen anderen Agenten reviewen lassen, bevor ein Mensch merged.

Wie lang sollte CLAUDE.md sein?

So kurz, dass sie sich bei jeder Anfrage lohnt. Anthropic empfiehlt unter 200 Zeilen. Wir zählen CLAUDE.md und jede immer geladene Regeldatei zusammen und lassen die CI in Firmen- und Kunden-Repositorys ab 300 Zeilen scheitern.

Gehören Claude Code Settings ins Git?

Der Teamteil ja: .claude/settings.json mit Permissions und Hooks gehört ins Repository. Persönliche Vorlieben gehören in ~/.claude/settings.json und lokale Abweichungen in .claude/settings.local.json, die nicht ins Git kommt.

Wie teilt man Claude Code Skills im Team?

Als Plugin, das jedes Repository in seinen Settings aktiviert. Kopien von Skills in jedem Repository laufen innerhalb weniger Wochen auseinander; ein Plugin gibt jeder Session dieselben Skills, Agenten und Hooks.

Ist der Plan Mode für jede Aufgabe eine Best Practice?

Zum Erkunden vor einer größeren Änderung ja. Im Team muss der Plan aber auch dort stehen, wo andere ihn lesen können, etwa im Issue mit seinen Akzeptanzkriterien, nicht nur in der Session eines Entwicklers.