Bundles
Bundles are versioned collections of text-based assets — prompts, configs, templates, agent definitions — that can be published as immutable snapshots and resolved by CLI runners. Think of a bundle as a package manager for workflow definitions: you author assets locally, publish a version, and any runner can resolve and download that exact set of files by slug and version string.
Design Goals
- Immutability — once a version is published, its contents never change. The manifest and every asset's SHA-256 hash are frozen at publish time.
- Determinism — given a slug and version, resolution always returns the same manifest. No draft states, no partial publishes, no mutable "latest" that silently changes.
- Integrity — every asset stores a SHA-256 hash computed on write. Consumers verify downloaded content against these hashes without trusting the transport layer.
Core Concepts
| Concept | Description |
|---|---|
| Bundle | A named container scoped to a namespace and identified by a unique slug. Holds assets and has a visibility setting (private, workspace, or public). |
| BundleAsset | A single text file within a bundle, identified by a logical path. Each asset has a type label, content body, and SHA-256 hash. |
| BundleVersion | An immutable published snapshot of a bundle's assets at a point in time. Contains the manifest JSON, optional OCI reference, and version string. |
Lifecycle at a Glance
Create Bundle ──▶ Manage Assets ──▶ Publish Version ──▶ Resolve ──▶ Download
│
▼
Yank Version- Create — define a bundle with a slug, name, and visibility.
- Manage assets — add, update, or remove text files within the bundle.
- Publish — freeze the current assets into an immutable version with a manifest.
- Resolve — look up a version by slug and version string to get the manifest.
- Download — fetch individual assets by ID and verify integrity via SHA-256.
- Yank — soft-withdraw a version from resolution while preserving the audit trail.