Claude Code für Teams: Ein Playbook zur Kompetenzstandardisierung

Setzen Sie fünf Entwickler mit Claude Code zusammen, und Sie erhalten fünf verschiedene Tools. Einer hat eine CLAUDE.md-Datei mit starken Meinungen zum Testen. Einer hat das skills-Verzeichnis noch nie geöffnet. Einer hat vor drei Wochen einen Debugging-Skill aus einem GitHub-Thread installiert und vergessen, es jemandem mitzuteilen. Zwei verwenden die Standardeinstellungen, was bedeutet, dass Claude ihre Konventionen in jeder Sitzung neu errät.

Der Code, der in Ihrer PR-Warteschlange landet, spiegelt diese Aufteilung wider. Einige Diffs enthalten zuerst geschriebene Tests und eine saubere Commit-Historie. Andere enthalten einen plausibel aussehenden Fix für einen Fehler, den niemand tatsächlich diagnostiziert hat. Gleiches Modell, gleiches Repo, gleiche Woche, fünf verschiedene Ausgabequalitäten, und der Reviewer fängt alles manuell ab.

Dies ist ein Problem der persönlichen Konfiguration, das sich als Teamproblem tarnt. Individuell ist das Setup jedes Entwicklers vertretbar. Kollektiv hat das Team keinen Mindeststandard. Niemand hat sich darauf geeinigt, wie „gut“ aussieht, wenn Claude den ersten Entwurf erstellt, daher kann niemand diese Linie halten. Dieser Artikel handelt von der Lösung: projektbezogene Skills, die im Repo statt auf Laptops leben, und die Governance und Einführung, die sie dauerhaft macht.

Die Lösung liegt dort, wo der Skill lebt, nicht in dem, was er tut

Claude Code liest Skills von zwei Orten. Persönliche Skills befinden sich in ~/.claude/skills/, sind an eine Maschine gebunden, für Teamkollegen unsichtbar und verschwinden in dem Moment, in dem der Entwickler den Laptop wechselt. Projekt-Skills befinden sich in .claude/skills/ innerhalb des Repositories selbst, committet zusammen mit dem Code, den sie steuern.

Dieser zweite Speicherort ist der ganze Trick. Ein Projekt-Skill ist eine Datei in Git: Er erhält einen Diff, einen Reviewer, eine Commit-Nachricht, die erklärt, warum das Debugging einem hypothesenbasierten Zyklus folgen sollte, anstatt dem, was sich an diesem Tag richtig anfühlte. Wenn jemand den Skill verbessert, wird die Verbesserung beim nächsten Pull an alle ausgeliefert, genauso wie ein Linter-Konfigurationsupdate.

Vergleichen Sie das mit der Alternative, zu der die meisten Teams zuerst greifen: einer Wiki-Seite mit dem Titel „How we use Claude“, die drei Leute gelesen haben und niemand durchsetzt. Eine Wiki-Seite ist ein Ratschlag. Ein Projekt-Skill ist eher eine Abhängigkeit: Claude lädt seine Beschreibung zu Beginn jeder Sitzung in diesem Repo und wendet sie automatisch an, wenn eine Aufgabe übereinstimmt, ohne dass jemand sich daran erinnern oder sie im Prompt erneut erklären muss.

Das praktische Ergebnis ist, dass „der Standard unseres Teams“ aufhört, ein Satz in einem Onboarding-Dokument zu sein, und zu etwas wird, das Claude tatsächlich identisch ausführt, egal ob es die Sitzung des Tech Leads oder die Sitzung des neuen Mitarbeiters am ersten Tag ist.

Was zuerst standardisiert werden sollte

Versuchen Sie nicht, Ihre gesamte Ingenieurkultur auf einmal in Skills zu kodieren. Drei Bereiche decken den Großteil der Unterschiede ab, die wir zwischen Entwicklern im selben Team sehen, und jeder hat einen getesteten, bewerteten Skill, den Sie als konkretes Beispiel dafür anführen können, wie „gut“ aussieht, selbst wenn Sie am Ende Ihre eigene, auf Ihren Stack zugeschnittene Version schreiben.

