Package Catalog
The catalog is Hoziron's ecosystem of reusable components — competencies, skills, workflow templates, and collections packaged for distribution. Think of it as the layer that turns one team's work into building blocks everyone can use.
Packages follow semantic versioning, support cryptographic signatures, and resolve dependencies automatically. You can consume packages from the public Hoziron registry, host your own private registry behind your firewall, or use scoped packages to partition namespaces across multiple registries.
What you'll find here
| Guide | Description |
|---|---|
| Browsing and installing | Search the catalog, install packages, manage updates across your agents |
| Publishing packages | The full publish flow: init, build, lint, sign, and push to a registry |
| Private registries | Stand up your own registry, configure auth tokens, and use scoped packages |
| Collections | Group related packages into installable sets with the closure invariant |
Common tasks
- Find and install a competency → Browsing and installing § Search and install
- Update all packages to latest compatible versions → Browsing and installing § Updating
- Publish your first package → Publishing packages § Quick start
- Pin a package to your internal registry → Private registries § Scoped packages
- Create a curated starter kit for new agents → Collections § Defining a collection
- Understand the lockfile and reproducible installs → Browsing and installing § The lockfile
Key concepts
Semver resolution — Dependencies declare version constraints (^1.0, ~2.3, >=1.0, <3.0). The resolver picks the newest version satisfying all constraints across your dependency graph.
Scoped packages — The @scope/name syntax routes resolution to a specific registry, preventing name collisions between your internal packages and the public catalog.
Lockfile — packages.lock records exact resolved versions so every environment gets identical dependencies.
Package anatomy
Every package contains a MANIFEST.toml that declares its name, version, type, dependencies, and compatibility constraints. The manifest is what the resolver reads during installation — it's the contract between a package author and the catalog.
my-competency/
├── MANIFEST.toml # Name, version, dependencies, type
├── COMPETENCY.toml # (for competency packages) behavior definition
├── prompts/ # System prompts and templates
└── tools/ # Tool schemas
Related
- Competencies — the most common package type you'll install and publish
- Security § Authentication — registry auth tokens and key management
- Deployment § Air-gapped — offline package transfer for disconnected environments