Workflow-Schritte

Workflow-Schritte sind die einzelnen Arbeitseinheiten innerhalb einer CodeCourier- Pipeline. Jeder Schritt repräsentiert eine spezifische Rolle, die ein KI-Agent während der Workflow-Ausführung einnimmt. CodeCourier definiert zehn Schritttypen, jeder für einen klar abgegrenzten Zweck im Softwareentwicklungszyklus konzipiert. Schritte werden über Personas konfiguriert und im Workflow-Builder zu Pipelines zusammengestellt.

Referenz der Schritttypen

Die Tabelle unten fasst alle verfügbaren Schritttypen und deren primäre Eigenschaften zusammen.

type StepRole =
  | "designer"      // Primary implementation agent
  | "checker"       // Review and verdict agent
  | "optimizer"     // Code polish agent
  | "prompter"      // Prompt refinement agent
  | "investigator"  // Codebase research agent
  | "deep-dive"     // Deep analysis agent
  | "evaluator"     // Quality scoring agent
  | "judge"         // Multi-branch comparison agent
  | "answerer";     // Question-answering agent

Schritttypen

Designer

Der Designer ist der primäre Coding-Agent. Er empfängt den Aufgaben-Prompt (oder den verfeinerten Prompt eines vorherigen Schritts) und implementiert die Lösung. Designer-Schritte erzeugen Code-Änderungen, erstellen Dateien, installieren Pakete und führen alle Entwicklungsarbeiten aus, die zur Erfüllung der Anforderungen nötig sind.

• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - empfängt den Prompt und Kontext vorheriger Schritte
• Erzeugt Output: Ja - Code-Änderungen und Implementierungsergebnisse
• Kann iterieren: Ja - häufig mit einem Checker in einer Iterations-Schleife gepaart

Der Designer ist das Arbeitstier der meisten Workflows. In einem einfachen Workflow kann ein einzelner Designer-Schritt ausreichen. In komplexeren Pipelines arbeitet der Designer innerhalb einer Schleife, in der ein Checker dessen Ausgabe prüft und bei Bedarf zur Überarbeitung zurückschickt.

Designer-Schritte beinhalten eingebautes Selbstvalidierungs-Verhalten. Der System- Prompt weist den Designer an, TypeScript-Compilation (npx tsc --noEmit), Linting (npx next lint) und Convex-Schema-Validierung vor dem Committen auszuführen. Das fängt häufige Fehler ab, bevor der Checker die Arbeit überhaupt prüft.

Checker

Der Checker ist ein Review-Agent, der die Ausgabe des vorherigen Schritts bewertet. Er erzeugt ein Urteil - eine strukturierte Antwort mit einem booleschen pass und einem feedback-String. Stimmt der Checker zu, fährt die Pipeline mit dem nächsten Schritt fort. Lehnt er ab, startet die Schleife mit dem Feedback des Checkers neu, das in den nächsten Designer-Prompt eingebaut wird.

• Standard-Tool: Claude Code
• Standard-Modell: claude-sonnet-4-6
• Akzeptiert Input: Ja - prüft die Ausgabe des Designers
• Erzeugt Output: Ja - Urteil (Pass/Fail) und Feedback
• Kann iterieren: Ja - immer mit einem Designer in einer Schleife gepaart

Der System-Prompt des Checkers betont End-to-End-Testing. Standardmäßig sind Checker angewiesen:

1. Backend-Änderungen (Convex, Datenbank usw.) zu erkennen und zu deployen.
2. Abhängigkeiten zu installieren und den Dev-Server zu starten.
3. End-to-End-Tests mit einem Headless-Browser auszuführen.
4. Jede Anforderung aus dem ursprünglichen Prompt zu verifizieren.
5. Ein strukturiertes Urteil auf Basis echter Testergebnisse zu produzieren.

Optimizer

Der Optimizer läuft, nachdem eine Designer-Checker-Schleife zugestimmt hat. Seine Aufgabe ist es, den Code zu bereinigen und zu polieren, ohne die Funktionalität zu ändern. Optimizer- Schritte übernehmen typischerweise:

• Entfernen von totem Code und ungenutzten Imports.
• Verbesserung der Variablen- und Funktionsbenennung.
• Hinzufügen oder Verbessern von Dokumentation und Kommentaren.
• Refactoring für Lesbarkeit und Wartbarkeit.
• Sicherstellung eines konsistenten Code-Stils.

• Standard-Tool: Claude Code
• Standard-Modell: claude-sonnet-4-6
• Akzeptiert Input: Ja - arbeitet am freigegebenen Code
• Erzeugt Output: Ja - bereinigte Code-Änderungen
• Kann iterieren: Typischerweise nein - läuft einmal nach Freigabe

Prompter

Der Prompter ist ein Agent, der eine vage Aufgabenbeschreibung in einen detaillierten, umsetzbaren Prompt verfeinert oder erweitert. Er analysiert die Codebasis, versteht die Projektstruktur und erzeugt eine gründliche Spezifikation, die nachfolgende Designer-Schritte effektiv implementieren können.

• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - empfängt den ursprünglichen Prompt
• Erzeugt Output: Ja - verfeinerter/erweiterter Prompt
• Kann iterieren: Typischerweise nein - läuft einmal am Anfang

Der Prompter ist besonders nützlich, wenn Ihre Aufgabenbeschreibungen hochgradig abstrakt sind. Statt "Authentifizierung hinzufügen" könnte der Prompter eine mehrabsätzige Spezifikation produzieren, die abdeckt, welcher Auth-Provider zu verwenden ist, welche Seiten geschützt werden müssen, wo Login-Buttons hinzukommen und wie Session-Zustände zu handhaben sind.

Investigator

Der Investigator ist ein Recherche-Agent, der die Codebasis erkundet, um ein Problem zu verstehen, bevor andere Agenten daran arbeiten. Investigator-Schritte sind nützlich für Debugging-Workflows - der Investigator liest Code, führt Tests aus und erzeugt einen Bericht, den nachfolgende Schritte als Kontext nutzen.

• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - empfängt die Problembeschreibung
• Erzeugt Output: Ja - Untersuchungsbericht und Erkenntnisse
• Kann iterieren: Typischerweise nein - läuft einmal vor Designer-Schritten

Deep-Dive

Der Deep-Dive-Schritt ist ein intensiver Analyse-Agent, der eine gründliche Recherche bei komplexen Problemen durchführt. Ähnlich dem Investigator, jedoch für schwierigere Probleme konzipiert, die das Lesen vieler Dateien, das Nachvollziehen von Ausführungspfaden und ein tiefes Verständnis der System-Architektur erfordern.

• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - empfängt das Issue oder die Frage
• Erzeugt Output: Ja - detaillierter Analysebericht
• Kann iterieren: Nein - läuft einmal

Evaluator

Der Evaluator-Schritt bewertet die aktuelle Pipeline-Ausgabe gegen mehrere Qualitätsdimensionen. Er erzeugt ein qualityScores-Objekt, das quantifiziert, wie gut die Implementierung definierte Qualitätskriterien erfüllt. Der Evaluator wird separat über die Evaluator-Setup-Seite konfiguriert, wo Sie den Kontext, die Skills und Setup-Befehle oder -Skripte definieren, die er vor der Bewertung ausführt.

• Bezeichner des Schritttyps: evaluator
• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - bewertet den aktuellen Zustand der Codebasis
• Erzeugt Output: Ja - qualityScores-Objekt
• Kann iterieren: Typischerweise nein - läuft einmal, nachdem das Design freigegeben wurde

Der Evaluator generiert Qualitäts-Scores über fünf Dimensionen:

qualityScores: {
  correctness: number,       // 0-100: Does implementation meet requirements?
  typeSafety: number,        // 0-100: Are TypeScript types correct and complete?
  codeStyle: number,         // 0-100: Does code follow project conventions?
  testCoverage: number,      // 0-100: Are changes covered by tests?
  completeness: number,      // 0-100: Is the implementation fully finished?
  composite: number,         // 0-100: Weighted average of all dimensions
  thresholdResult: boolean,  // True if composite meets the configured threshold
}

Der boolesche thresholdResult zeigt an, ob der Composite- Score den auf der Evaluator-Persona konfigurierten Qualitäts-Schwellenwert erfüllt. Dieses Feld kann von nachgelagerten Schritten verwendet werden, um zu entscheiden, ob fortgefahren oder eine weitere Verfeinerung ausgelöst wird. Der gesamte Run-Datensatz trägt zudem ein Top-Level-Feld qualityScore (den Composite-Wert aus allen Evaluator-Schritten) für schnelles Filtern und Analytics.

Judge

Der Judge-Schritt vergleicht Ausgaben aus parallelen Branches und entscheidet, welche besser ist. Er wird in Multi-Branch-Evaluations-Szenarien verwendet, in denen zwei oder mehr Implementierungen erzeugt wurden - beispielsweise durch Ausführung desselben Workflows mit unterschiedlichen Modellen oder Anweisungen - und eine endgültige Entscheidung darüber benötigt wird, welche behalten wird.

• Bezeichner des Schritttyps: judge
• Standard-Tool: Claude Code
• Standard-Modell: claude-opus-4-6
• Akzeptiert Input: Ja - empfängt Ausgaben mehrerer Branches zum Vergleich
• Erzeugt Output: Ja - ein Urteil, das den gewinnenden Branch und die Begründung benennt
• Kann iterieren: Nein - läuft einmal, nachdem alle Branches abgeschlossen sind

Der Judge ist ein fortgeschrittener Schritttyp für Teams, die A/B- Experimente mit ihren Workflow-Konfigurationen durchführen wollen. Statt manuell zwei Implementierungen zu prüfen, bewertet der Judge-Agent sie gegen die ursprünglichen Anforderungen und erzeugt einen strukturierten Vergleich.

Answerer