Eine Review-Checkliste. Die Lücke zwischen einem Review, das echte Fehler findet, und einem Review, das Präferenzen bei der Variablennamenvergabe findet, wird genau durch einen guten Review-Skill geschlossen. Code Review Checklist erzielt in unseren Tests 8.4/10 Punkte: Bei einem 600-Zeilen-PR fand es einen echten Off-by-one-Fehler und zwei Dead-Code-Pfade und produzierte null rein stilistische Beanstandungen. Wenn jeder Reviewer diese Qualität des ersten Durchlaufs erhält, bevor ein Mensch den Diff öffnet, verbringen Senior-Ingenieure ihre Review-Zeit mit Architektur, anstatt das zu finden, was eine Checkliste hätte finden sollen.

TDD-Disziplin. Test-Driven Development aus Jesse Vincents Superpowers-Sammlung erzielt 9.6/10 Punkte. Wir haben es in einer Drei-Feature-Sitzung ausgeführt, und Claude schrieb jedes Mal zuerst den fehlschlagenden Test und weigerte sich, den Zyklus zu überspringen, selbst wenn eine Abkürzung verfügbar war. Es ist ein reiner Verhaltens-Skill, ohne Skripte oder externe Tools, was es am einfachsten macht, ihn universell einzusetzen: „Schreiben Sie zuerst den Test“ hängt nicht von Ihrem Framework ab.

Ein Debugging-Protokoll. Systematic Debugging, ebenfalls 9.6/10, ersetzt die Standard-Schleife „versuche einen plausiblen Fix“ durch reproduzieren, hypothesieren, instrumentieren, verifizieren. In unserem Test identifizierte es die Grundursache einer Race Condition, die bereits drei auf Vermutungen basierende Fixes überlebt hatte. Dies ist der Skill, der in einem Team am wichtigsten ist, da das „Raten und Prüfen“-Debugging die größte Varianz in der Ausgabe erzeugt, und ein gemeinsames Protokoll diese Lücke schließt.

Drei Skills. Nicht die zwanzig, die Sie hinzufügen möchten, sobald die ersten drei funktionieren.

Wer einen neuen Skill genehmigt

Sobald Skills im Repo leben, muss jemand entscheiden, was hinzugefügt wird, und das ist der Teil, den Teams überspringen, bis es sie beißt. Ein Skill sind Anweisungen, denen Claude automatisch folgt, und manchmal Skripte, die Claude ausführt, was ihn in dieselbe Vertrauenskategorie wie ein neues npm-Paket oder eine CI-Aktion stellt. Niemand würde zulassen, dass ein Entwickler eine beliebige Abhängigkeit zu package.json hinzufügt, ohne ein PR-Review. Ein Skill verdient dieselbe Prüfung.

Die Mechanik ist einfach, sobald Sie sich dazu verpflichten, es so zu behandeln. Ein neuer Skill gelangt über einen normalen Pull Request ins Repo, mit demselben Branch-Schutz wie jede andere Änderung. Der Reviewer liest die gesamte SKILL.md und prüft auf Anweisungen, die nicht dem angegebenen Zweck entsprechen, und auf jeden Netzwerkaufruf, dessen Grund nicht offensichtlich ist. Wenn der Skill Skripte bündelt, öffnet jemand diese tatsächlich. Dies ist dasselbe Zwei-Minuten-Audit, das wir in unserem Sicherheitsleitfaden durchgehen.

Weisen Sie einen Verantwortlichen zu, eine Person statt eines Komitees, normalerweise denjenigen, der den Skill vorgeschlagen hat, oder einen rotierenden Tech Lead, der dafür verantwortlich ist, dass die Beschreibung des Skills korrekt und seine Anweisungen aktuell bleiben. Wenn die Trigger-Phrase eines Skills bei falschen Aufgaben ausgelöst wird oder seine Anweisungen vom Workflow abweichen, für den er geschrieben wurde, behebt dieser Verantwortliche dies oder zieht ihn zurück.

Versionieren Sie es wie alles andere im Repo. Wenn ein Skill sein Verhalten erheblich ändert, ist das eine Notiz in der PR-Beschreibung wert und, für alles mit echtem Verhaltensgewicht, eine Erwähnung im Standup, damit die Leute wissen, dass ihre Sitzungen ab heute anders funktionieren werden.

Onboarding ist das eigentliche Killer-Feature

