Conductor v8.1.0 — Wie aus 13 Plugins ein Orchester wird

TL;DR

Conductor v8.1.0 ist mein produktiver Agentic-Coding-Stack: 13 spezialisierte Claude-Code-Plugins, 55+ Commands, ein Orchestrator-Plugin als Taktstock. Damit baue ich 8 parallele Projekte über 424 Repositories. Nach 8 Major-Versionen in 2 Jahren ist das System kein Experiment mehr, sondern Backbone. Dieser Post erklärt die Architektur, was sich gegenüber der ersten Version geändert hat, und welche drei Plugins den größten Hebel haben — conductor, auto-test, finalizer. Der Stack ist privat (Repo moinsen-dev/claude_code_conductor), aber die Plugin-Pattern sind übertragbar.

Was ist Conductor?

Conductor ist ein Plugin-Ökosystem für Claude Code, die offizielle CLI von Anthropic für Code-Agenten. Anthropic dokumentiert Plugins als “scoped sets of commands, agents, hooks, and MCP servers” — also genau die fünf Erweiterungspunkte, die Claude Code seit der Plugin-System-Einführung im Oktober 2025 öffentlich macht. Conductor nutzt alle fünf.

Die Idee: Ein Plugin pro Phase im Software-Lifecycle. PRD-Phase hat eigene Commands, Design hat eigene, Tests haben eigene, Release hat eigene. Statt einen monolithischen Mega-Prompt zu pflegen, ist jeder Schritt ein eigenes Plugin mit eigenem Kontext und eigenen Sub-Agenten.

Nach 8 Major-Versionen — v1.0 lief im Mai 2024, v8.1.0 läuft Mai 2026 — habe ich gelernt: die Granularität ist die Architektur. Ein zu grobes Plugin verliert Kontext, ein zu feines Plugin kostet mehr Orchestrierungs-Overhead als es spart.

Die 13 Plugins, sortiert nach Hebel

Die Reihenfolge ist die Reihenfolge der Wertschöpfung pro Stunde: conductor und auto-test sparen am meisten Zeit, marketing-pilot zahlt sich erst bei Release ein.

Warum 13 statt 1?

Drei Gründe, alle aus Schmerz gelernt.

1. Kontext-Window ist ein Bottleneck

Claude Code mit Claude Opus 4.7 hat aktuell 1 Million Token Kontext (Anthropic, Claude Models Overview, Stand Februar 2026). Das klingt nach viel — bis du ein 100k-Zeilen-Flutter-Projekt aufmachst und alle relevanten Dateien drinhalten willst. Plugins erlauben scoped contexts: das auto-test-Plugin lädt nur Test-Files und die zu testenden Sources, nicht das ganze Repo. Das ist die einzige Art, in einem Projekt mit 800+ Dateien dauerhaft arbeiten zu können, ohne dass die Antworten langsamer und unschärfer werden.

Anthropic empfiehlt diesen Ansatz explizit: “Plugins offer a clean way to bundle and share extensions in formats you already use” (Mike Krieger, Chief Product Officer, Anthropic, Oktober 2025).

2. Sub-Agents > Mega-Prompt

Anthropics offizielle Doku (Engineering Blog, “Effective Context Engineering for AI Agents”, September 2025) sagt es klar: “Sub-agents inherit fresh contexts and tools”. Ein Plugin in Conductor ist genau das — ein Sub-Agent mit klar definiertem Zweck, eigenem Prompt, eigener Toolbox. Wenn auto-test einen Test schreibt, weiß es nicht, was conductor zwei Schritte vorher mit dem PRD gemacht hat. Das ist Feature, nicht Bug: weniger Cross-Talk, klarere Verantwortung.

3. Hooks zwingen zur Disziplin

Claude Code unterstützt seit dem Plugin-System Lifecycle-Hooks: PreToolUse, PostToolUse, Stop. Conductor nutzt finalizer-Hooks vor jedem Push auf main — wenn der Build rot ist oder Tests fehlen, blockt der Hook. Das ist die einzige Art, in einem 8-Projekte-parallel-Modus nicht ständig Production-Bugs zu produzieren.

Was sich von v1.0 zu v8.1.0 geändert hat

Die ehrliche Version: jede Major-Version hat ein altes Designprinzip kaputt gemacht.

Die zwei Lektionen aus diesen 8 Iterationen:

1. Granularität schlägt Cleverness. v5.0 war der Versuch, einen schlauen Mega-Plugin zu bauen, der alles entscheidet. v6.0 war das Geständnis, dass dumme separate Plugins besser sind.
2. Hooks schlagen Konventionen. v7.0 hat das, was bis dahin als “ich erinnere mich, vor Push die Tests laufen zu lassen” galt, in Code gegossen. Das ist der Punkt, ab dem ich nicht mehr in einer Production-Pipeline persönlich aufpassen musste.

Wie ich Conductor eigentlich benutze

Ein typischer Tag in einem aktiven Projekt:

