A catalog for reusable AI agent artifacts, with tools that translate those artifacts into harness-specific formats and help you share them with others.
Podium stores skills, agents, commands, rules, hooks, contexts, and MCP
server registrations as portable artifacts. A developer can keep a local
filesystem catalog and run podium sync to write harness-native files into
a workspace. A team can put the same artifacts behind a registry server for
runtime discovery, identity-aware visibility, audit, and shared governance.
In server mode, teams usually keep the catalog in one or more Git
repositories; the registry ingests those tracked refs and builds the
effective catalog it serves.
Documentation • Install • Hello world • Contributing
Status: 0.1.x, early release. The CLI, server, MCP bridge, and SDKs are all published, but the surface and behavior may still shift before 1.0. Open an issue or discussion for bug reports, missing use cases, or design feedback.
The Podium CLI ships three binaries (podium, podium-server, podium-mcp) on every supported platform. Pick whichever channel matches your setup.
macOS / Linux (Homebrew):
brew tap lennylabs/tap
brew install podiumWindows (Scoop):
scoop bucket add lennylabs https://github.com/lennylabs/scoop-bucket
scoop install podiumDirect binary download: grab podium-<os>-<arch> (or the .tar.gz / .zip bundle that includes all three binaries) from the latest release.
Container (for the registry server): docker pull ghcr.io/lennylabs/podium-server:latest.
SDKs for programmatic consumers:
pip install podium-sdk # Python; imports as `from podium import ...`
npm install @lennylabs/podium-sdk # TypeScriptFrom source (Go 1.26+ required):
git clone https://github.com/lennylabs/podium.git
cd podium && go build -o ~/.local/bin/podium ./cmd/podiumPodium can run from a filesystem catalog or from a registry server:
- Filesystem catalog: file-based artifacts plus the Podium CLI. This mode fits any team or individual whose catalog does not require access control or progressive disclosure: solo work, prototypes, CI, and Git-shared catalogs.
- Registry server: artifacts in one or more Git repositories, plus the Podium server, CLI, MCP server, and SDKs. Git stores catalog history and review flow; the registry ingests the configured refs and composes the effective catalog. This mode adds runtime discovery, identity-aware visibility, audit, and server-side composition.
Concepts Compare deployment setups
- Cross-harness delivery. Pluggable harness adapters translate canonical artifacts into Claude Code, Claude Desktop, Claude Cowork, Cursor, Codex, Gemini CLI, OpenCode, Pi, Hermes, or a custom runtime. The adapter roster with documentation links is in Configure your harness.
- Artifact organization based on domains and subdomains. Keep artifacts organized in folders and subfolders, where each folder defines a domain.
- Selective materialization. Sync a subset of the catalog into a workspace. Define profiles to quickly switch between scopes.
- Marketplace publishing. A
podium synctarget ofkind: marketplacerenders the catalog into harness-native git-repo distributions (the Claude, Codex, and Cursor plugin marketplaces, the Gemini extension, the Pi package, and the Hermes tap) and runs an operator-configured git workflow to push them. See Marketplace publishing. - Layered composition. Compose the catalog from multiple sources with deterministic merge and explicit precedence. (Requires the Podium registry server.)
- Per-layer visibility. Declare who can see what: each layer can be
public, organization-wide, scoped to OIDCgroups, or restricted to specificusers. (Requires the Podium registry server.) - Agent-driven progressive discovery. Discovery tools for traversing domains and searching artifacts. (Requires the Podium MCP server or SDK.)
- Lazy artifact loading. Materialize artifact files into the workspace as they are loaded. (Requires the Podium MCP server or SDK.)
Every capability is covered by the integration test suite.
The commands below describe the target v1 CLI flow.
After installing the podium CLI, create a skill directory with a
SKILL.md file for agent-facing instructions and an ARTIFACT.md file for
Podium metadata:
~/podium-artifacts/personal/hello/greet/SKILL.md
---
name: greet
description: Greet the user by name and tell them today's date.
---
Greet the user by their first name. Tell them today's date.~/podium-artifacts/personal/hello/greet/ARTIFACT.md
---
type: skill
version: 1.0.0
tags: [demo, hello-world]
---
<!-- Skill body lives in SKILL.md. -->Point Podium at the directory and set the harness:
cd workspace
podium init --registry ~/podium-artifacts/ --harness claude-code
podium syncOpen Claude Code in the project. Claude Code can discover the materialized skill in its native location.
Podium consists of:
- A registry: the catalog of artifacts. Backed either by a folder
on disk (filesystem mode) or by a Podium server (standalone or
standard mode). Built-in source types are
git(a remote Git repo at a tracked ref) andlocal(a filesystem path); theLayerSourceProviderSPI lets deployments add custom sources (S3 buckets, OCI registries, HTTP archives). - Consumers: built-in consumers are
podium sync, the MCP server, and the language SDKs.podium syncrenders a target as a workspace tree the harness reads directly or, for akind: marketplacetarget, as a harness-native git-repo distribution a harness imports. Custom consumers can build against the HTTP API directly.
In server mode, the server holds the catalog; consumers reach it over HTTP and identity-aware composition runs server-side:
In filesystem mode, the catalog is a folder. podium sync reads
it directly, with no server, HTTP, or auth, and writes harness-native
files to a project. The MCP server and language SDKs require a
server.
| Component | Role |
|---|---|
| Podium server | HTTP API; layer composition; visibility filtering; manifest indexing; hybrid retrieval; signing; audit. |
| MCP server | In-process bridge for MCP-speaking hosts. Exposes the discovery and load meta-tools. Requires a server. |
podium sync |
CLI (and library) that materializes the user's effective view to disk via the harness adapter. Either mode. |
| Language SDKs | Thin HTTP clients for programmatic runtimes (LangChain, Bedrock, custom orchestrators). Requires a server. |
Layer composition, visibility filtering, and harness adaptation run
through the same shared Go library regardless of mode: embedded
behind the server's HTTP API in server mode; invoked directly by
podium sync in filesystem mode. Migrating between modes is
mechanical and produces equivalent output for the same artifact
directory.
- Documentation site: organized by role (author / consume / deploy). Start with Getting Started for the quickstart, concepts, and architecture.
- Contributing, Governance, Security.
Building from source requires:
- Go 1.26 or later for the registry, CLI, and MCP server.
- Python 3.10 or later for the
podium-pySDK. - Node.js 20 or later for the
@lennylabs/podium-sdkTypeScript SDK.
Clone the repository, then:
go build ./... # Build every Go binary in the module.
make test # Run the full Go test suite.
make test-live # Run Tier 2 tests against real Postgres, S3,
# Sigstore, and embedding providers
# (configured via PODIUM_LIVE_* env vars).
make coverage # Run with -coverprofile and print a summary.
make help # List every make target.The SDK suites run independently:
cd sdks/podium-py
pip install -e .
pytest
cd sdks/podium-ts
npm install
npm testThe complete Go suite runs in about 10 seconds on a recent laptop.
The full development setup is in
docs/about/contributing.md.
Today's most useful contributions:
- Open issues or discussions: questions, missing use cases, bug reports.
- Run the test suite from source and report failures or environment-specific issues.
- Sketch a harness adapter: prototyping an adapter for a new harness helps validate the adapter SPI shape.
- Sketch a
LayerSourceProviderplugin: a custom source backend (S3, OCI, internal CMS) helps validate that SPI surface. - Fix typos and broken links: small documentation PRs are welcome any time.
See CONTRIBUTING.md and GOVERNANCE.md.