Hier ist der Teil, der leicht unterbewertet wird, wenn Sie dies einem skeptischen Teamleiter vorstellen: Ein neuer Mitarbeiter klont das Repo am ersten Tag und erhält dieselbe Review-Disziplin, dieselbe Test-First-Gewohnheit und dasselbe Debugging-Protokoll wie die Person, die seit zwei Jahren dabei ist. Nicht, weil sie ein 40-seitiges Onboarding-Dokument genau gelesen haben. Weil die Skills bereits in .claude/skills/ liegen und Claude sie in dem Moment aufnimmt, in dem der neue Mitarbeiter das Projekt öffnet.

Denken Sie darüber nach, wie Onboarding normalerweise ohne dies aussieht. Ein Senior-Ingenieur erklärt die Testphilosophie des Teams in einem 1:1-Gespräch, der neue Mitarbeiter nickt, und drei Wochen später ist die Hälfte davon unter Termindruck verflogen, weil unter Druck entstandene Gewohnheiten standardmäßig auf das Schnellste zurückgreifen. Mit Projekt-Skills ist die Disziplin keine Erinnerung, die der neue Mitarbeiter aufrechterhalten muss. Es ist Infrastruktur, die bei ihrem ersten PR genauso durchgesetzt wird wie bei ihrem hundertsten.

Es schließt auch die Lücke zwischen den Senioritätsstufen. Die Sitzung eines Junior-Entwicklers, der denselben Debugging-Skill wie ein Staff Engineer ausführt, erzeugt eine Ausgabe auf einem viel näheren Qualitätsniveau, als die beiden ohne Unterstützung erreichen würden, da ein Großteil dessen, was eine gute Debug-Sitzung von einer schlechten trennt, Prozedur und nicht Erfahrung ist.

Wenn Sie den Rest der Claude Code-Schicht noch nicht eingerichtet haben, lohnt es sich, dies vorher oder gleichzeitig zu tun. Unser Setup-Leitfaden behandelt die CLAUDE.md- und Berechtigungsebenen, auf denen Projekt-Skills aufsetzen.

Wie man erkennt, ob es tatsächlich funktioniert

Widerstehen Sie dem Drang, ein Dashboard dafür zu erfinden. Das gewünschte Signal fließt bereits durch die Tools, die Sie haben.

Beobachten Sie das Volumen der PR-Review-Kommentare und, noch wichtiger, den Kommentartyp. Wenn Reviewer weniger Kommentare wie „Haben Sie das getestet?“ und „Dies behandelt den Null-Fall nicht“ hinterlassen und mehr Kommentare zu tatsächlichen Design-Kompromissen, dann erfüllen die Review- und TDD-Skills ihre Aufgabe. Wenn die Anzahl der Kommentare sinkt, die verbleibenden Kommentare aber immer noch Korrektheitsfehler finden, die der Skill hätte finden sollen, ist der Skill noch nicht richtig abgestimmt, nicht das Team.

Beobachten Sie die Regressionsrate. Ein Debugging-Skill, der eine Hypothesen-Verifizierungs-Disziplin durchsetzt, sollte bedeuten, dass weniger „behobene“ Fehler eine Woche später wieder auftauchen, da „Raten und Prüfen“-Fixes genau die Art sind, die zurückkommen. Dies ist ein langsameres Signal, das normalerweise über ein oder zwei Monate statt über einen Sprint sichtbar wird, aber es ist am wichtigsten für ein Team, das zuvor von „behobenen“ Fehlern betroffen war.

Beobachten Sie die Zeit bis zur ersten Genehmigung von PRs, wobei ein Datenpunkt als Hinweis und eine anhaltende Verschiebung über mehrere Sprints hinweg als echtes Signal zu werten ist. Und sprechen Sie mit den Leuten: Ob Entwickler das Gefühl haben, dass Claudes Ausgabe konsistenter geworden ist, ob ein neuer Mitarbeiter sagt, dass die Codebasis schneller lesbar war als bei ihrem letzten Job, ist im ersten Monat mehr wert als alles oben Genannte.

Ein vierwöchiger Rollout für ein zehnköpfiges Team

