Shopware-Plugins mit Dynamic Workflows entwickeln: von der Recherche bis zum grünen Test

Ein Shopware-Plugin zu entwickeln heißt, an vielen Baustellen gleichzeitig sauber zu arbeiten: Entities und Migrationen für die Datenbank, Subscriber für die richtigen Events, Admin-Modul, Storefront-Templates, Composer-Constraints für Shopware 6.7 - und am Ende Tests, die das alles absichern. Wer dafür KI-Assistenten nutzt, kennt das Muster: Der Chat startet stark, aber nach der dritten Datei vergisst er die Konvention aus der ersten. Das Problem ist selten das Modell. Es ist das Kontextfenster, in dem Recherche, Code, Fehlermeldungen und Zwischenstände um denselben Platz konkurrieren.

Genau dieses Problem adressieren Dynamic Workflows in Claude Code: Statt eine Aufgabe Zug um Zug in einem einzigen Gespräch abzuarbeiten, schreibt Claude ein Orchestrierungs-Skript, das viele spezialisierte Subagenten in parallelen Wellen koordiniert. Bis zu 16 Agenten arbeiten gleichzeitig, weitere warten in der Queue. Am Ende landet ein zusammengeführtes Ergebnis in der Session - ob und wie stark es verifiziert ist, hängt vom Aufbau des Workflows ab. Dieser Beitrag zeigt, wie sich damit die vier Phasen der Plugin-Entwicklung strukturieren lassen: Recherche, Setup, Verifizierung und Testing.

• Phase 1: Recherche - parallele Leser statt Doku-Marathon

• Phase 2: Setup - das Skeleton als gespeicherter Team-Workflow

• Phase 3: Verifizierung - Findings müssen einen Widerspruch überleben

• Phase 4: Testing - von PHPUnit bis zur Playwright-Acceptance-Suite

Was Dynamic Workflows sind - und warum sie anders arbeiten als ein Chat

Ein Dynamic Workflow ist ein JavaScript-Skript, das Subagenten orchestriert. Ihr beschreibt die Aufgabe, Claude schreibt das Skript, eine Runtime führt es im Hintergrund aus, während die Session frei bleibt. Der entscheidende Unterschied zum klassischen Chat-Agenten: Zwischenergebnisse landen in Skript-Variablen statt im Kontextfenster des Modells. Ein Agent, der 40 Doku-Seiten gelesen hat, verstopft damit nicht den Kontext des Agenten, der später den Code schreibt.

Die Eckdaten laut offizieller Dokumentation: verfügbar ab Claude Code v2.1.154 auf allen Bezahl-Plänen (auf dem Pro-Plan per /config zuschaltbar) sowie über die Anthropic API, Amazon Bedrock, Google Cloud Agent Platform und Microsoft Foundry. Ein einzelner Lauf darf bis zu 1.000 Agenten umfassen - gleichzeitig aktiv sind davon jeweils bis zu 16 (auf Maschinen mit wenigen CPU-Kernen weniger), alle weiteren warten in der Queue und starten, sobald ein Slot frei wird. Ein Lauf kann also 40 oder 100 Agenten umfassen, ist dann aber bereits groß und potenziell sehr tokenintensiv: Claude Code kennzeichnet Workflows ab mehr als 25 geplanten Agenten oder 1,5 Millionen projizierten Tokens als "Large workflow". Für den Einstieg ist deshalb ein kleiner, klar abgegrenzter Ausschnitt sinnvoll. Gestartet wird ein Workflow entweder explizit (das Schlüsselwort "ultracode" im Prompt oder schlicht die Bitte "nutze einen Workflow") oder pauschal über /effort ultracode, womit Claude für jede substanzielle Aufgabe selbst entscheidet, ob sich Orchestrierung lohnt.

Stand: 4. August 2026. Funktionen, Limits und Berechtigungsmodelle von Claude Code können sich mit neuen Versionen ändern.

So sieht ein gespeichertes Workflow-Skript im Kern aus - hier ein Audit aller Event-Subscriber eines Plugins:

export const meta = {
  name: 'audit-subscriber',
  description: 'Event-Subscriber auf 6.7-Kompatibilitaet pruefen',
}

const found = await agent(
  'Liste alle Subscriber-Klassen unter src/Subscriber auf.',
  { schema: { type: 'object', required: ['files'],
    properties: { files: { type: 'array', items: { type: 'string' } } } } }
)

const audits = await pipeline(found.files, file =>
  agent(`Pruefe ${file} gegen die Event-Signaturen in vendor/shopware/core.`,
    { label: file }),
)

return audits.filter(Boolean)