1. Morgens 06:30: claude --plugin knowhow project-status — frischer Kontext, was hat sich seit gestern geändert.
2. 07:00: claude --plugin conductor next-task — Conductor pickt aus dem PRD die nächste Aufgabe, schaut auf Dependencies, schlägt vor.
3. 07:00–10:00: Implementation. auto-test läuft im Hintergrund mit --watch-Flag und schreibt Tests parallel.
4. 10:00: claude --plugin finalizer pre-push — checkt: Build grün? Lint clean? Tests grün? Wenn nein, blockt.
5. 10:01: Push, dann claude --plugin marketing-pilot release-notes falls Major.

Das ist die Choreografie für ein Projekt. Bei 8 parallelen läuft das gleiche Muster in 8 Repos. Conductor weiß über sein Knowhow-Plugin, in welchem Kontext gerade welcher Stand ist — sonst wäre Kontext-Switching der Killer.

Was es nicht kann (Limitations)

Damit dieser Post nicht als Werbung gelesen wird, hier die ehrlichen Grenzen.

• Conductor ist privat. Repo moinsen-dev/claude_code_conductor ist nicht öffentlich. Die hier beschriebenen Patterns sind übertragbar, der konkrete Code nicht (noch nicht).
• Conductor ist auf Claude Code zugeschnitten. OpenCode, Codex CLI, Cursor — alle haben eigene Plugin-Systeme. Conductor-Logik portieren bedeutet Re-Implementation, nicht Copy.
• Conductor löst kein Produkt-Problem. Es löst ein Bauprozess-Problem. Wenn der PRD-Input schlecht ist, bauen 13 Plugins schneller einen schlechten Sachverhalt.
• MCP-Performance ist ein offener Punkt. Anthropic’s Model Context Protocol (modelcontextprotocol.io) ist die Grundlage für Plugin-zu-Plugin-State, aber Latenz im 200-500ms-Bereich pro Call summiert sich bei Workflows mit 15+ Schritten.

Wann lohnt sich so etwas für jemand anderen?

Drei Bedingungen müssen alle drei zutreffen:

1. Du baust 5+ aktive Projekte parallel (sonst ist der Plugin-Overhead höher als der Spar-Effekt).
2. Du nutzt Claude Code als primären Agenten (sonst sind die Plugin-Slots im falschen System).
3. Du bist bereit, alle 3-4 Monate eine Major-Version zu refaktorieren (sonst zementiert sich eine Architektur, die deine veränderten Workflows nicht mehr abbildet).

Wenn das nicht alle drei sind: kleinere Stacks sind oft besser. Ein einzelnes gutes Custom-Command tut viel.

Wo es weitergeht

Conductor v9 ist schon in Planung. Drei Themen, die wir mit v8.1.0 explizit nicht gelöst haben:

• Cross-Repo-Refactoring: wenn die gleiche Änderung in 12 Repos gleichzeitig passieren muss, bricht der aktuelle Stack zusammen.
• Long-Running Background Jobs: Tests, die 30+ Minuten laufen, blocken aktuell zu früh.
• Multi-LLM-Orchestrierung: Claude Code als primär, aber Codex und Kimi sollen für spezifische Sub-Tasks aufgerufen werden. v8 macht das ad hoc, v9 soll es deklarativ machen.

Wenn du selbst mit Claude-Code-Plugins arbeitest oder einen ähnlichen Stack baust: schreib mir auf LinkedIn oder GitHub. Ich tausche Notes gerne.

FAQ

Was ist Conductor in einem Satz?

Ein Plugin-Ökosystem für Claude Code, das den kompletten Software-Lifecycle eines Indie-Builders — von PRD über Implementation und Test bis Release — in 13 spezialisierten Plugins abbildet.

Welche Claude-Code-Version brauche ich?

Plugins werden seit Claude Code 1.0.107 unterstützt (Anthropic, “Claude Code plugins”, Oktober 2025). Conductor v8.1.0 setzt mindestens diese Version voraus, läuft aktuell gegen Claude Opus 4.7 mit 1M Token Kontext.

Warum nicht alles in einem Plugin?

Weil Claude Code dann den ganzen Plugin-Kontext bei jedem Command lädt. Mit 13 Plugins lädt es nur den relevanten Sub-Kontext und reserviert das Token-Budget für die eigentliche Arbeit. Anthropic dokumentiert dies in der Plugin-Übersicht als bewusste Designentscheidung.

Wie lange hat v8.0 zu v8.1.0 gedauert?

2 Wochen reine Iteration. v8.0 → v8.1.0 war kein Architekturwechsel, sondern Stabilisierung und das Reife-Machen von marketing-pilot.

Wird Conductor je Open Source?

Wahrscheinlich nicht in der aktuellen Form — zu viel ist auf meinen spezifischen Indie-Builder-Workflow getuned. Aber einzelne Plugins, die sich verallgemeinern lassen (auto-test, finalizer), könnten 2026/2027 als separate Open-Source-Releases erscheinen. Konkrete Pläne dazu in Now.

Geschrieben am 17. Mai 2026 in Hamburg. Wenn du diesen Post hilfreich findest, verlinke ihn — das hilft, dass auch andere ihn finden.