Skip to content

Ossature

Unstable - v0.x

Ossature is currently in its 0.x series and should be considered unstable. APIs, spec formats, CLI flags, and internal behavior may change significantly between releases without prior deprecation. Pin your version and check the changelog before upgrading.

An open-source build system that turns specs and architecture into working code.

You write a spec for what your software should do, optionally lay out the architecture for how it fits together, and Ossature turns that into a build plan that runs step by step, with an LLM generating the code under tight constraints. Your specs and architecture are the source, the generated code is the output.

This is not "throw a prompt at a model and hope for the best." You review the plan before anything gets built. When something breaks at step 14 of 30, you fix that step and keep going instead of starting over. When requirements change, you update the spec and Ossature figures out what needs to be regenerated.

How It Works

A project is a collection of spec files (.smd), optional architecture files (.amd), and optional verification files (.vmd) that hold test cases you write yourself. Ossature discovers them, builds a dependency graph, and processes them through three stages:

ossature validate → ossature audit → ossature build

Validate parses your specs and checks that everything is structurally sound. No LLM involved.

Audit sends your specs to an LLM for review, generates context files (briefs, interfaces) and a build plan. The plan is a TOML file you can read and edit before anything gets built.

Build executes the plan task by task, calling the LLM to generate code for each one. Each task produces a small number of files, gets verified, and if verification fails there's a fix loop that tries to repair it automatically. When a spec has a verification file, the plan also holds deterministic test tasks built from the cases you wrote, and the generated code has to pass them.

All state lives in a .ossature/ directory. Builds are incremental - if you change a spec, only the affected tasks get rebuilt. Interface files act as boundaries between specs, so an internal change to an upstream spec that leaves its public interface unchanged doesn't pull its downstream specs into a rebuild.

Next Steps