agent() spawnt einen Subagenten, pipeline() lässt einen pro Listeneintrag laufen - bei zwölf Subscribern also zwölf unabhängige Prüfungen parallel statt einer langen Sitzung, die ab Datei acht müde wird. Das Skript selbst ist lesbar, versionierbar und wiederholbar: Ein Lauf, der funktioniert, lässt sich als Command speichern und beim nächsten Plugin unverändert erneut ausführen.

Phase 1: Recherche - parallele Leser statt Doku-Marathon

Vor der ersten Codezeile stehen bei Shopware immer dieselben Fragen: Welcher Extension Point ist der richtige - Event-Subscriber, Decorator oder Flow-Action? Was hat sich zwischen 6.6 und 6.7 an den Signaturen geändert? Wie lösen vergleichbare Open-Source-Plugins das Problem? Klassisch bedeutet das einen Nachmittag zwischen developer.shopware.com, dem Core-Code im vendor-Verzeichnis und GitHub-Repos.

Als Workflow wird daraus ein Fan-out mit eingebauter Gegenprüfung: Mehrere Lese-Agenten arbeiten parallel - einer die offiziellen Guides, einer den Core-Code, einer die Changelogs und UPGRADE-Dateien, einer zwei Referenz-Plugins. Eine zweite Stufe prüft jede Behauptung aus der Doku gegen den tatsächlichen Core-Code, denn genau da liegen die teuren Fehler: Trainingswissen von KI-Modellen kann veralten, und besonders bei Major-Sprüngen wie Shopware 6.6 auf 6.7 sowie bei als @internal oder @experimental markierten APIs können sich Signaturen und Extension Points ändern. Innerhalb einer Major-Serie sollen Minor- und Patch-Releases dagegen rückwärtskompatibel bleiben. Ein konkreter Prompt dafür:

Nutze einen Workflow: Recherchiere, wie ein Shopware-6.7-Plugin eigene
Zahlungsarten registriert. Lies parallel (1) die offizielle Doku,
(2) den Core-Code unter vendor/shopware/core und (3) zwei Open-Source-
Plugins mit Payment-Integration. Verifiziere jede Aussage aus der Doku
gegen den Core-Code und markiere Widersprueche explizit.

Das Ergebnis ist ein Dossier mit belegten Aussagen statt 40 offener Browser-Tabs. Behauptungen, die die Gegenprüfung nicht überstehen, werden herausgefiltert oder als unverifiziert markiert - dasselbe Muster, das der mitgelieferte /deep-research-Befehl für Web-Recherchen nutzt. Für den Einstieg ist diese Phase ideal: Ein über Berechtigungen und Sandbox auf Lesezugriffe begrenzter Recherche-Workflow reduziert das Risiko unbeabsichtigter Codeänderungen. Risikofrei ist er dennoch nicht, weil Repository-Inhalte verarbeitet werden und Prompt Injection sowie freigegebene Web-, Shell- oder MCP-Zugriffe weiterhin Teil des Sicherheitsmodells bleiben.

Phase 2: Setup - das Skeleton als gespeicherter Team-Workflow

Das Grundgerüst eines Plugins ist bekanntes Terrain: bin/console plugin:create erzeugt die Struktur mit composer.json (Typ shopware-platform-plugin plus shopware/core-Requirement), src/-Verzeichnis, phpunit.xml und tests/TestBootstrap.php. Der eigentliche Aufwand steckt in dem, was danach kommt und in jeder Agentur anders aussieht: Namespace-Konventionen, PHPStan- und Code-Style-Konfiguration, CI-Pipeline, Composer-Constraints für die Zielversion.

Hier zahlt sich aus, dass Workflows speicherbar sind: Ein einmal geschriebener Setup-Workflow landet als Datei in .claude/workflows/ im Repository und steht damit jedem im Team zur Verfügung, der das Repo klont. Über den args-Parameter nimmt er Eingaben entgegen - aus "/plugin-setup MeinFeaturePlugin" wird dann ein Skeleton nach euren Hausregeln, wie wir sie auch in der Plugin-Entwicklung für Kundenprojekte ansetzen. Ein solcher Workflow erledigt typischerweise:

• Skeleton generieren und die shopware/core-Constraint auf die Zielversion setzen

• Test-Bootstrap und phpunit.xml einrichten - der Source-Namespace wird per PSR-4 in der composer.json registriert, der Test-Namespace im TestBootstrap über den Class Loader

• Statische Analyse und Code-Style (PHPStan, PHP-CS-Fixer mit dem Shopware Coding Standard) mit der Team-Konfiguration verdrahten

• Einmal komplett bauen und validieren: shopware-cli extension build und extension validate als Abnahmekriterium