Woche 1. Wählen Sie ein Repo, nicht alle, und einen Skill; die Review-Checkliste lässt sich normalerweise am einfachsten verkaufen, da Reviewer den Nutzen sofort erkennen. Fügen Sie es über einen normalen PR zu .claude/skills/ hinzu. Bitten Sie zwei oder drei Freiwillige, es bei ihren nächsten Reviews zu verwenden und in einem kurzen Thread, nicht in einem Meeting, Bericht zu erstatten.

Woche 2. Fügen Sie den TDD-Skill demselben Repo hinzu. Dies ist derjenige, der auf den größten Widerstand stößt, da er die Art und Weise ändert, wie Leute Code schreiben, anstatt wie sie ihn reviewen. Erwarten Sie Reibung und behandeln Sie sie als Daten. Lassen Sie den Debugging-Skill vorerst weg und sammeln Sie spezifische Beschwerden („er wird bei Aufgaben ausgelöst, bei denen ich es nicht möchte“), um die Beschreibung des Skills zu korrigieren, bevor Sie versuchen, das Verhalten der Leute zu ändern.

Woche 3. Fügen Sie den Debugging-Skill hinzu. Inzwischen hat das Team ein Gefühl dafür, wie sich Projekt-Skills verhalten, daher sollte diese Ergänzung schneller gehen. Führen Sie ein kurzes Retro zu den Daten der letzten zwei Wochen durch: Ändern sich die Review-Kommentare, vermeidet jemand stillschweigend die Skills, warum. Passen Sie die Trigger-Beschreibungen an, wenn ein Skill zu oft oder nicht oft genug ausgelöst wird.

Woche 4. Rollen Sie dieselben drei Skills auf die restlichen Repos des Teams aus. Schreiben Sie eine kurze Notiz in die README jedes Repos, die erklärt, was in .claude/skills/ ist und warum, damit der nächste neue Mitarbeiter nicht fragen muss. Legen Sie den Genehmigungsprozess aus dem obigen Abschnitt als feste Regel fest, da der wahre Test der Governance ist, was mit dem vierten Skill passiert, den jemand vorschlägt, nicht mit den ersten drei.

Vier Wochen, drei Skills, ein Repo, skaliert auf den Rest der Organisation. Widerstehen Sie der Versuchung, dies zu komprimieren; die Reibung in Woche 2 ist Information, die Sie haben möchten, bevor Sie fünf Skills über zehn Repos hinweg ausführen.

Die Plugin-Option für Multi-Repo-Organisationen

Projekt-Skills lösen die Standardisierung innerhalb eines Repos, aber die meisten Engineering-Organisationen sind nicht ein einziges Repo. Wenn Ihre zehn Entwickler über fünfzehn Dienste hinweg arbeiten, wird das manuelle Kopieren von .claude/skills/ in jedes einzelne und das manuelle Synchronisieren zu einer eigenen Wartungsaufgabe, die nach dem zweiten Quartal stillschweigend eingestellt wird.

Claude Code-Plugins lösen diese Schicht. Ein Plugin bündelt eine Reihe von Skills, plus Befehle und andere Konfigurationen, in einer installierbaren Einheit, die nicht an die Git-Historie eines einzelnen Repos gebunden ist. Anstatt fünfzehn Kopien derselben drei Skills, die unabhängig voneinander driften, pflegt die Organisation ein Plugin, einmal versioniert, und jedes Repo installiert davon. Ein Update des Debugging-Skills verbreitet sich dann überall dort, wo das Plugin installiert ist, anstatt fünfzehn separate PRs zu erfordern.

Dies ist eine Steigerung der operativen Komplexität und lohnt sich erst, wenn Sie den Schmerz der Synchronisierung mehrerer Repos gespürt haben. Für ein zehnköpfiges Team mit ein oder zwei Repos ist der hier beschriebene Projekt-Skills-Ansatz der richtige Endpunkt. Für eine Organisation, die dieselben Standards über viele Codebasen hinweg anwendet, behandelt unser Plugins-Leitfaden die Mechanismen der Paketierung und Verteilung.

Der Fehlermodus: Zwanzig Skills am ersten Tag vorschreiben

Die häufigste Art, wie dies schiefgeht, ist nicht technisch, sondern ein Rollout-Fehler. Ein Tech Lead liest über Projekt-Skills, wird begeistert und committet zwanzig davon an einem Nachmittag: Review, TDD, Debugging, plus ein Dutzend weitere für Logging-Konventionen, Commit-Nachrichtenformat, API-Design, Barrierefreiheit und was sonst noch an einem Donnerstagnachmittag um 16 Uhr vernünftig erschien.

