I built SLCR to address known limitations in spec-driven development. Specs codify a project's desired behavior in a human-optimized format that serves as a central source of truth for implementation agents. But when agents re-ingest the entire document when implementing, or translating to tickets it can introduce errors in different ways:
1. Ingesting the entire spec can lead to context bloat, which not only costs extra tokens, but also decreases agent coherence.
2. Translating spec to tickets can be lossy because agents may make small omissions or conflate information required across multiple tickets.
Further, errors compound from agent session to session, making small omissions or missed details early in the process much bigger problems after multiple rounds of iteration.
SLCR (Sliceable, Linked, Checkable Requirements, pronounced slicer) is a new open-standard document format to make sure agents build to spec every time, without sacrificing human readability.
Requirements live in one structured spec file (TOML, JSON, or YAML), with typed edges between requirements forming a DAG. Agents read small, task-specific walks of the DAG called slices, which provide them with all of the context they need to understand a given requirement with none of the superfluous context.
Requirements can have acceptance criteria that can be checked by a validators, which is a mapping to an executable tool to verify the requirement, vitest, your linter, or ast-grep. Requirements can be composed with AND, OR, or XOR, and the SLCR CLI can check whether each requirement is satisfied, so your spec is always synced to your codebase's current status. This helps prevent multi-session agent drift and misalignment by ensuring that no agent session invalidates existing pinned requirements.
A slice is one requirement plus the context it actually needs, determined by walking the DAG from a leaf node back to the root. When an agent picks up a ticket, you give it the slice instead of the whole spec, eliminating superfluous text unrelated to the requirement at hand. People still get the full picture, because the CLI renders the whole spec to deterministic, read-only Markdown.
There's also an agent skill that teaches agents to use the CLI and write valid SLCR.
This tool is for engineers and tech leads on long-lived codebases who are giving agents real implementation work and want a check beyond reading the diff. If you're writing one-off scripts or throwaway prototypes, you probably don't need this.
The format is an open standard. The reference implementation written in Rust and released under the MIT license. Pull requests welcome!
I built SLCR to address known limitations in spec-driven development. Specs codify a project's desired behavior in a human-optimized format that serves as a central source of truth for implementation agents. But when agents re-ingest the entire document when implementing, or translating to tickets it can introduce errors in different ways:
1. Ingesting the entire spec can lead to context bloat, which not only costs extra tokens, but also decreases agent coherence. 2. Translating spec to tickets can be lossy because agents may make small omissions or conflate information required across multiple tickets. Further, errors compound from agent session to session, making small omissions or missed details early in the process much bigger problems after multiple rounds of iteration.
SLCR (Sliceable, Linked, Checkable Requirements, pronounced slicer) is a new open-standard document format to make sure agents build to spec every time, without sacrificing human readability. Requirements live in one structured spec file (TOML, JSON, or YAML), with typed edges between requirements forming a DAG. Agents read small, task-specific walks of the DAG called slices, which provide them with all of the context they need to understand a given requirement with none of the superfluous context.
Requirements can have acceptance criteria that can be checked by a validators, which is a mapping to an executable tool to verify the requirement, vitest, your linter, or ast-grep. Requirements can be composed with AND, OR, or XOR, and the SLCR CLI can check whether each requirement is satisfied, so your spec is always synced to your codebase's current status. This helps prevent multi-session agent drift and misalignment by ensuring that no agent session invalidates existing pinned requirements.
A slice is one requirement plus the context it actually needs, determined by walking the DAG from a leaf node back to the root. When an agent picks up a ticket, you give it the slice instead of the whole spec, eliminating superfluous text unrelated to the requirement at hand. People still get the full picture, because the CLI renders the whole spec to deterministic, read-only Markdown. There's also an agent skill that teaches agents to use the CLI and write valid SLCR.
This tool is for engineers and tech leads on long-lived codebases who are giving agents real implementation work and want a check beyond reading the diff. If you're writing one-off scripts or throwaway prototypes, you probably don't need this.
The format is an open standard. The reference implementation written in Rust and released under the MIT license. Pull requests welcome!
Repo: https://www.github.com/wack/slcr Site: https://www.slcr.dev