Einen mehrstufigen Workflow bauen

Eine einzelne Issue Session ist ein taktischer Schritt. Ein Workflow ist Strategie. In diesem Guide komponieren Sie fünf Phasen - Triage, Planung, Ausführung, Review und Auslieferung - zu einer Pipeline, die unbeaufsichtigt vom Ticket-Titel bis zum gemergten Pull Request läuft. Die Gesamterstellung dauert etwa 45 Minuten und spart Ihnen anschließend wöchentlich Stunden.

1. Die richtige Form für Ihren Workflow wählen

Skizzieren Sie die Pipeline auf Papier, bevor Sie den Workflow Builder öffnen. Echte Workflows folgen fast immer demselben Skelett: breiter Intake-Trichter, Planungs-Bottleneck mit menschlicher Intervention, Fan-out-Ausführung, Review-Gate und Auslieferungsschritt. Genau das bauen wir.

Sinn des Skeletts ist nicht Originalität, sondern Wiederholbarkeit. Jeder vernünftige Engineering-Prozess durchläuft diese fünf Phasen. Einmal in CodeCourier kodifiziert, erfinden Sie den Prozess nicht bei jedem Ticket neu.

2. Die vier Personas anlegen

Öffnen Sie den Personas-Tab und erstellen Sie vier Einträge. Jede wird vom Workflow referenziert. Halten Sie sie klein und scharf - nicht eine Persona, die alles können soll.

• Triage - schnelles Modell, niedriges Thinking-Budget. Liest ein Ticket, entscheidet über Scope, vergibt Priorität und ordnet das passende Repo zu.
• Planner - starkes Modell, hohes Thinking-Budget. Liest das Repo gegen das Ticket und entwirft einen nummerierten Plan mit Verweisen auf konkrete Dateien und Zeilen.
• Coder - ausgewogenes Modell, volles Toolset. Setzt den Plan um. Hat Zugriff auf Ihren Test-Runner und Linter.
• Reviewer - starkes Modell, keine Write-Tools. Liest das Diff gegen Ihre Standards und produziert ein strukturiertes Review.

3. Workflow Builder öffnen

Klicken Sie im Dashboard auf Workflows → New workflow. Benennen Sie ihn langweilig und stabil - standard-ticket-flow statt experimental-thing-v3. Zukünftiges Ich dankt dem heutigen Ich für die Disziplin.

workflow: standard-ticket-flow
trigger:  manual | issue:created | issue:labeled
inputs:   ticket_title, ticket_body, repo

4. Die fünf Schritte verkabeln

Ziehen Sie fünf Blöcke nacheinander auf das Canvas. Der Workflow Builder macht die Verbindungen explizit - Output eines Schritts ist Input des nächsten, mit optionalem Fan-out, wo es passt.

• Schritt 1: Triage - Triage-Persona liest das Ticket und liefert {priority, scope, repo}. Überspringt alles Nachgelagerte, falls Scope out-of-scope ist.
• Schritt 2: Plan - Planner-Persona liest das Repo und liefert einen nummerierten Plan. Fügen Sie hier einen Human-Approval-Knoten ein. Dies ist der einzige Punkt im Workflow, an dem ein Mensch auf dem kritischen Pfad steht.
• Schritt 3: Execute - Coder-Persona läuft gegen den genehmigten Plan in einer E2B-Sandbox.
• Schritt 4: Review - Reviewer-Persona bewertet das Diff. Liegt der Score unter Ihrer Schwelle, zurück zu Schritt 3 mit angehängten Review-Notizen.
• Schritt 5: Ship - Pull Request öffnen und Channel benachrichtigen. Keine Persona nötig - deterministischer Action-Knoten.

5. Mit einem bekannten Ticket testen

Bevor Sie den Workflow auf das echte Backlog loslassen, lassen Sie ihn durch ein Ticket laufen, das Sie bereits manuell gelöst haben. Vergleichen Sie Plan und Diff des Agenten mit Ihrer eigenen Arbeit. Achten Sie auf zwei Failure Modes: Der Agent überspringt einen für Sie wesentlichen Schritt, oder er fügt einen Schritt hinzu, den Sie abgelehnt hätten. Beides sind Tuning-Signale.

Ein Workflow ist nicht fertig, wenn er Output produziert. Er ist fertig, wenn er den Output produziert, den Sie produziert hätten.

6. Den Loop straffen

Iterieren Sie zuerst an der Planner-Persona - die meisten Workflow-Fehler gehen auf einen schlechten Plan zurück, nicht auf einen schlechten Coder. Senken Sie das Thinking-Budget der Triage, falls sie über simple Tickets nachdenkt. Heben Sie die Reviewer-Schwelle schrittweise an, sobald Sie Vertrauen aufbauen.

7. Nächste Schritte

Wenn der Workflow stabil läuft, sind die offensichtlichen Upgrades: Ausführung über mehrere Tickets per Sprint Chain parallelisieren, GitHub-Issue-Auto-Ingestion in den Trigger einklinken und Webhooks in Ihren Slack-Channel verkabeln, damit das Team Workflow-Events ohne Tab-Wechsel sieht.

Der Guide Design a frontend persona ist die natürliche Folgelektüre, wenn Sie die Coder-Persona für einen spezifischen Stack spezialisieren möchten.