Der Unterschied zu einem statisch vorprogrammierten Shell-Skript: Die Agenten können auch unerwartete Fehler diagnostizieren und innerhalb definierter Regeln einen neuen Lösungsweg wählen - etwa eine fehlende Abhängigkeit nachziehen und den Build erneut anstoßen, statt mit Exit-Code 1 stehenzubleiben. Genau diese Flexibilität macht klare Grenzen, Abbruchbedingungen und eine abschließende Diff-Prüfung notwendig.

Phase 3: Verifizierung - Findings müssen einen Widerspruch überleben

Der größte Schwachpunkt von KI-generiertem Code ist nicht der offensichtliche Fehler, sondern der plausible: Code, der kompiliert, gut aussieht und in einem Randfall falsch rechnet. Workflows machen adversariale Verifizierung dagegen systematisch, wiederholbar und über viele Dateien hinweg skalierbar: Für jedes Finding und jede Implementierung startet das Skript separate Prüf-Agenten, deren expliziter Auftrag es ist, das Ergebnis zu widerlegen. Nur was mehrere skeptische Prüfer übersteht, landet im Report. Die Prüf-Agenten laufen als separate Modellaufrufe ohne gemeinsame Gesprächshistorie - für eine möglichst unabhängige Gegenprüfung sollte der Workflow ihnen nur das Finding, den relevanten Code und die Beleglage übergeben, nicht die Rechtfertigung des ursprünglichen Autors.

Die zweite Säule ist deterministisch: die Prüfwerkzeuge, die es im Shopware-Ökosystem ohnehin gibt, in einer Schleife bis zum grünen Ergebnis. Die offizielle Extension-Validierung der shopware-cli prüft unter anderem Composer-Anforderungen, Metadaten, PHP-Linting sowie Theme- und Snippet-Konsistenz - mit --full zusätzlich Analysewerkzeuge wie PHPStan, ESLint und Stylelint. Für eine belastbare Kompatibilitätsaussage sollte die Extension außerdem gegen die niedrigste und die höchste unterstützte Shopware-Version geprüft werden. Das ist ein starkes Quality Gate, ersetzt aber keine vollständige manuelle Prüfung sämtlicher Store-Richtlinien. PHP-CS-Fixer mit dem Shopware Coding Standard sichert den Code-Style. Ein Verifizierungs-Workflow für ein Plugin führt typischerweise aus:

# Offizielle Extension-Validierung (Composer-Anforderungen, Metadaten,
# PHP-Linting, Theme-/Snippet-Konsistenz; --full inkl. PHPStan, ESLint, Stylelint)
shopware-cli extension validate --full --reporter summary .

# Statische Analyse und Code-Style
vendor/bin/phpstan analyse
vendor/bin/php-cs-fixer fix --dry-run --diff

Das Schleifenmuster dazu: prüfen, gemeldete Fehler beheben, erneut prüfen - bis alles grün ist oder zwei Runden in Folge keinen Fortschritt bringen. Das Abbruchkriterium ist wichtig: Es verhindert, dass sich der Lauf an einem Fehler festbeißt, der eine Architektur-Entscheidung braucht statt eines Patches. Solche Fälle gehören auf den Tisch des Entwicklers, und ein gut geschriebener Workflow eskaliert sie dorthin, statt sie wegzubügeln. Eine Schutzregel gehört zusätzlich explizit ins Skript: Der Workflow darf zum Erreichen eines grünen Ergebnisses weder Tests abschwächen noch Fehler unterdrücken oder erwartetes Verhalten ohne Freigabe verändern - sonst wird nicht der Fehler behoben, sondern nur das Prüfwerkzeug zufriedengestellt.

Phase 4: Testing - von PHPUnit bis zur Playwright-Acceptance-Suite

Shopware bringt für jede Testebene offizielle Werkzeuge mit: PHPUnit für Unit- und Integrationstests - letztere gegen eine eigene Test-Datenbank, die der TestBootstrapper aus der DATABASE_URL ableitet und automatisch mit dem Suffix _test versieht - und die Acceptance Test Suite auf Playwright-Basis mit fertigen Fixtures für Storefront, Administration und API-Clients. Die Frage ist selten, womit man testet - sondern wer die Tests schreibt, wenn das Feature-Deadline-Fenster eng wird. In der Praxis ist Testabdeckung der erste Posten, der gestrichen wird.

Workflows drehen die Ökonomie dieser Entscheidung um, weil Testerstellung parallelisierbar ist wie kaum eine andere Aufgabe:

