Write a brief Slo can run with

"Fix the payments bug" works for a two-minute job. For anything bigger, the prompt is the plan, and a vague plan gets you a vague result.

The people who get the most out of Slo write briefs, not prompts. A brief is what you'd hand a new senior engineer on their first day: what we're doing, where the truth lives, what not to touch, and how we'll know it's finished. It takes five minutes to write and saves you an afternoon of corrections.

The six parts

You don't need headings or a fixed format. You need all six answered somewhere.

A brief that works

Here's a real-shaped brief for a sample payments service:

Implement task 12.b (refund endpoint) in ~/code/payments on the
existing branch feature/refunds. Nothing else from the spec.

The spec in specifications/12-refunds/ is authoritative. Read
overview.md and 12.b-refund-endpoint.md before writing code.
Also read AGENTS.md and docs/RESEARCH.md.

Boundaries:
- Don't commit or push.
- Don't change anything under deploy/ or migrations/ that already exists.
- The worktree has uncommitted work from me. Inspect it and build on it
  if it matches the spec. Never discard it.

Deliverables:
- The endpoint, its service method and tests for every decision point.
- A short note in docs/RESEARCH.md about the idempotency key rule.

Done means: `make test` and `make lint` pass. End with a summary of
what changed, what you verified, and anything you're unsure about.

Slo reads that, loads the matching skills (routers, services, tests, docstrings), and starts with the reading list. You'll see it cite the spec as it goes.

Why each part matters

Outcome keeps the scope honest. Agents are eager. Say "task 12.b only" and Slo won't helpfully start 12.c.

Sources of truth settle arguments before they happen. If the spec and an old README disagree, you've already said which one wins.

Required reading is cheap context. Pointing at three files costs you one sentence and gives Slo your architecture, conventions and history. See Give Slo a memory for what to keep in those files.

Boundaries are where most damage is avoided. "Don't commit", "don't touch deployments" and "keep my untracked files" show up in hundreds of real briefs for good reason.

Deliverables stop useful knowledge from evaporating. If Slo figured out something non-obvious, ask it to write that down where the next session will find it.

Done means gives the run a finish line. Without one, you'll end up asking "are we done?" and getting a guess. With one, Slo checks its own work against something concrete and tells you what's left.

Say it once, not every time

If you find yourself repeating the same boundaries in every brief, move them into SLO.md at the project root (or ~/.slo/SLO.md for all projects). Slo loads those files at the start of every session, so your brief can shrink to the parts that change.

Follow-ups that work

Once a brief is running, short messages are fine because the context is already there:

• "Proceed to the next task in the breakdown."
• "What's left? Check against the task list, not from memory."
• "Run the full test suite and tell me what fails before fixing anything."
• "Explain the change to the retry logic in plain terms."
• "Commit this with a message that says what changed and why."

While Slo is mid-run you can add direction without stopping it with /steer, or stop the current step with /abort. See Slash commands.

Scaling a brief up

A brief with several independent tasks is a good fit for a dynamic workflow. Add "use dynamic workflows" and Slo turns your brief into phases, hands each to its own sub-agent, and checks their work. The six parts matter even more there: every sub-agent gets its own copy of your boundaries.