@khal-os/* SDK, wire them over NATS, and ship them into customer organisations through a release pipeline and catalog you’ll meet below.

A pack is the unit of everything
Every pack is the same three things — a frontend package, an optional Bun service, and a Helm chart — declared together inkhal-app.json and consumed by the shell at runtime. Some packs use only the frontend. Others wire up a full backend. A few bundle several frontends under one manifest.
- Frontend-only (pack-settings)
- Full-stack (pack-terminal)
- Bundle (pack-hello)
khal-app.json
backend block. Scaffolds UI only. Ships as a single npm package.The platform contracts
Every pack consumes a handful of platform contracts. You don’t build them — you call them.| Capability | Your surface |
|---|---|
| Auth | useKhalAuth() returns {userId, orgId, role, permissions, loading} |
| Window management | The shell launches, sizes, persists, and restores your pack’s windows |
| NATS | useNats() gives you a bridged client; subjects are scoped to your pack’s namespace |
| Services | useService() calls into your own backend service over NATS |
| Secrets and config | Declare env[] entries in khal-app.json; the platform injects values at install time |
| Multi-tenant isolation | Every pack runs inside its org’s boundary — permissions, data, NATS subjects |
Agents are peers
Every pack exposes the same SDK to agents and humans. An agent can open your pack, drive its UI, and call its services — no separate API surface.
Packs are composable
Packs can publish to NATS subjects other packs subscribe to. A notes pack that emits changes is readable by a search pack, a voice pack, a summarizer pack — without coordination.
The release pipeline
Fromgit push to a shipped artifact, the pipeline is the same for every pack:
PR to `dev` or `main`
ci.yml runs typecheck, lint, test, helm lint, and validates khal-app.json against the schema. All four gates must be green before merge.Merge to `main`
release.yml reads the version from package/package.json, tags v${VERSION}, and cuts a GitHub Release with auto-generated notes. This is the publish trigger.The catalog
Published packs are indexed by the platform’s catalog — the component that turns your OCI chart into a one-click install for customer admins. From the platform side:- Every pack is registered with its manifest, version, and permissions after publish.
- Customers browse the catalog per-organisation, see the packs they’re entitled to, and install them with one action.
- Cross-org distribution is the catalog’s problem, not the FDE’s. You publish; the catalog routes.
khal-app.json (accurate permissions, clear env[], real description) and your pack lands cleanly in every customer’s catalog. Nothing else is required.
See Customer install for the customer-side handoff contract — what you hand over after publish.
Where the automagik toolchain fits
Khal OS is where packs run. The automagik toolchain is how you build them faster:genie
Wishes in, PRs out — autonomous agent teams that scaffold and iterate on packs against the template.
omni
Omnichannel messaging. Agents inside your packs speak Slack, WhatsApp, Discord, email — one SDK.
rlmx
A research-grade reasoning loop for packs whose agents need to think before they act.
Next
Clone the workspace
Get the khal-os workspace onto your machine.
Your first pack
Scaffold, run, and ship a pack end-to-end.