Skip to main content
Spec Led is meant to be portable. That means tools should read repo-local specs without forcing each project to copy large helper scripts.

​
Beta tool story

For beta, we want three tool surfaces:
  • a TypeScript client and CLI
  • an Elixir client
  • a reusable GitHub Action
This lets teams adopt the loop in CI without copying custom validation scripts into every repo.

​
What tools should do

Good first capabilities:
  1. find spec files
  2. parse structured blocks
  3. normalize them into a stable machine model
  4. validate the authored structure
  5. run verification targets
  6. emit human-readable and machine-readable results

​
Two verification layers

The mature form of the system has two layers:
  • governance verification
  • executable conformance
Starter tools can begin with the first layer and a small behavioral check. Larger systems can add stronger traceability and conformance over time.

​
Respect the authored boundary

Tools should treat these as authored:
  • subject metadata
  • requirements
  • scenarios
  • verification expectations
  • exceptions
Tools should derive these externally:
  • missing verification
  • drift
  • findings
  • reports
  • action plans
  • CI summaries

​
Keep adoption easy

The starter path should aim for:
  • one folder
  • one check command
  • one GitHub Action
Anything more advanced should come later through progressive disclosure.