Feature specifications

The feature specifications workflow takes a plain-language description of something you want to build and produces a verified, structured specification document with a full task breakdown.

How to start it

Just describe what you want to build:

"Write a feature specification for adding Stripe payments to the checkout flow."

"I need a spec for a background job that syncs orders from the Shopify API every 15 minutes."

Slo recognises the intent and runs the full specification workflow automatically.

What happens

PRE hook — context gathering

Before writing anything, Slo reads:

  • Your CLAUDE.md — coding conventions and ground rules
  • The relevant code surfaces in your project
  • Your knowledge base (if you have one at ~/Code/KnowledgeBase/)
  • Any applicable skill files for the tech stack involved

This makes sure the spec reflects your actual conventions, not generic advice.

Spec writing

Slo writes the specification as a structured document covering:

  • What — the user-facing behaviour and acceptance criteria
  • Why — the motivation, constraints, and stakeholders
  • How — the technical approach, broken down by layer (API, domain, UI, tests)
  • Second-order requirements — scale, latency, idempotency, logging, deployment

POST hook — verification

After writing, Slo verifies the spec against:

  • Every applicable build-*.md skill for the tech stack
  • Your test verification policy
  • Completeness — does it cover all the cases it needs to?

If anything is missing, Slo revises and re-verifies before finalising.

Task breakdown

Once the spec passes verification, Slo produces a numbered task list, ordered by dependency, ready to hand off to an engineer or to start immediately.

Output

The spec is saved to specifications/<feature-name>/ in your project directory. Each run produces:

  • spec.html — the full specification document
  • tasks.md — the numbered task breakdown

Tips

  • The more context you give upfront, the better the spec. Mention the tech stack, affected users, and any known constraints.
  • If you have existing API documentation or a knowledge base, make sure Slo can see it — it uses those to check for consistency.
  • You can ask Slo to revise the spec after reviewing it: "The spec looks good but the auth section is missing — please add it."