Zwei Dinge gehen schief. Erstens beginnen sich überlappende Beschreibungen bei falschen Aufgaben oder gegenseitig auszulösen, weil niemand überprüft hat, ob die Trigger-Phrase von Skill drei mit der von Skill elf kollidiert; diese Konflikte sind einer der häufigsten Mängel, die wir beim Testen sehen, und sie werden schlimmer, je höher die Anzahl steigt. Zweitens, und schädlicher, entwickelt das Team nie Vertrauen in die Skills, weil eine Woche unter zwanzig neuen Regeln sich wie eine Compliance-Übung anfühlt, und die Leute beginnen, Claude zu umgehen, anstatt mit ihm zu arbeiten.

Drei Skills, über einen Monat hinweg eingeführt, wobei echtes Feedback jeden einzelnen formt, bevor der nächste hinzukommt, schafft Vertrauen, das zwanzig auf einmal eingeführte Skills niemals erreichen werden. Wenn Ihr Team noch entscheidet, wo es anfangen soll, sind unsere Rankings für Coding-Skills nach getesteter Punktzahl geordnet, was ein vernünftiger Filter ist, um den nächsten nach Ihren ersten drei auszuwählen.

FAQ

Funktionieren projektbezogene Skills genauso wie persönliche?

Ja, das Format ist identisch. Der einzige Unterschied ist der Speicherort: .claude/skills/ im Repo statt ~/.claude/skills/ auf einem Laptop. Claude Code lädt beide auf die gleiche Weise. Wenn ein Skill an beiden Orten mit demselben Namen existiert, hat die Projektversion in der Regel Vorrang für dieses Repo, was genau das Verhalten ist, das Sie für einen Teamstandard wünschen.

Wird dies Claude für alle im Team verlangsamen?

Kaum. Jeder installierte Skill kostet ungefähr 100 Tokens an ständig geladenen Metadaten. Drei Projekt-Skills in einem Team fügen weniger stehenden Kontext hinzu, als ein einzelner verbundener MCP-Server typischerweise tut. Die wahren Kosten, dies falsch zu machen, sind nicht die Geschwindigkeit, sondern die Trigger-Verwirrung durch überlappende Beschreibungen, weshalb der oben genannte Rollout-Plan Skills einzeln hinzufügt.

Was, wenn ein Entwickler mit dem TDD- oder Debugging-Standard des Teams nicht einverstanden ist?

Das ist ein Gespräch, das vor dem Mergen des Skills im PR-Review geführt werden sollte, an derselben Stelle, an der Sie es über eine Linter-Regel führen würden. Sobald es im Repo ist, gilt es für alle, aber „alle“ sollte bedeuten, dass jeder während des Reviews die Möglichkeit hatte, sich zu äußern, nicht dass eine Person unilateral entschieden und auf main gepusht hat.

Sollten wir Skills vorschreiben oder optional lassen?

Projekt-Skills werden automatisch für jeden geladen, der das Repo hat, daher gibt es keinen separaten „Vorschreiben“-Schritt, sie sind einfach Teil der Codebasis. Was Sie optional machen können, ist der Beitrag: Nicht jeder Entwickler muss neue Skills vorschlagen, aber die Sitzung jedes Entwicklers führt die zusammengeführten aus. Behandeln Sie die Merge-Entscheidung als Prüfpunkt.

Wie unterscheidet sich das vom bloßen Schreiben einer langen CLAUDE.md?

Ladeverhalten. CLAUDE.md wird in jede Sitzung geladen, unabhängig davon, was der Entwickler an diesem Tag tut, was es für Fakten richtig macht, die immer gelten: Build-Befehle, Architektur, Namenskonventionen. Ein Skill wird nur geladen, wenn eine Aufgabe seiner Beschreibung entspricht, was es für eine Prozedur richtig macht, die Sie manchmal benötigen: wie das Team debuggt, wie das Team Reviews durchführt. Wenn Ihre CLAUDE.md einen langen Abschnitt enthält, der beschreibt, wie Tests geschrieben oder ein Review strukturiert werden, sollte dieser Abschnitt stattdessen zu einem Skill werden.