sspec
Spec-driven development for AI coding. Developer controls the agent. State lives in files, not chat.
The Idea
AI coding agents can generate code cheaply and abundantly, but judging whether code is correct is the most expensive operation — it happens last, and is hard to undo.
sspec's core strategy: move verification forward from the expensive final artifact to a cheap, faithful proxy — the spec. You can predict what the code will look like from the spec, and make your judgment before writing begins.
The goal of collaboration is not for the agent to obey the user, but for both sides to converge on intent ∧ reality: what you genuinely want, combined with what the world actually permits.
Three principles:
- Verify early: The spec is the faithful proxy. You predict outcomes from the spec, not from the code.
- Externalize state: Intent and decisions live in repository files. Agents resume from files, not from chat history.
- Enforce alignment: Stop before irreversible investment. Confirm intent ∧ reality are aligned.
Is sspec for you?
Yes if you:
- can judge whether code is correct, and want the agent to accelerate you rather than decide for you
- are willing to invest time aligning direction before writing begins
Probably not if you:
- cannot judge code quality and need the agent to take full responsibility
- prefer rapid iteration without reviewing intermediate artifacts
How it works
Request — user intent
sspec request new add-password-reset # directive (default)
sspec request new strange-logout-bug --kind observe
sspec request new async-refactor --kind idea
Change — atomic unit of work
A change is a cohesive, reviewable piece of work. It lives in .sspec/changes/<name>/ and contains:
| File | Purpose |
|---|---|
spec.md |
Problem, approach, scope, and success criteria — the contract |
tasks.md |
File-level execution checklist with progress |
memory.md |
Current state, key decisions, milestones — continuity across sessions |
design.md |
(optional) Technical design for interfaces, data models, architecture |
revisions/ |
(optional) Causal records for accepted semantic evolution |
Lifecycle
Clarify → Design → Plan → Implement → Review
■ ■
■ = hard stop. The agent must wait for your review before proceeding.
- Design gate: Review
spec.md(+design.md). After acceptance, these files stay current; semantic evolution also records its cause inrevisions/and its version inspec.md. - Implementation gate: Review the code. Fix issues, amend scope, or approve as done.
Memory — continuity file
memory.md is how the agent resumes. Next session, the agent reads memory.md first — it knows exactly where the work stands, what files matter, and why past decisions were made. No reconstructing from chat history.
Spec-docs — long-lived knowledge
Architecture decisions, design patterns, platform constraints — things that outlive any single change. Live in .sspec/spec-docs/, referenced by the agent across all changes.
Folder layout
project/
├── AGENTS.md ← lightweight router (agent reads this first)
├── .agents/skills/ ← synced from .sspec/skills/
└── .sspec/
├── project.md ← your stack, conventions, key paths
├── SSPEC.rule.md ← managed sspec workflow rule
├── requests/ ← intent records (directive / observe / idea)
├── changes/ ← active and archived changes
│ └── <name>/
│ ├── spec.md
│ ├── tasks.md
│ └── memory.md
├── spec-docs/ ← architecture and design knowledge
├── skills/ ← agent-facing skill definitions
├── asks/ ← structured Q&A records
├── howto/ ← operational guides
└── tmp/ ← scratch space
Quick Start
1. Install and initialize
pip install sspec
cd your-project
sspec project init
Then fill .sspec/project.md with your stack, key paths, and conventions.
2. Start work — two paths
Path A: Describe your need to the agent. Tell the agent what you want. A capable agent reads AGENTS.md, then .sspec/project.md, and loads .sspec/SSPEC.rule.md when the task needs the sspec workflow — it clarifies, creates a change, writes the spec, and stops at the design gate for your review.
Path B: Write a request file. If you have clear ideas, create a request:
sspec request new add-dark-mode
Fill in background, problem, direction, and success criteria. The agent picks it up from there.
3. Review at gates
The agent stops at two points:
- Design gate: read
spec.md, confirm the approach, then tell the agent to proceed. - Implementation gate: review the code, request fixes, or approve.
4. Archive when done
sspec change archive --with-request <name>
Common commands
# Requests
sspec request new <name> [--kind directive|observe|idea]
sspec request list
# Changes
sspec change new <name> [--from <request>] [--root]
sspec change status <name>
sspec change list
sspec change archive <name> --with-request
# Project
sspec project status
sspec project update --dry-run
# Docs
sspec doc new "Architecture Overview"
# Tools
sspec tool now
sspec tool mdtoc README.md
Run sspec --help for the full command list.
License
AGPL-3.0
Metadata
Release files for sspec 2.8.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| sspec-2.8.1.tar.gz | 4.0 MB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| sspec-2.8.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 4.2 MB
Release files / sspec-2.8.1.tar.gz
| Download URL | sspec-2.8.1.tar.gz |
|---|---|
| Size | 4.0 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8e1de156d4633ac71d325455c05b797f00e99182aa257696d332b714b021d40a
|
|
BLAKE2b-256 checksum How to use checksums |
49c0b6ad2151023dabeb26cf45eb457d6ed535d19590a772e4bbc43f7a6c14d5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.9.16 {"installer":{"name":"uv","version":"0.9.16","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":null,"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
|
Release files / sspec-2.8.1-py3-none-any.whl
| Download URL | sspec-2.8.1-py3-none-any.whl |
|---|---|
| Size | 223.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
8449385e7c9ecf4a76692229c84ea94b08e76dfaaf5434c3a10df5fc1e3f0743
|
|
BLAKE2b-256 checksum How to use checksums |
778ab097c5ed80997e55963b8577a6635a9c23f7d214c63e03a249f28070fc01
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.9.16 {"installer":{"name":"uv","version":"0.9.16","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":null,"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
|
Security for sspec 2.8.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.