KI-Agent-Workflow-Vorlagen für Claude Code, Codex und ChatGPT

Eine zentrale Orchestrierung verbindet Research-, Planungs-, Umsetzungs- und Review-Agenten mit einem Human Gate. — Spezialisierte Agenten arbeiten koordiniert — mit einem menschlichen Freigabepunkt vor kritischen Schritten.

Claude Code, Codex, Cursor und ChatGPT schreiben Code in Sekunden. Was bleibt, ist die Arbeit drumherum — und die ist bei jeder Aufgabe fast gleich. Diese Seite zeigt fünf konkrete Workflow-Vorlagen zum Kopieren und Anpassen, plus eine generische Handoff-Vorlage für den Alltag.

Das wiederkehrende Problem

Ein schnelles Modell macht die immer gleiche Vorarbeit nicht überflüssig. Bei praktisch jeder Aufgabe stellen sich dieselben Fragen, unabhängig davon, welcher Agent am Ende den Code schreibt:

Task-Kontext: Was ist die eigentliche Aufgabe, in einem Satz?
Grenzen: Welcher Dateibereich ist erlaubt, welcher nicht?
Geschützte Dateien: Was darf unter keinen Umständen berührt werden?
Report-Pflicht: Welche Angaben muss der Abschlussbericht enthalten?
QA-Beleg: Welcher Nachweis zählt, und welcher nicht?
Merge-Entscheidung: Wer trifft sie, und anhand wovon?

Ohne feste Vorlage wird jede dieser sechs Fragen bei jeder Aufgabe neu erfunden — meist unter Zeitdruck und unterschiedlich vollständig. Die folgenden fünf Vorlagen decken die häufigsten Situationen ab.

Vorlage 1: Sichere UI-Text-Änderung

Der einfachste und häufigste Fall: ein sichtbarer Text ändert sich, ohne dass Logik betroffen ist.

Vorlage 1 — Sichere UI-Text-Änderung

Wann nutzen: Label, Überschrift oder Fehlertext ändert sich sichtbar, keine Logik betroffen

Handoff-Aufbau: Ziel, betroffene Datei(en), Text vorher → nachher

Nicht anfassen: Zahlungs-/Checkout-Code, .env, Tracking-Konfiguration, Build-Setup

Report-Pflicht: Geänderte Dateien, Vorher/Nachher-Text, Build- oder Screenshot-Beleg

Bridge-Review-Erwartung: merge-ready, wenn nur Text/Markup betroffen ist und Schutzbereiche unberührt blieben

Vorlage 2: Checkout-Copy ändern, ohne Zahlungslogik zu berühren

Sichtbare Texte auf einer Checkout- oder Bezahlseite lassen sich ändern, ohne die Zahlungslogik selbst anzufassen — solange der Auftrag beides sauber trennt.

Erlaubter Bereich

Sichtbare Texte, Labels und Hinweise auf der Checkout-Seite
Layout- und Stil-Anpassungen ohne Änderung an Formularfeldern oder Requests

Nicht anfassen

Stripe- oder Zahlungsanbieter-Konfiguration
.env-Dateien und Secrets
Payment-API-Routen
Webhook-Logik

Tabelle horizontal scrollen, um alle Spalten zu sehen.

Dimension	Sauberer Diff	Diff mit geschützten Dateien
Geänderte Dateien	Nur Copy-/Template-Dateien der Checkout-Seite	Stripe-Konfiguration, .env, Payment-API-Route oder Webhook-Handler
Zahlungslogik	Unverändert	Verändert oder auch nur berührt
Bridge-Empfehlung	merge-ready	do-not-merge
Nächster Schritt	Normaler Review, dann Merge	Sofort stoppen, Rücksprache vor jedem weiteren Schritt

Vorlage 3: Kleines Komponenten-Refactoring

Vorlage 3 — Kleines Komponenten-Refactoring

Erlaubter Scope: Eine einzelne Komponente, keine neuen Abhängigkeiten, öffentliche Props/Events unverändert

Tests/Checks: Bestehende Komponententests bleiben grün, Typecheck sauber, visueller Vergleich vorher/nachher

Risiken: Versteckte Kopplung an andere Komponenten, geteilte Styles, unbeabsichtigte Verhaltensänderung

Report-Pflicht: Diff-Umfang, welche Tests liefen, Bestätigung dass sich das äußere Verhalten nicht geändert hat

Vorlage 4: Agenten-Report prüfen

Ein guter Abschlussbericht ist kurz, aber vollständig. Für diese Vorlage reichen sechs Bausteine — eine ausführlichere Struktur mit Beispiel steht in der KI-Agent Report Vorlage.

Zusammenfassung: Was wurde gemacht, in ein bis zwei Sätzen.
Geänderte Dateien: Vollständige Liste, nicht nur die „wichtigsten".
Ausgeführte Checks: Welche Tests/Builds liefen, mit welchem Ergebnis.
Belege: Testausgabe, Build-Log oder Screenshot statt bloßer Behauptung.
Risiken: Was unsicher blieb oder bewusst nicht geprüft wurde.
Offene Fragen: Was der Mensch vor dem Merge noch entscheiden muss.

