Build a multi-step workflow

A single Issue Session is a tactical move. A workflow is a strategy. In this guide you compose five distinct phases - triage, planning, execution, review, and shipping - into one pipeline that runs unattended from a ticket title to a merged pull request. The whole thing should take about 45 minutes to build and will save you hours every week.

1. Pick the right shape for your workflow

Before you open the Workflow Builder, sketch the pipeline on paper. Real workflows almost always follow the same skeleton: a wide intake funnel, a planning bottleneck where a human can intervene, a fan-out execution phase, a review gate, and a shipping step. We will build exactly that.

The point of the skeleton is not novelty - it is repeatability. Every sane engineering process moves through these five phases. Encoding them once in CodeCourier means you stop reinventing the process per ticket.

2. Create the four personas you need

Open the Personas tab and create four entries. Each will be referenced by the workflow. Keep them small and opinionated rather than trying to make one persona do everything.

• Triage - fast model, low thinking budget. Reads a ticket, decides if it is in scope, labels it with priority, and attaches the right repo.
• Planner - strong model, high thinking budget. Reads the repo against the ticket and drafts a numbered plan that cites real files and lines.
• Coder - balanced model, full tools. Implements the plan. Has access to your test runner and linters.
• Reviewer - strong model, no write tools. Reads the diff against your standards and produces a structured review.

3. Open the Workflow Builder

In the dashboard, click Workflows → New workflow. Name it something boring and durable - standard-ticket-flow rather than experimental-thing-v3. Future-you will thank present-you for the discipline.

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

4. Wire the five steps

Drag five blocks onto the canvas in order. The Workflow Builder makes the connections explicit - output of one step is the input of the next, with optional fan-out where it makes sense.

• Step 1: Triage - Triage persona reads the ticket and emits {priority, scope, repo}. Skip everything downstream if scope is out-of-scope.
• Step 2: Plan - Planner persona reads the repo and emits a numbered plan. Add a Human approval node here. This is the only point in the workflow where a human is in the critical path.
• Step 3: Execute - Coder persona runs against the approved plan inside an E2B sandbox.
• Step 4: Review - Reviewer persona grades the diff. If the score is below your threshold, route back to step 3 with the review notes attached.
• Step 5: Ship - open a pull request and notify the channel. No persona needed - this is a deterministic action node.

5. Test with a known-good ticket

Before pointing your workflow at the real backlog, run it through a ticket you have already solved manually. Compare the agent's plan and diff to what you actually did. Look for two failure modes: the agent skipping a step you considered essential, or the agent adding a step you would have refused. Both are tuning signals.

A workflow is not done when it produces output. A workflow is done when it produces output you would have produced.

6. Tighten the loop

Iterate on the Planner persona first - most workflow failures trace back to a bad plan, not a bad coder. Lower the thinking budget on Triage if you find it overthinking simple tickets. Raise the Reviewer threshold gradually as you build trust.

7. Next steps

Once the workflow is stable, the obvious upgrades are: parallelise execution across multiple tickets with a Sprint Chain, plug GitHub issue auto-ingestion into the trigger, and wire webhooks into your Slack channel so the team sees workflow events without leaving chat.

The Design a Frontend Persona guide is the natural next read if you want to specialise the Coder persona for a specific stack.