Build your own workflow

A workflow is a process with steps Slo won't skip. The built-in ones cover specs and code-test-review. Yours can cover whatever your team does repeatedly: releases, bug triage, dependency upgrades, onboarding a new service.

Your workflows live in ~/.slo/user_workflows/, next to the built-in ones.

Ask Slo to write it

Describe the process step by step, including what has to be true before moving on:

"Create a user workflow for releases. Check there are no open merge requests against main, run the full test suite, update the changelog from merged MRs, tag the release, and stop for my approval before pushing the tag."

"Build a workflow that takes a bug report and produces a triage note: severity, affected files, a likely cause, and a suggested fix."

Slo uses its create-user-workflow skill to write the file and saves it to ~/.slo/user_workflows/<name>/SKILL.md.

What's in a workflow

A workflow is a SKILL.md with kind: workflow in its header. The body lists the steps, the skills each step uses, and when a step counts as done:

~/.slo/user_workflows/
└── release/
    └── SKILL.md

Good workflows say, for every step:

• what it needs as input,
• which skill or conventions apply,
• what it produces,
• what must be true before the next step starts.

Running it

Ask for it like a built-in workflow:

"Run the release workflow for version 2.4.0."

Like the built-in workflows, it pauses after each step unless you say "run it to completion". Add "use dynamic workflows" to give each step its own sub-agent.

Using skills inside a workflow

Name the skills a step should follow, and Slo reads them when it gets there:

"In the review step, use the review-feature-code skill."

That's how a workflow stays short: the how lives in skills, and the workflow only decides the order.

Changing it later

Edit the SKILL.md in any editor, or ask:

"Update the release workflow to create a GitLab release after tagging."