Core concepts

Seven ideas explain almost everything Slo does.

Skills

A skill is a markdown file that teaches Slo how to do one kind of task well: build a router, write a migration, review a pull request, write a spec. Slo ships with 116 of them.

You don't call skills by name. Describe the work, and Slo picks the skills that match:

"Write a FastAPI router for user sign-up with named arguments and type hints."

Slo sees a routing task, reads build-routers and named-arguments-and-type-hints, and follows both. Ask "what skills do you have for databases?" to see what's there.

See Skills overview.

Workflows

A workflow chains skills into a process with checkpoints. Slo ships with two:

  1. Feature specifications turn a rough request into a verified spec, split into tasks.
  2. Code-test-review takes a task through code, tests, review and a completion check.

Start one by describing the goal: "Write a spec for the refund flow", or "Build task 12.b and review it".

Sub-agents

For big jobs, Slo can act as an orchestrator: it splits the work into phases and gives each one to a sub-agent, a separate Slo process with its own clean context. The orchestrator checks the results and retries what fails. This is a dynamic workflow. Ask for one with the words "dynamic workflows".

Sessions

Every conversation is a session, saved as it goes under ~/.slo/sessions/. Quit whenever you like and come back with:

slo --resume <session-id-or-name>

Name sessions with /rename so they're easy to find. See Sessions & context.

Instruction files

At the start of every session, Slo reads SLO.md, AGENTS.md, CLAUDE.md and docs/RESEARCH.md from your project folder and every folder above it, plus one global file from ~/.slo/. This is where your ground rules live: how to run the tests, what not to touch, the conventions that aren't obvious from the code.

If your project has none yet, ask:

"Draft an SLO.md for this repository."

Knowledge base

Some knowledge belongs to no single project: how your services fit together, the incident last spring, the library version that breaks the build. Point SLO_KB_DIR at a folder of markdown notes:

export SLO_KB_DIR=~/notes/kb

Slo consults it before designing or debugging, and writes back anything non-obvious it discovers. It's optional. See Give Slo a memory.

Overrides

Everything opinionated in Slo is a file you can replace. Put a skill in ~/.slo/user_skills/<name>/SKILL.md and it's used instead of the built-in skill of the same name. Slo logs when that happens, so an override is never silent. Keep Slo's defaults and change only what your team does differently.

See Build your own skill.