Logo von martinzoeller.com mit den Buchstaben „MZ“ in Weiß auf dunkelblauem Hintergrund.
60-Sekunden-Impuls

Impuls: Claude Code: Welche Plugins brauchen wir? Welche davon gehören ins Repo?

15. Mai 2026 1 Min. Lesezeit
Portrait von Martin Zöller

Martin Zöller

Claude Code: Welche Plugins brauchen wir? Welche davon gehören ins Repo?

Plugins für Claude Code lassen sich nicht über einen Kamm scheren. Manche kann man getrost im Repo einchecken, andere lieber nicht — und der Unterschied liegt darin, was es mit der Arbeitsweise macht.

Wenn du dich wie ich täglich mit dem Thema befasst, sind die folgenden Namen nicht neu für dich: Figma für pixelgenaue Implementierungen von Designs, Serena für schnellere Code-Navigation, context7 gegen API-Halluzinationen oder Superpowers für… quasi alles.

Die spannende Frage ist: Welche davon brauchen wir? Um das zu beantworten, teile ich Plugins grob in zwei Kategorien ein:

  1. Plugins, bei denen sich das Team einig ist, dass sie ihre Arbeit ohne echten Nachteil vereinfachen. Ein Beispiel: Wenn deine UI/UX-Designer wunderschöne Figma-Designs erstellen, gewinnt jeder Engineer Zeit, sobald Claude Code diese Designs pixelgenau in Code gießen kann. Kein manuelles Heraussuchen von Abständen oder exakten Farben mehr.
  2. Plugins, die grundsätzlich beeinflussen, wie Claude Code funktioniert. Ein Beispiel: Mit Superpowers lassen sich neue Funktionen sehr detailliert planen. Bevor die erste Codezeile geschrieben wird, wird alles haarklein in Markdown-Dateien gegossen — unabhängig davon, ob der Engineer bereits einen klaren Weg im Kopf hat oder nicht. Das kostet Zeit und ist nicht für jeden die richtige Wahl. Die Implementierung ist am Ende wahrscheinlich wasserdicht, aber die Arbeit mit dem Tool verändert sich grundlegend.

Einen Konsens über Plugins der ersten Kategorie zu finden, ist recht einfach und ergibt sich in den ersten Wochen der Arbeit mit Claude Code wahrscheinlich automatisch. Hin und wieder kommt ein neues Plugin raus, dein Team probiert es aus, und entweder ist es ein No-Brainer, oder eben nicht.

Die Plugins der zweiten Kategorie sind keine No-Brainer, weil sie beeinflussen, wie ein Engineer mit dem Tool arbeitet. Stark vereinfacht gesagt: Ich kenne keine zwei Engineers, die gleich arbeiten. Heißt, du darfst deinen Engineers nicht aufzwingen, sie zu nutzen, und du darfst ebenfalls keinen Konsens im Team erzwingen.

Beide Plugin-Kategorien können jedoch ins Repo eingecheckt werden, da man ohne Enterprise- und MDM-Tanz ohnehin keine Möglichkeit hat, die Installation gewisser Plugins auf Laptops zu erzwingen oder zu verhindern. Eingecheckte Einstellungen sind eine Convenience-Funktion, keine Policy, und Engineers können dankend ablehnen.

Bonus-Tipp: Wie schaffe ich es, dass Engineers Plugins bestmöglich nutzen? Indem du einen Raum schaffst, in dem sie sich über solche Meta-Themen unbefangen (!) austauschen können.