Pipelines
Pipeline as code
Pull a pipeline to JSON, edit it, and push it back.
Pipelines are portable JSON. Steps, edges, and triggers reference each other by
step_key (not internal IDs), so a spec is human-editable, diffable, and reusable
across pipelines and orgs.
premia pipelines list
premia pipelines pull <id> # → <id>.pipeline.json
premia pipelines push my.pipeline.json --id <id> # update an existing pipeline
premia pipelines push my.pipeline.json --project p # create a new oneThe spec
{
"name": "Default Pipeline",
"start": "plan",
"steps": [
{ "step_key": "plan", "agent_slug": "plan", "label": "Planner", "position_x": 400, "position_y": 0 },
{ "step_key": "develop", "agent_slug": "execute", "label": "Developer", "position_x": 400, "position_y": 180 }
],
"edges": [
{ "from": "plan", "to": "develop", "condition": "success" },
{ "from": "review", "to": "revise", "condition": "changes_requested" },
{ "from": "revise", "to": "review", "condition": "revised", "loop": true, "max_iterations": 3, "on_exhausted": "escalate" }
],
"triggers": [
{ "event_type": "branch_pushed", "step_key": "rebase" },
{ "event_type": "pr_comment", "step_key": "revise" }
]
}Conditions
Edge condition matches the source agent's outcome. Common values: success /
failure (generic), approved / changes_requested (review & requirements),
revised (the reviser made changes). The engine also matches a coarse
success/failure fallback, so approved satisfies a success edge too.
Applying a spec replaces the pipeline's steps/edges/triggers, so keep the JSON in your repo as the source of truth if you manage pipelines this way.