3. Design a pipeline

A pipeline is your delivery process, written down: what happens to a task, in what order, who or what decides that a step is done, and what happens when it is not.

Open Pipelines in the sidebar. The screen is an editor: pipelines of every project you can access on the left, the selected one on the right.

Pipeline authoring is behind a feature flag. If the screen is empty or the API answers 404, enable it once:

kodelctl feature enable pipelines
kodelctl feature enable pipelines.localRunner   # steps that run on your machine

Start from the template

Press New, name it (Feature delivery), and you get a working three-step pipeline you can edit:

#	Step	Kind	What it does
1	Plan	AI step	Break the task into concrete steps before any code
2	Implement	AI step	Write the code
3	Test	Check	Run `npm test`

Plan → Implement → Test, each transition firing when the previous step passes. That is already a complete process — the rest of this page is how to shape it into yours.

The five kinds of step

The toolbar adds them:

AI Step — an agent does the work. This is where prompts live.
Check — something must pass: a shell command like npm test, an automated review of the diff, or an evaluation.
Approval — a human decides. The run pauses until someone approves or rejects, and you can restrict who is allowed to.
Set Status — move the task in the tracker, e.g. to In Review when implementation ends. The process drives the board instead of someone remembering to drag a card.
Commit — record the produced changes as a commit on the run branch.

Inside a step

Expand a step to configure it:

Behavior — either Write instructions (a prompt, right there) or Use a skill, a reusable prompt stored in the project. Skills are how you stop copy-pasting the same “how we do code review here” into every pipeline.

Acceptance — how the step is allowed to finish:

Just continue — the outcome is whatever the step reported;
Auto-check — a check must pass before the run moves on;
Human approval — someone signs off.

Acceptance is the difference between “an agent did something” and “the work passed our bar”. Put a human approval after planning and you get a cheap gate before any code is written; put an auto-check after implementation and nothing proceeds on a red test suite.

Where it runs — the selector on the step row. Developer’s machine means the step is executed by your own agent (the flow these docs use). The same pipeline can send other steps to infrastructure Kodel manages.

Transitions: what happens next

Under each step is its outgoing transition — → Implement (passes). Add more with + transition to describe the interesting cases:

a failing check goes back to the implementation step instead of ending the run — that is a rework loop, and it is what the analytics later counts as a “return”;
a rejected approval goes back to planning;
a passing check moves forward.

Because failure paths are part of the graph, a run does not just stop with an error: it goes where you said it should.

Validate, publish, version

Validate checks the graph before you commit to it — unreachable steps, missing prompts, contradictory settings.

Publish turns the draft into a version. The header tracks the state: draft · saved while you edit, v1 · no changes once published. Runs always use a published version, so editing a pipeline never disturbs a run already in flight. History shows previous versions.

The three view modes — List, Canvas, YAML — are the same pipeline. The YAML view is the whole definition as text: keep it in your repository, review it in a merge request, apply it with kodelctl if you prefer configuration as code.

Create a task for the pipeline to run on.