Spirefy Studio is one app built on the Spirefy framework, and its features are plugins. The framework is a desktop runtime for signed WebAssembly: it loads a plugin, sandboxes it, gives it typed host functions over WIT, draws its windows, and loads native code a plugin brings with it when you grant the capability. The same tools that build our plugins build yours.
The unified model is the core the rest of the app builds on, and it has one writer. Importing a format, authoring with the on-device AI, and syncing a live session are what change it, all built into the app, and each goes through one spirefy.cmd.v1 command path instead of touching the model in place. No other kind of plugin writes the model; they read it and render over it.
What you can build
- Exporters turn the model into files, such as documentation or a server project. See building exporters.
- Curation engines run rules over the model and report findings inside the API Workshop, like the Spectral engine.
- Pages and panels add UI to the app. The Studio pages are plugins themselves.
- Tools add utility capabilities, such as the local LLM chat panel.
Themes are not plugins. They are JSON files of CSS custom properties that the framework loads directly.
Build something that is not Studio
The framework does not know what Studio is. It loads signed WebAssembly, hands it typed host functions, draws its windows, and loads native code a plugin brings with it, with your consent. That is enough to build a desktop app that has nothing to do with APIs: a chat client with voice and video, an audio recorder, a save-file editor with its own windows. If it is a desktop app you want sandboxed, signed, and extensible, you build it on the same engine Studio runs on.
The CLI
The spirefy command-line tool scaffolds, builds, and packages plugins. It is the same tool we use internally.
spirefy init my-plugin --lang=zig # scaffold a project (zig, rust, go, or java)
cd my-plugin
spirefy build # compile to WebAssembly
spirefy pack # produce my-plugin-1.0.0.zp
spirefy generate --lang=<lang> reads your WIT files and emits typed bindings for Zig, Rust, Go, Java, or C, so the boundary is checked at compile time rather than at runtime.
How plugins fit together
Plugins do not call each other directly. Each one declares the interfaces it provides and the ones it needs in WIT, and the engine’s interface registry wires them together at load. Changes to the model always travel as a spirefy.cmd.v1 command batch through the one command path, never as an in-place edit. See core concepts for the model and the protocol.
Build with your own LLM
Writing a plugin pairs well with an AI assistant, and it does not have to be a paid one. We provide context prompts that give any model, local or hosted, the background it needs to understand a Spirefy plugin: the WIT interface, the exports, and the command-batch protocol. Feed the prompt to your model, describe what the plugin should do, and build the result with the CLI.