Feature specifications

The feature specifications workflow turns a rough request into a spec you'd be happy to hand to another engineer, then splits it into tasks small enough to build and review one at a time.

Starting it

Describe what you want built:

"Write a feature specification for partial refunds from the admin panel."

"Spec out a background job that syncs orders from Shopify every 15 minutes."

Or point at a ticket, if you've set up the Jira connector:

"Write a feature specification for PAY-412."

The more you say up front about users, constraints and the code it touches, the less Slo has to guess.

What happens

Step 1: Gather context, then write

Before writing anything, Slo reads your instruction files (SLO.md, AGENTS.md), the parts of the code the feature touches, your knowledge base if you have one, and the skills for your stack. That keeps the spec grounded in how your system actually works.

Then it writes the spec: what the feature does and why, how it should behave, the edge cases, how it fails, how it's tested, and the implementation details specific enough that nobody has to guess.

Straight after writing, it checks its own draft. Does anything duplicate code that already exists? Does it follow your conventions? Are the examples concrete? Is the scope too big? It revises until the answer is yes.

Step 2: Verify

A separate pass looks for gaps: decisions that haven't been made, edge cases without an answer, acceptance criteria that contradict each other. Anything it finds gets fixed before moving on.

Step 3: Break it into tasks

Finally, Slo splits the spec into tasks, ordered by what depends on what, each one small enough to build and test on its own.

What you get

specifications/12-refunds/
├── overview.md                   the feature, why it matters, and a technical map
├── 12.a-refund-model.md          one file per task
├── 12.b-refund-endpoint.md
└── 12.c-admin-panel-button.md

The folder is numbered so specs sort in the order they were written. Each task file stands on its own, so you can hand one to Slo (or a person) without the rest.

Controlling the pace

By default Slo pauses after each step so you can read what it wrote. That's the moment to push back:

"12.b should reject refunds over the remaining balance, not cap them. Revise and re-verify."

To run all three steps without stopping, say "run it to completion".

Next

Build the tasks one at a time with code-test-review. The whole path is in From spec to merged PR.