Workflows
Declarative, versioned pipelines: phases, steps, gates, and status automation in plain YAML.
A workflow is a YAML file in .warden/workflow/ —
versioned with your code, reviewed like your code. It declares the
phases a run moves through and what each phase does.
Phases and steps
version: 1
name: feature
phases:
- id: spec
title: Spec
gate: true
steps:
- type: prompt
prompt: Write a short spec for the task.
persona: architect
- id: coding
title: Coding
gate: true
steps:
- type: prompt
prompt: Implement the approved spec.
- type: check
name: test
run: pnpm test
- id: merge
title: Merge
terminal: true
steps:
- type: git
action: merge
method: squash
- type: notify
to: slack
message: Run merged.
Five step types cover the pipeline:
- prompt — hand the agent an instruction; optionally as a persona, with a pinned model or reasoning effort.
- check — run a command that must succeed (tests, linters); failures stop the phase and show in the live view.
- command — run a shell command for its effect.
- git — branch, commit, or merge the run's work.
- notify — tell a connected channel (Slack, Discord, Teams, Telegram, webhook) what happened.
Gates
gate: true parks the run when the phase's steps finish,
until a human approves or requests changes. A phase can also restrict
who may approve it with approvers: — see
Gates & reviews.
Status automation
Phases can bind to your task board: onStatus names the
column that triggers the phase when a task moves into it, and
setStatus names the column the task moves to when the phase
completes. With those two fields, dragging a card across the board is
what drives execution.
Agents and personas
The default agent is Claude Code; a workflow (or a single step) can
select a provider, model, and reasoning effort via agent: /
model: / effort:. Personas —
.warden/persona/<id>.yaml files with a name, icon,
color, and system prompt — give each step a reusable identity.