Skip to content
SLCR

Concepts

Slices

What a slice contains, what it leaves out, and how slicing affects the way a spec is written.

A slice is the part of a spec that one requirement needs: everything required to understand and implement that requirement, and nothing more. slcr slice REQ-ID prints it as Markdown that reads like a shortened version of the rendered spec.

Slices address context rot. An agent given a whole requirements document has to work out which parts matter for its task, and it gets that wrong more often as the document grows. A slice makes that selection in advance by following the spec's links, so it doesn't depend on the agent's judgment.

What a slice contains⁠Link to this section

For a requirement R, the slice contains:

  • R's ancestors, as headings with their bodies. This is the background that every section and requirement above R provides.
  • R and everything that refines it, in full, with acceptance criteria. This includes refiners nested elsewhere in the tree. For example, the slice of todo-api's GET requirement includes the authentication requirement, even though that requirement is nested under POST.
  • What R refines, under "Related requirements", so the implementer knows what larger requirement the work is part of.
  • Everything R and its refiners depend on, following dependsOn links transitively, also under "Related requirements". Each dependency appears with its acceptance criteria and the sections it sits in, so its background is included too.
  • A glossary of the terms used by everything above.

A node included for more than one reason appears once, in the most detail any of those reasons calls for. Nodes keep their numbers from the full document, and a reference to a node outside the slice appears as plain text, so every link in the slice resolves.

What a slice leaves out⁠Link to this section

A slice leaves out everything not reachable from the requirement:

  • Sibling requirements. They belong to other tasks. Including them invites an agent to build them too, or to mix their details into its own work.
  • The internals of dependencies. A dependency shows its own statement and criteria, not the requirements that refine it.
  • Unrelated sections, however close they are in the document.

An example⁠Link to this section

In todo-api, the controller requirement REQ-005 is refined by "Validates the request payload" and depends on the endpoint (REQ-001) and the table (REQ-007). Here is its slice, with link anchors removed and the glossary simplified:

Markdown
# TodoList API

A REST web application in MVC layout with one resource.

## 2. Controllers

### 2.1 TodoListItem controller

There MUST be a controller for TodoListItem.

All of the following must hold:

- Validates the request payload

*Depends on:* TodoListItem endpoint, Table todo_list_item exists

#### 2.1.1 Validates the request payload

The controller MUST validate the request payload.

## Related requirements

### 1. Views

The API surface.

### 1.1 TodoListItem endpoint

*In:* TodoList API › Views

There MUST be an endpoint for the TodoListItem resource.

### 3. Models

Persistence assumptions.

### 3.1 Table todo_list_item exists

*In:* TodoList API › Models

There MUST be a table `todo_list_item` with columns `title` (string) and `done` (bool).

*Acceptance criteria:*

**Table schema is declared**

A table named `todo_list_item` is declared with a string column `title` and a
boolean column `done`. A structural match against the schema or migration
source is sufficient.

## 5. Glossary

TodoListItem
: A single item on a to-do list, with a title and a done flag.

The controller's implementer receives the endpoint and table it works with, and the meaning of "TodoListItem". It doesn't receive the POST and GET requirements under the endpoint, or the Authentication section. Authentication matters to the API, but it isn't part of the controller's task.

How slicing affects spec structure⁠Link to this section

Because a slice is built from links and ancestry, where information sits in a spec determines which slices include it:

  • A section's body reaches every slice beneath it. Background placed in a sibling section doesn't reach neighboring requirements.
  • Context from elsewhere in the spec reaches a requirement's slice only through a dependsOn link.
  • A term's definition reaches a slice only through usesTerm.

slcr slice shows exactly what an implementer will see, which makes gaps in a spec's structure visible. A missing piece of context usually indicates a missing link or misplaced background.

Slices are useful to people too. A reviewer checking one change can read the slice of the requirement it implements instead of searching a long document for the relevant parts.