Besonders das letzte Muster ist im Chat-Format unpraktikabel: Ein Workflow lässt die Suite in Runden wiederholt laufen, protokolliert, welche Tests intermittierend fehlschlagen, und stoppt erst, wenn zwei Runden in Folge nichts Neues finden. Flaky Tests im Checkout sind bei E-Commerce-Projekten notorisch - und genau die Sorte Fleißarbeit, für die im Alltag nie Zeit ist.

Kosten und Kontrolle: was ihr vor dem ersten Lauf wissen solltet

Ein Workflow spawnt viele Agenten und verbraucht entsprechend mehr Tokens als dieselbe Aufgabe im Gespräch. Claude Code macht das transparent: Die /workflows-Ansicht zeigt Tokenverbrauch je Agent live, und ein Lauf, der mehr als 25 Agenten einplant oder dessen Projektion 1,5 Millionen Tokens übersteigt, wird als "Large workflow" markiert. Über die Größenrichtlinie in /config lässt sich beeinflussen, wie viele Agenten Claude beim Erstellen eines Workflows anstrebt: small zielt auf weniger als 5, medium auf weniger als 15 und large auf weniger als 50 Agenten. Es handelt sich um Richtwerte, nicht um feste Limits. Seit Claude Code v2.1.219 ist medium der Standard; ältere Versionen verwenden standardmäßig unrestricted.

Drei Regeln haben sich für den Einstieg bewährt:

1. Klein anfangen: erst ein Verzeichnis auditieren statt des ganzen Plugins, erst dann skalieren. So wird der Tokenverbrauch kalkulierbar, bevor er anfällt.

2. Berechtigungen und Schreibzugriff vorher klären: Workflow-Subagenten laufen im Modus acceptEdits - Dateiänderungen werden automatisch genehmigt, nicht freigegebene Shell-, Web- und MCP-Aufrufe (etwa composer, phpstan oder shopware-cli) können den Lauf dagegen an einem Berechtigungs-Prompt pausieren. Deshalb auf einem sauberen Branch oder Worktree starten, die Allowlist eng halten und vor dem Merge immer den vollständigen Diff prüfen.

3. Repo-Hygiene ernst nehmen: Agenten lesen, was im Repository liegt. Test-Fixtures mit echten Kundendaten oder Credentials in Konfigurationsdateien sind ein Datenschutzproblem, bevor der erste Agent startet - nicht erst danach.

Noch ein praktischer Hinweis für längere oder nächtliche Läufe: Die Claude-Code-Session muss geöffnet bleiben - nach dem Beenden wird der Workflow in einer neuen Session nicht an derselben Stelle fortgesetzt.

Für datenschutzsensible Umgebungen relevant: Dynamic Workflows können über die Anthropic API sowie über Amazon Bedrock, Google Cloud Agent Platform und Microsoft Foundry genutzt werden - je nach Plattform mit unterschiedlichen regionalen und vertraglichen Optionen. Eine EU-Region oder ein bestehender AVV macht den konkreten Einsatz jedoch nicht automatisch DSGVO-konform. Zu prüfen sind insbesondere das Hosting- und Deployment-Modell, der tatsächliche Verarbeitungsort, beteiligte Auftragsverarbeiter und Unterauftragsverarbeiter, Aufbewahrungsregeln, Toolzugriffe sowie die im Repository enthaltenen Daten. Ausführlich haben wir das im Beitrag Claude DSGVO-konform nutzen aufgeschlüsselt.

Fazit: Die vier Phasen bleiben - aber jede bekommt ein wiederholbares Muster

Dynamic Workflows ändern nichts daran, was gute Plugin-Entwicklung ausmacht: verstandene Extension Points, saubere Struktur, geprüfter Code, echte Testabdeckung. Sie ändern, wie viel davon pro Arbeitstag machbar ist. Die Recherche wird zum verifizierten Dossier statt zum Tab-Chaos, das Setup zum Team-Command im Repository, die Verifizierung zur Schleife mit Abbruchkriterium, das Testing zur parallelen Fließbandarbeit mit Flaky-Erkennung.

Die Rolle des Entwicklers verschiebt sich dabei vom Schreiber zum Orchestrator und Reviewer - und das ist anspruchsvoller, nicht einfacher. Wer beurteilen kann, ob ein Finding echt ist und ob eine Architektur trägt, multipliziert seine Wirkung. Der pragmatische Einstieg: mit einem auf Lesezugriffe begrenzten Recherche-Workflow beginnen, dann die Validierungs-Schleife auf ein bestehendes Plugin ansetzen, und erst danach Workflows Code schreiben lassen. Jeder Lauf, der sich bewährt, wandert als gespeicherter Command ins Repository - so entsteht Stück für Stück eine Werkbank, die dem ganzen Team gehört.