Claude Code bekommt eigene Teamregeln

Ein Coding-Agent soll eine Änderung vorbereiten. Das Team möchte dabei sehen, welche Tests gelaufen sind, welche Dateien betroffen sind und an welcher Stelle eine Freigabe fehlt. Solche Informationen landen bisher leicht in verschiedenen Fenstern. Anthropic hat am 1. Oktober Mods für Claude Code vorgestellt: Erweiterungen, mit denen Entwickler das Verhalten und die Oberfläche des Agenten selbst anpassen können. Für Softwareteams stellt sich damit eine konkrete Frage: Welche ihrer Arbeitsregeln sollten direkt im Werkzeug sichtbar und ausführbar werden?

Laut Ankündigung von Anthropic bestehen Mods aus kleinen TypeScript-Funktionen und werden über Plugins verteilt. Sie können beispielsweise Prompts verändern, Werkzeugaufrufe beeinflussen oder zusätzliche Bedienelemente anzeigen. Anthropic nennt unter anderem eine Anzeige für den Status der Build-Pipeline und zusätzliche Bestätigungen vor Änderungen an Produktionskonfigurationen. Das sind mögliche Anwendungen, kein Beleg dafür, dass ein beliebiges Plugin diese Aufgaben zuverlässig erfüllt.

Der Arbeitsablauf wird anpassbar

Ein Mod reagiert auf Ereignisse in Claude Code, etwa einen Werkzeugaufruf oder das Zeichnen eines Oberflächenelements. Er kann den Vorgang beobachten, verändern oder selbst beantworten. Die technische Übersicht beschreibt außerdem gemeinsam nutzbaren Zustand: Eine Funktion kann etwas zählen, eine andere zeigt den Stand an. So lässt sich eine Anzeige während der Arbeit aktualisieren.

Für die Auswahl des passenden Mittels lohnt sich eine Unterscheidung. Skills geben dem Agenten Anweisungen. MCP-Server stellen externe Werkzeuge bereit. Mods greifen innerhalb von Claude Code ein und können dessen Oberfläche erweitern. Wer nur wiederkehrende Projektvorgaben festhalten möchte, braucht dafür möglicherweise weiterhin lediglich einen Skill. Eine eigene interaktive Prüfungsansicht ist ein stärkerer Grund, sich Mods anzusehen.

Ich finde an der Neuerung vor allem interessant, dass ein Team seine Arbeitsweise im Werkzeug abbilden kann. Aus einer häufig wiederholten Rückfrage wie „Welche Tests hast du wirklich ausgeführt?“ könnte eine klar erkennbare Anzeige werden. Ob das hilft, hängt davon ab, welche Informationen sie tatsächlich erfasst.

Ein sinnvoller erster Versuch bleibt überschaubar

Als hypothetischen Einstieg würde ich eine kleine Statusansicht für eine einzelne Anwendung wählen. Sie zeigt den zuletzt ausgeführten Testbefehl, seinen Zeitpunkt und das Ergebnis. Dazu gehört die Information, auf welchen Arbeitsstand sich der Test bezog. Ändert der Agent danach erneut Code, sollte die Anzeige deutlich machen, dass das alte Testergebnis diesen neuen Stand noch nicht abdeckt.

Gerade hier liegt die eigentliche Entwicklungsarbeit. Ein grünes Symbol allein verrät wenig. Wurde der Test erfolgreich beendet oder lediglich gestartet? Wurde die Ausgabe vollständig gelesen? Hat der Agent nur die schnelle Prüfung eines einzelnen Moduls ausgeführt, während die betroffene Schnittstelle ungeprüft blieb? Das Team muss festlegen, welche Aussage es seiner Anzeige zutraut.

Ich würde zuerst mit einem kleinen Testprojekt arbeiten und absichtlich einen fehlgeschlagenen Test erzeugen. Anschließend müsste derselbe Versuch mit abgebrochener Ausführung und veraltetem Ergebnis stattfinden. Eine brauchbare Erweiterung zeigt diese Zustände verständlich an. Diese Vorschläge beschreiben einen möglichen eigenen Testaufbau; wir haben damit keine neue Mod-Erweiterung von Anthropic praktisch bewertet.

Ein Mod bekommt weitreichenden Zugriff

Zur Einführung gehört eine wichtige Eigenschaft aus der Dokumentation: Mods laufen mit den Zugriffsrechten des Nutzers. Sie können Dateien lesen und schreiben, Prozesse starten und Netzwerkanfragen ausführen. Sie sind laut Anthropic nicht durch die Sandbox für die Bash-Befehle des Agenten eingegrenzt. Eine Erweiterung kann daher sensible Projektinformationen erreichen. Auch die Herkunft einer kleinen Komfortfunktion verdient eine Prüfung.

Für Unternehmen erläutert Anthropic in der Administrationsdokumentation, wie zentral verwaltete Einstellungen die Auswahl einschränken. Die Option allowManagedModsOnly kann vom Nutzer eingebrachte Mods am Laden hindern. Bei Team- und Enterprise-Anmeldung oder vorhandenen verwalteten Einstellungen lädt ein eingebauter Schutz vor den Nutzer-Mods. Er schützt bestimmte verwaltete Vorgaben; die eigenen Datei- und Prozesszugriffe eines Mods werden dadurch nicht allgemein abgeschottet.

Daraus würde ich für ein Entwicklungsteam eine konkrete Zuständigkeit ableiten: Jemand prüft die Erweiterung, hält die freigegebene Version fest und entscheidet über Updates. Wenn ein Mod eine Freigabe anzeigen oder einfordern soll, muss das Team außerdem gezielt prüfen, was bei Fehlern oder beim Ausfall dieser Erweiterung passiert. Eine hübsche Bestätigungsfläche schafft für sich genommen noch keine belastbare Kontrolle.

Was Teams jetzt ausprobieren können

Mods benötigen laut aktueller Dokumentation Claude Code ab Version 2.1.287. Die Oberfläche wird im Terminal und im Code-Bereich der Desktop-App unterstützt; andere Ausführungsumgebungen haben Einschränkungen. Vor einem Team-Rollout sollte deshalb die tatsächlich verwendete Umgebung geprüft werden.

Der offizielle Einstiegsleitfaden zeigt eine Kontextanzeige als erstes Beispiel und weist darauf hin, dass sich die API zwischen Versionen ändern kann. Für eigene Erweiterungen bedeutet das laufende Pflege. Ich würde zunächst eine konkrete, häufig wiederkehrende Unterbrechung im Arbeitsablauf auswählen und prüfen, ob ein Mod sie nachvollziehbar reduziert.

Für die gemeinsame Bewertung solcher Abläufe bietet sich eine KI-Beratung an. Wenn daraus ein eigenes Werkzeug für das Team entsteht, gehört seine Wartung zur KI-Softwareentwicklung. Den Umgang mit Agenten und überprüfbaren Ergebnissen können Teams in KI-Workshops erproben.

Mein Maßstab wäre ein einfacher Vorher-nachher-Vergleich: Kann ein anderes Teammitglied nach der Änderung schneller erkennen, was der Agent erledigt hat und was noch offen ist? Daran lässt sich eine erste Mod-Idee gut messen.

Quellen und Links

Stand: 5. Oktober 2026. Grundlage sind die verlinkte Ankündigung vom 1. Oktober, die aktuelle Mods-Übersicht, die Administrationsdokumentation und der Einstiegsleitfaden von Anthropic. Die vorgeschlagene Statusansicht und ihre Prüffälle sind unsere redaktionelle Einordnung; daraus folgt kein Leistungs- oder Sicherheitsversprechen für ein konkretes Plugin.