Put Slo on autopilot

Everything you do in the TUI, Slo can do without it. This guide covers three setups, from simplest to most involved: a review in CI, a morning report, and a scheduled check-in on a long-running workflow.

Before you start

Unattended runs don't see your shell profile or the sign-in you did in the TUI unless you set them up. Two things to sort out first:

Credentials. On your own machine, the saved sign-in from /auth works. On a CI runner, use an API key from your secrets:

export OPENAI_API_KEY="$CI_OPENAI_API_KEY"

Pop-ups. Turn off the visualizer window, since there's no screen to show it on:

export SLO_AUTO_VISUALIZE=0

The CI profile has a complete set.

1. A review on every merge request

slo run prints one JSON event per line and exits with 0, 1 or 2. That's all a CI job needs.

# .gitlab-ci.yml
slo-review:
  stage: test
  script:
    - curl -fsSL https://get-slo.sh/install.sh | bash
    - export PATH="$HOME/.local/bin:$PATH"
    - |
      slo run \
        -p "Review the changes on this branch against main. Focus on bugs,
            missing tests and anything that breaks our conventions in SLO.md.
            End with BLOCKING or OK on its own line." \
        > review.jsonl
    - jq -r 'select(.kind == "run_completed") | .content' review.jsonl | tee review.md
    - tail -n 1 review.md | grep -q '^OK$'
  artifacts:
    paths: [review.md]

The final grep fails the job when the review ends with BLOCKING. The same shape works in GitHub Actions or any other runner.

2. A morning report

For work on your own machine, let your OS run it. On macOS that's launchd, on Linux cron, and Slo sets either up for you:

slo schedule add \
  --name "Morning test report" \
  --prompt "Run the full test suite. Summarise failures, flaky tests and anything new since yesterday." \
  --cron "0 7 * * 1-5" \
  --cwd ~/code/payments \
  --session-mode fresh

slo schedule install --name "Morning test report"

Each morning on weekdays it runs, then saves a record. Read them with:

slo schedule reports --name "Morning test report"

fresh means each run starts clean. Use continuous when you want each run to build on the last, like a running log of a release.

See Schedulers for triggers, time zones and the rest.

3. Check in on a long workflow

A dynamic workflow can run for hours. Instead of watching it, schedule a check-in that lands in the same session:

slo schedule add \
  --name "Refunds check-in" \
  --prompt "Check the running sub-agents. Report which phases are done,
            retry anything that stalled, and summarise what's finished." \
  --cron "0 * * * *" \
  --session-mode continuous \
  --session-reference refunds \
  --coalescing-mode latest_by_key \
  --coalescing-key refunds

slo schedule install --name "Refunds check-in"

If the refunds session is open in a TUI, the check-in waits in its inbox and runs when the TUI is idle, so two processes never write to one session. If it isn't open, Slo resumes it in the background. latest_by_key means that if you're away for a while, you get one pending check-in, not twelve.

4. Keep context between steps

Several slo run calls can share one conversation. Give them the same session id:

export SLO_SESSION_ID="release-$(date +%F)"

slo run --enable-history -p "List everything merged since the last tag."
slo run --enable-history -p "Group those changes into features, fixes and chores."
slo run --enable-history -p "Write release notes from that grouping."

The third call sees what the first two found.