Der Answerer-Schritt wird in Answering-Sessions verwendet, um Fragen und Annahmen zu beantworten, die während Issue-Untersuchungs-Sessions entdeckt wurden. Wenn eine Issue-Session Mehrdeutigkeiten oder Fragen aufdeckt, die eine menschliche oder automatisierte Klärung erfordern, liefert der Answerer Antworten, damit die Pipeline ohne manuellen Eingriff fortgesetzt werden kann.

• Bezeichner des Schritttyps: answerer
• Standard-Tool: Claude Code
• Standard-Modell: claude-sonnet-4-6
• Akzeptiert Input: Ja - empfängt Fragen und Annahmen aus der Issue-Session
• Erzeugt Output: Ja - strukturierte Antworten, die Mehrdeutigkeiten auflösen
• Kann iterieren: Nein - läuft einmal pro Answering-Session

Der Answerer integriert sich in den Issue-Session-Workflow, um die Feedback-Schleife zwischen Untersuchung und Implementierung zu schließen. Er wird am häufigsten in Pipelines verwendet, die einen Investigator- oder Deep-Dive- Schritt enthalten, wobei die Untersuchungsphase offene Fragen aufdecken kann, die vor Beginn der Implementierung beantwortet werden müssen.

Schritt-Konfiguration

Jeder Schritt in einer Pipeline wird über seine Persona konfiguriert. Die Persona definiert:

{
  // Role determines the step type and execution behavior
  type: "designer" | "checker" | "optimizer" |
        "prompter" | "investigator" | "deep-dive" |
        "evaluator" | "judge" | "answerer",

  // CLI tool override (falls back to workflow default)
  cliId: "claude",     // or "opencode", "codex", "pi"

  // Model override (falls back to workflow default)
  model: "claude-opus-4-6",

  // Thinking effort for this step
  thinkingEffort: "high",

  // Custom instructions appended to the step's system prompt
  instructions: "Focus on TypeScript type safety...",

  // Skills enabled for this persona
  selectedSkills: ["vitest-testing", "seo-integration"],

  // Whether to inject compiled learnings
  learningsEnabled: true,
}

Details zur Schritt-Ausführung

Run-Schritt-Datensätze

Jede Schritt-Ausführung erzeugt einen Datensatz in der Tabelle runSteps. Dieser Datensatz verfolgt:

• runId - Referenz auf den übergeordneten Run.
• sandboxId - Die für diesen Schritt verwendete E2B-Sandbox.
• personaId - Die Persona, die diesen Schritt definiert hat.
• cliId - Das verwendete CLI-Tool (z. B. "claude").
• modelId - Das verwendete KI-Modell (z. B. "claude-opus-4-6").
• iteration - Zu welcher Gesamt-Iteration dieser Schritt gehört.
• loopId - Die Loop-Gruppen-ID (falls in einer Schleife).
• loopIteration - Die Iteration innerhalb der Schleife.
• role - Der Schritttyp (Designer, Checker, Evaluator usw.).
• status - pending, running, completed oder failed.
• verdict - Checker-Urteil (Pass/Fail + Feedback).
• qualityScores - Evaluator-Qualitäts-Scores (correctness, typeSafety, codeStyle, testCoverage, completeness, composite, thresholdResult). Wird nur für evaluator-Schritte befüllt.
• startedAt / completedAt - Zeitinformationen.

Schritt-Zeitleiste

Die Run-Detailansicht zeigt eine visuelle Schritt-Zeitleiste, die jeden Schritt als Knoten mit Rolle, Status und Dauer darstellt. Ein Klick auf einen Schritt öffnet dessen Sandbox-Ausgabe. Die Zeitleiste erleichtert das Nachvollziehen des Ausführungsablaufs, das Erkennen, welche Iterationen bestanden oder fehlgeschlagen sind, sowie das Identifizieren von Engpässen.

Bedingte Logik

Das Workflow-System von CodeCourier verwendet ein urteilsbasiertes bedingtes Modell statt expliziter if/else-Verzweigung. Das Pass/Fail-Urteil des Checkers ist der primäre Entscheidungspunkt:

• Pass - Mit dem nächsten Block in der Pipeline fortfahren.
• Fail - Zurückspringen und neu versuchen (innerhalb der Iterations- Limits).
• Max. Iterationen erreicht - Erzwungenes Fortfahren unabhängig vom Urteil.

Dieses Modell hält die Workflow-Konfiguration einfach und bietet dennoch die Feedback-Schleife, die für iterative Qualitätsverbesserung nötig ist.

Parallele Ausführung

Innerhalb eines einzelnen Workflow-Runs werden Schritte sequenziell ausgeführt - Schritt 2 wartet auf den Abschluss von Schritt 1. CodeCourier unterstützt jedoch parallele Ausführung auf Run-Ebene. Sie können mehrere Runs desselben Workflows gleichzeitig starten, die jeweils an unterschiedlichen Aufgaben auf unterschiedlichen Branches arbeiten. So funktionieren Sprint Chains - mehrere Sprints können nacheinander ausgeführt werden, aber die internen Schritte jedes Sprints sind sequenziell.