Core concepts

Understanding these concepts unlocks everything Slo does.

Skills

A skill is a structured prompt document that teaches Slo a repeatable task. Skills live in ~/.slo/skills/ and cover topics like writing domain services, building routers, running tests, or generating swagger docs.

You don't invoke skills by name. You describe what you want and Slo automatically loads the relevant skills:

"Write me a FastAPI router for user authentication with named arguments."

Slo sees a routing task, loads build-routers and named-arguments-and-type-hints, and applies both.

You can always ask Slo which skills it has for a given topic:

"What skills do you have for working with databases?"

"What skills do you have for building Vue components?"

Skills are the building blocks. Workflows compose them.

Workflows

A workflow is an orchestrated sequence of skill invocations that produces a structured output. Slo ships with two:

  1. Feature Specifications — turns a rough request into a verified, task-broken spec
  2. Code-Test-Review — guides a feature from code to tests to reviewed PR

Workflows are triggered the same way — just describe the goal in plain language:

"Write a feature specification for the beta signup page."

"Help me test the payment module and open a pull request when it's done."

Sessions

The TUI persists your full conversation history by default. Each session is stored under:

~/.slo/sessions/history/<session_id>/

Each session directory contains a session.json (metadata) and an append-only JSONL file of tool call events.

Resume a past session at any time:

slo --resume <session_id_or_name>

You can override the storage location by setting the SLO_HOME environment variable.

Headless runs (slo run -p "...") do not persist history by default. Add --enable-history to opt in:

slo run --enable-history -p "Refactor the auth module."

Project context

Slo automatically reads context files from your project to understand your team's conventions, architecture, and ground rules. It walks up the directory tree from your working directory looking for:

  • SLO.md
  • AGENTS.md
  • CLAUDE.md

A global ~/.slo/SLO.md (if present) is prepended first, so user-level preferences are always in scope.

If your project has no context file yet, ask Slo to generate one:

"Generate a RESEARCH.md and AGENTS.md for this project."

These generated files give Slo a map of your codebase structure, key conventions, and agent operating instructions that persist across sessions.

Knowledge base

Set the SLO_KB_DIR environment variable to point Slo at a curated markdown knowledge base:

export SLO_KB_DIR=~/Code/KnowledgeBase/KB

Slo reads the knowledge base using the same tools it uses to read project code — read, grep, and related file tools. This means it can navigate folders, follow cross-links, and search by symptom.

A knowledge base is useful for:

  • Cross-project patterns — distilled architecture decisions that apply across multiple repos
  • Failure-mode lookups — known pitfalls and their fixes, accumulated over time
  • Team conventions — anything too broad to belong in a single project's context file

If SLO_KB_DIR is not set, Slo works without it — the variable is optional.

Conventions

Slo's built-in skills enforce conventions: named arguments, type hints, declarative method structure, and more. These conventions apply to every file Slo touches.

You can override any convention by placing your own skill file in ~/.slo/user_skills/.

The override model

Built-in skills live in the Slo package. User skills shadow them. If Slo finds ~/.slo/user_skills/typescript-named-arguments/SKILL.md, it uses that instead of the built-in.

This means you can adopt Slo's defaults for your team and override only what needs to be different.