Biomes
A biome is the Xema unit of distribution. One biome can ship agents, skills, tools, workflows, deliverable specs, document templates, mount sources, artifact types, connector bindings, frontend slot contributions, optional backend services, and storage schemas — all governed by a single declarative manifest and a fully-specified lifecycle.
Quick Links
| Page | What it covers |
|---|---|
| Concepts | BiomeLifecycle state machine, manifest anatomy, capability model |
| Authoring | Writing xema-biome.json, contribution kinds, testing locally |
| Store | Publishing to the Xema Store; OCI packaging; versioning |
| Manifest Reference | Field-by-field xema-biome.json reference, generated from the platform schema |
| Examples | Runnable worked examples |
Getting Started
Read in order:
- Concepts — understand the lifecycle and manifest before writing code.
- Authoring — write and validate your first biome.
- Store — package and publish when ready.
- Examples — see a minimal working biome from scratch.
Keep the Manifest Reference open while authoring — it is generated from the platform manifest schema, so it always matches what the biome host validates.
FAQ
Q: Can a biome ship a backend service?
A: Yes. Put the service under api/<name>/ and declare it in xema.ships.apis[]. The service is deployed by the biome host when the biome is org-installed and removed when it is archived.
Q: How does a biome get capabilities?
A: The biome declares requiresCapabilities[] in the manifest. At install time, an org admin reviews and approves a permission digest; the resulting grant is what the runtime checks. The biome never short-circuits that gate.