Step-by-step playbooks

Guides that get you from manifest to working tools

Start with the deploy walkthrough, then choose the artifact type or kit recipe that matches what you are building. Every example is designed to be copied, adapted and checked locally.

01 / path

Start here: deploy one release

A release begins in a Git repository with a v2 hubbound.json. The shortest safe path is: define the deployment, run the local preflight, then publish only after the dry run is clean.

  1. 1. Create the project manifest

    Run hubbound init, then add a deployment under deployments. Keep project dependencies under dependencies; they are install pins, not things deploy publishes.

  2. 2. Choose the artifact contract

    Pick MCP, SKILL, SUBAGENT, HOOK or RULE. Its content object tells HubBound how to apply the release to supported tools; its files patterns select the bundle.

  3. 3. Validate before mutation

    Run hubbound deploy --dry-run --json. This checks the manifest, Git provenance, paths, UTF-8 files and release limits without calling the release backend.

  4. 4. Publish and verify

    Authenticate, run deploy, save the JSON result, and distinguish a committed release from its later public-registry projection.

02 / artifacts

Artifact recipes

Artifacts are the smallest publishable unit. Their type changes the shape of content and the way providers materialize them locally; the release and file rules stay the same.

MCP

Connect a tool server

Define stdio or HTTP transport, environment references, secrets and tool permissions.

Read the MCP guide SKILL

Package a reusable skill

Ship an entrypoint such as SKILL.md plus supporting references, scripts or assets.

Read the skill guide SUBAGENT

Define a specialist agent

Point to an instruction file that supported tools can register as a subagent.

Read the subagent guide HOOK

Run automation on events

Connect a safe executable entrypoint to a provider-neutral trigger vocabulary.

Read the hook guide RULE

Publish instructions

Apply markdown always, to matching files, or through a smart trigger description.

Read the rule guide

03 / composition

Kit recipe

A kit is a versioned composition of artifacts. It does not contain a second copy of every blob: it names local artifact deployments and/or exact remote tag versions, then install resolves and applies the members.

KIT

Compose a team-ready bundle

Build a kit from local artifact deployments and pinned remote members, then publish the composition after its artifacts.

Read the kit guide

04 / model

The mental model

Keep these four layers separate while you work. Most deployment mistakes come from treating a dependency pin, a local package, and a public registry entry as the same thing.

01

hubbound.json

The source of truth for exact dependencies and named local deployments.

02

Preflight

The local safety gate for schema, Git provenance, paths, file type and size.

03

Release

The authenticated prepare/upload/commit flow that stores the immutable version.

04

Install

The consumer flow that resolves a version, downloads members and materializes provider files.