Skip to main content
Spec 1.0: This page reflects the current stable portable core release.
Spec Led Development is language-agnostic. The tooling is not. That is an important distinction. The method should stay portable across languages. The commands and package names will vary by stack.

​
The method comes first

The core ideas do not depend on one runtime:
  • current truth in the repo
  • a small authored model
  • derived verification state
  • a repeatable drift check
What changes is the implementation that reads the workspace and runs the checks.

​
Elixir package

specled_ex is the current most complete implementation of the 1.0 portable core. Its command story is intentionally simple:
  • mix spec.prime for session-start context
  • mix spec.init, mix spec.next, and mix spec.check for the default local loop
  • mix spec.status and mix spec.decision.new when you need coverage or durable ADR support
  • mix spec.index and mix spec.validate as lower-level plumbing
This is the implementation with the deepest support for the current stable spec release. Today that also means specled_ex has the simplest beginner loop:
  1. run mix spec.prime --base HEAD when you enter the repo or hand work to an agent
  2. make the change and tighten the smallest proof
  3. run mix spec.next
  4. update the subject or ADR if needed
  5. run mix spec.check --base HEAD

​
TypeScript package

specled is the JavaScript and TypeScript implementation track. The goal is the same portable workspace and verification model for JS and TS repos. It is earlier in maturity than the Elixir package. That means the method is already language-agnostic, while the tooling maturity is still catching up across implementations.

​
CI support

The project also includes shared GitHub Actions support so repositories can run the same verification loop in CI that they run locally. That matters because Spec Led Development is not just a local authoring habit. It is supposed to create lasting back pressure when code changes without the matching intent and verification changes.

​
Project repos

If you want the actual project repos, start here:

​
If your stack is not fully supported yet

You can still adopt the method. The portable core is small enough that a repo can start with:
  • .spec/specs/*.spec.md
  • .spec/state.json
  • one local verification command
Then the implementation-specific tooling can catch up around that contract.

​
Choosing a path

If you are evaluating the project today:
  • use the Elixir package if you want the most complete current workflow
  • treat the TypeScript package as the matching implementation direction
  • keep the site-level method docs language-agnostic so the model stays portable
If you want the method first, start with the docs site. If you want implementation details, start with the package repo for your stack.