Skip to main content
jido_action is the first package being used to refine Spec Led. This is not the simplest starter path. It is a deeper example that helps test how the method grows in a real package. It is a useful example because it is:
  • a stable package
  • a package with multiple module-level subjects
  • a package with substantial tests and docs
  • a package where public behavior matters more than hidden implementation detail

​
Package and module subjects

For jido_action, useful subjects include:
  • package
  • Jido.Action
  • Jido.Exec
  • Jido.Instruction
  • Jido.Plan
  • Jido.Action.Tool
These are better fits than generic user stories because they represent enduring parts of the package surface.

​
What the example proves

The jido_action example is testing whether Spec Led can:
  • describe package- and module-level intent cleanly
  • stay declarative without local helper code
  • remain useful to humans and agents
  • avoid turning into a second codebase

​
Lessons so far

  • authored gaps do not belong in the spec
  • approved deviations belong in exceptions
  • helper code should stay outside the package
  • verification should be declared, while findings should be derived