Ivo Kund war zunächst skeptisch. Mods? Claude Code hatte doch schon Hooks, was sollte da noch Besonderes kommen? So beginnt sein „First look at Claude Code mods“, und der Untertitel verrät das Urteil gleich mit: „spoiler: yes, use one now!“ Kund schreibt auf seinem Blog über die Arbeit mit KI-Agenten; der Beitrag ist ein kurzer Erfahrungsbericht nach den ersten eigenen Mods.
Was Mods sind und warum sie mehr können als Hooks
Mods sind Erweiterungen, die das Verhalten und die Oberfläche von Claude Code verändern. Auf den ersten Blick klingt das wie Hooks, also kurze Skripte, die auf Ereignisse reagieren und etwa Logging oder Formatierung übernehmen. Genau daran setzte Kunds Skepsis an. Was Mods im Einzelnen können, erklärt er bewusst nicht: Er will es weder nacherzählen, noch empfiehlt er, sich durch das Handbuch zu arbeiten. Seine Kurzfassung lautet, dass sie alles mit deinem Claude Code anstellen können und du nicht wissen musst, wie sie funktionieren.
Was das praktisch heißt, zeigen seine Beispiele: Ein Mod blendet ein eigenes Seitenpanel ein, ein anderer verwandelt Textstellen im Terminal in anklickbare Links. Das geht über das hinaus, was man von Hooks kennt, die auf einzelne Ereignisse reagieren.
Der Einstieg: einfach Claude selbst fragen
Die beste Empfehlung im Beitrag: gar nicht erst versuchen, das Handbuch zu lesen. Stattdessen soll man Claude selbst fragen, und Kund liefert den Prompt gleich mit: „Claude Code has mods now. Given the workflows we usually use and the type of work we do here, what are some mods we could build that would be super useful?“ Sinngemäß also: Welche Mods würden uns bei unseren üblichen Abläufen am meisten helfen? Danach lässt er Claude einige davon direkt bauen. Das klingt ungewohnt, ist aber konsequent. Wer ein Werkzeug nutzt, das Code versteht und generiert, kann es auch für die Erweiterung der eigenen Werkzeuge einsetzen.
Das hat zwei Vorteile. Erstens entfällt die Einarbeitung, weil das Modell die Abläufe im eigenen Projekt bereits kennt. Zweitens sind die Vorschläge praxisnah, weil sie nicht aus einem Featurekatalog stammen, sondern aus dem konkreten Arbeitsalltag. Dass man nicht verstehen muss, wie die Mods intern funktionieren, senkt die Hemmschwelle zusätzlich.
Live-Visualisierung längerer Workflows
Kunds erstes Beispiel ist ein Visualisierungs-Mod für lang laufende Workflows. Wer Claude Code für umfangreiche Aufgaben nutzt, kennt das Problem: Ein Workflow läuft, im Terminal erscheint ein endloser Textstrom, und am Ende hat man den Verlauf der einzelnen Schritte nicht mehr im Kopf. Der Mod öffnet bei großen Workflows automatisch ein Seitenpanel rechts, das nicht nach Claude Code aussieht und sich, zu Kunds sichtlicher Freude, mit der Maus in der Breite verstellen lässt. Er nutzt es für die beiden Workflows, die er in einem früheren Beitrag beschrieben hat: Aufgabenvorbereitung und Umsetzung.
Das Panel zeigt den Ablauf als Folge von Blöcken. Die Rechtecke stehen für Kritikrunden, in denen mehrere Agenten den Plan bemängeln, rosa markiert Eskalationen und grün den erfolgreichen Endzustand. Ein Vorbereitungslauf, den Kund zeigt, dauerte zwei Stunden; mit der Visualisierung lasse er sich auf einen Blick erfassen. Auch der Build-Workflow, der Code schreibt und ausliefert, wird so nachvollziehbar. Er umfasst oft Dutzende einzelne Schritte: Code-Reviews und Korrekturen, Prüfungen in Entwicklungs- und Produktionsumgebung, Datenreparaturen, Merges und Deployments.
In der gezeigten Aufzeichnung eines solchen Laufs waren einige Prüfungen in der Entwicklungsumgebung rosa Eskalationen, die Kund selbst übernehmen musste. Das erste Deployment scheiterte an einem Schwachstellen-Scan, wurde korrigiert und erneut ausgerollt. Vor dem Abschluss führte der Agent fünf letzte Prüfungen in der Produktion durch. Eine solche visuelle Spur hilft bei der Fehlersuche und dabei, im Team zu erklären, was passiert ist.
Hyperlinks für Ticketnummern
Nicht jeder Mod muss ein großes Dashboard sein. Das zweite Beispiel erfüllt einen Wunsch, den Kund schon lange hatte, und betrifft ein Detail, das jeder kennt, der mit Issue-Trackern arbeitet. Claude erwähnt im Terminal beiläufig eine GitHub-Referenz wie #2443 und weiß, was gemeint ist, weil es den Kontext hat. Der Mensch vor dem Bildschirm weiß es nicht: Er sucht die Nummer, öffnet den Browser, navigiert zum Repository und landet beim Ticket. Im Alltag ist das eine kleine, aber stetige Reibung.
Ein Mod löst das, indem er jede Ticketnummer im Terminal in einen anklickbaren Link verwandelt. Kunds Auftrag an Claude bestand aus einem einzigen Satz: „Make it so that whenever I see a ticket number in the terminal, it is a hyperlink.“ Solche Mikro-Modifikationen zeigen, dass der Wert von Mods nicht nur in großen Visualisierungen liegt. Oft sind es die kleinen Erweiterungen, die Reibung wegnehmen, an Stellen, die man schon lange nicht mehr bewusst wahrnimmt.
Mods und Wegwerf-Software
Kund ordnet Mods in einen größeren Zusammenhang ein. Er sieht sie und OpenAIs gerade erschienene Intelligent UI als spannende Schritte in die Richtung, die manche Zukunftsforscher Disposable Software nennen, also Wegwerf-Software: Software, die nicht monatelang geplant, gestaltet und versioniert wird, sondern in Minuten für einen konkreten Zweck entsteht, eine Weile genutzt und dann verworfen oder ersetzt wird.
Mods passen in dieses Bild. Sie sind klein, schnell geschrieben, auf eine Aufgabe zugeschnitten und jederzeit austauschbar. Wenn das Modell den eigenen Workflow kennt, schlägt es die passenden Mods selbst vor – genau so ist Kunds Liste für die nächsten Mods entstanden.
Kund ist sicher, dass Codex, Grok, Gemini und praktisch alle anderen sehr bald ebenfalls Mods haben werden. Trifft das zu, lohnt der Einstieg schon jetzt, weil die Konzepte übertragbar sind. Es geht dann weniger darum, ein Produkt zu lernen, als um eine neue Art, Software im Alltag zu verwenden.
Was als Nächstes möglich wird
Am Ende steht eine Liste mit Mod-Ideen, die Claude selbst vorgeschlagen hat. Sie zeigt, wie vielfältig die Anwendungsfälle inzwischen sind. Etwa ein Jira-ähnliches Taskboard im Terminal, das den Wechsel zum Browser überflüssig macht. Oder ein Deploy-Watcher mit Statuslicht, das den Zustand der Umgebung jederzeit anzeigt. Die Idee, Prosa und Regeln aus der Datei agents.md in deterministische Prüfungen zu überführen, ist praxisnah: weg von weichen Anweisungen, hin zu überprüfbaren Bedingungen.
Ein weiteres Beispiel ist ein sichereres Werkzeug zum Abfragen von Produktionsdaten. Statt SQL von Hand zusammenzubauen, kapselt ein Mod den Zugriff in eine geprüfte Schnittstelle. Ebenfalls praktisch: eine Queue mit Lock für parallele End-to-End-Tests. Bei Kund begrenzen heute die speicherintensiven Browser-Tests, wie viele Agenten parallel laufen können. Eine Queue würde erst dann eingreifen, wenn tatsächlich Konflikte drohen. So lässt sich die parallele Auslastung erhöhen, ohne dass Tests sich in die Quere kommen. Daneben verweist Kund auf Mods anderer Nutzer: einen Modellwechsler und, für den Humor, einen Mod, mit dem man in einem Terminal-Panel Doom spielen kann, während man auf das Modell wartet.
Was das konkret für den eigenen Arbeitsalltag bedeutet
Mods sind kein Selbstzweck und kein Gimmick für Power-User. Sie verändern, wie man mit KI-Werkzeugen arbeitet. Man muss nicht jede Erweiterung als Projekt behandeln. Man kann das Modell selbst um die Erweiterung bitten, sie kurz prüfen und produktiv schalten. Die Rolle der Entwicklerin verschiebt sich damit ein Stück von der Implementierung hin zur Formulierung des Bedarfs und zur Qualitätskontrolle.
Wer Claude Code, Codex, Gemini oder ein vergleichbares Terminal-Werkzeug nutzt, sollte sich ein paar Minuten nehmen, das Modell nach passenden Mods zu fragen und zwei oder drei davon im Alltag einzusetzen. Die Einstiegshürde ist niedrig. Ein Visualisierungs-Panel macht einen zweistündigen Workflow lesbar – wer das einmal gesehen hat, will es behalten.
Quelle: ivokund.com