Fehlt einer dieser sechs Punkte, ist der Report unvollständig — unabhängig davon, wie zuversichtlich die Zusammenfassung klingt.

Vorlage 5: Do-not-merge-Beispiel

Manche Reports sollten unabhängig vom Inhalt der eigentlichen Änderung blockiert werden. Typische Warnsignale:

Eine als „nicht anfassen" markierte Datei wurde trotzdem geändert.
Der Auftrag hatte keinen klar benannten Scope.
Der Report ist vage („sollte passen", „fertig") statt konkret.
Es gibt keinen Testbeleg, nur eine Behauptung.
Riskante Geschäftslogik wurde berührt, ohne dass der Auftrag das verlangte.

Ein fiktives Beispiel, das aus mehreren Gründen do-not-merge auslöst:

Auftrag: „Kleines Update am Checkout"

Geänderte Dateien:
- src/lib/stripe/webhook-handler.ts
- .env.production (lokal überschrieben)
- src/components/CheckoutButton.tsx

Ausgeführte Tests:
„sollte passen"

Empfehlung: fertig

Drei Probleme gleichzeitig: eine geschützte Webhook-Datei wurde geändert, eine lokal überschriebene .env-Datei taucht im Diff auf, und der Test-„Beleg" ist eine Vermutung statt eines Ergebnisses. Jedes davon allein wäre schon ein Grund für do-not-merge.

Copy-Paste-Vorlage für den Alltag

Für Aufgaben, die in kein festes Muster passen, reicht diese generische Vorlage. Ausfüllen, in den Chat oder das Terminal einfügen, als Auftrag verwenden.

HANDOFF-VORLAGE

Ziel:
[Eine konkrete Aufgabe in einem Satz]

Erlaubter Bereich:
- [Datei/Ordner 1]
- [Datei/Ordner 2]

Nicht anfassen:
- [Geschützte Datei oder geschützter Bereich 1]
- [Geschützte Datei oder geschützter Bereich 2]

Erwartete Änderungen:
[Was sich sichtbar ändern soll]

Checks:
[Welche Tests/Builds vor der Abgabe laufen müssen]

Report am Ende:
[Zusammenfassung, geänderte Dateien, Checks, Belege, Risiken, offene Fragen]

Entscheidungskriterien:
merge-ready, wenn: [Bedingung]
Review nötig, wenn: [Bedingung]
do-not-merge, wenn: [Bedingung]

Wo AI Bridge dabei hilft

Die Vorlagen auf dieser Seite funktionieren unabhängig von einem Tool — als reiner Text. AI Bridge hilft zusätzlich dabei, Handoffs nach genau diesem Muster vorzubereiten, zurückkommende Agenten-Reports zu prüfen und eine Empfehlung zwischen merge-ready, Review nötig und do-not-merge einzuordnen. Die Entscheidung und der Merge bleiben bei dir.

Häufige Fragen

Funktioniert das nur mit Claude Code?

Nein. Die Vorlagen sind werkzeugneutral: Ziel, erlaubter Bereich, Nicht-anfassen-Liste, Checks und Report funktionieren unabhängig davon, welcher Agent den Code schreibt.

Kann ich die Vorlagen auch mit Codex nutzen?

Ja. Codex, Claude Code, ChatGPT und ähnliche Werkzeuge bekommen dieselbe Struktur als Auftrag — nur die Ausführung unterscheidet sich, nicht das Format der Übergabe.

Bedeutet merge-ready automatisches Mergen?

Nein. merge-ready ist eine Einschätzung, keine Aktion. Der Merge selbst bleibt eine bewusste Entscheidung eines Menschen, auch wenn ein Report oder ein Tool merge-ready empfiehlt.

Was passiert bei geschützten Dateien?

Sobald ein Diff eine als „nicht anfassen" markierte Datei berührt — etwa Zahlungslogik, .env oder einen Webhook-Handler — lautet die Einordnung do-not-merge, unabhängig davon, wie klein der Rest der Änderung wirkt.

Brauche ich MCP dafür?

Nein. Die Vorlagen funktionieren als reiner Text: kopieren, ausfüllen, dem Agenten als Auftrag geben. AI Bridge nutzt MCP zusätzlich, um Handoffs und Reports lokal vorzubereiten und zu prüfen — das ist aber keine Voraussetzung, um die Vorlagen selbst zu nutzen.

Kann ich manuell starten?

Ja. Jede Vorlage lässt sich manuell ausfüllen und in einen Chat oder ein Terminal einfügen, ganz ohne zusätzliches Werkzeug. Ein lokales Tool wie AI Bridge macht nur die Vorbereitung und Prüfung schneller.