In the last post I introduced Striatum, an OCI-native CLI for packaging and distributing AI skills. Near the end I wrote that prompt templates were next on the roadmap. That was the plan. What I did not expect was that building prompt support would surface a much bigger question: what happens when different kinds of artifacts need to depend on each other?
Striatum v0.3.0 answers that question. It ships two new artifact kinds (Prompts and Workflows), and the dependency model that already handled Skill-to-Skill dependencies now works across all three. If you are new to Striatum, the introductory post covers the basics: what it is, why OCI registries, how dependency resolution works. This post picks up from there.
Prompts as Artifacts
Skills often share reusable content. A severity rubric, a system prompt, a grading template. Today the pattern is to copy these files into each skill directory. Two skills that share the same rubric end up with two copies, and the copies drift.
Striatum v0.3.0 introduces "kind": "Prompt" to the artifact manifest. A Prompt is a versioned, packaged piece of content that lives in an OCI registry just like a Skill.
{
"apiVersion": "striatum.dev/v1alpha2",
"kind": "Prompt",
"metadata": {
"name": "severity-rubric",
"version": "1.0.0"
},
"spec": {
"entrypoint": "severity-rubric.md",
"files": ["severity-rubric.md"]
}
}
The workflow is the same as for Skills: scaffold, pack, push.
striatum init --name severity-rubric --kind Prompt --entrypoint severity-rubric.md
striatum pack
striatum push quay.io/myorg/prompts/severity-rubric:1.0.0
One deliberate design decision: Prompts are dependency-only. You never install a Prompt directly into an IDE. A Prompt reaches disk only when a Skill or Workflow declares it as a dependency, and Striatum resolves it transitively during installation. This keeps the model clean. Prompts are content that other artifacts consume, not standalone tools.
Workflows: Orchestrating Agents
Claude Code supports Workflows: JavaScript scripts that orchestrate multi-agent tasks using agent(), phase(), and pipeline(). A workflow script can fan out independent review passes, run adversarial verification, or pipeline items through multiple stages. These scripts live in ~/.claude/workflows/, but until now there was no way to version them, share them, or manage their dependencies.
Striatum v0.3.0 adds "kind": "Workflow". A Workflow artifact packages a workflow script as an OCI image with full dependency support.
{
"apiVersion": "striatum.dev/v1alpha2",
"kind": "Workflow",
"metadata": {
"name": "thorough-review",
"version": "1.0.0"
},
"spec": {
"entrypoint": "review.js",
"files": ["review.js"]
},
"dependencies": [
{
"source": "oci",
"registry": "quay.io",
"repository": "myorg/prompts/severity-rubric",
"tag": "1.0.0"
}
]
}
Notice the dependencies array. This Workflow declares a dependency on the severity-rubric Prompt from the previous section. During striatum pack, Striatum resolves that dependency, fetches the Prompt (from cache or registry), and bundles it as an extra OCI layer. During striatum install, the Prompt lands inside the Workflow’s directory.
striatum init --name thorough-review --kind Workflow --entrypoint review.js
striatum pack
striatum push quay.io/myorg/workflows/thorough-review:1.0.0
striatum install --target claude quay.io/myorg/workflows/thorough-review:1.0.0
After installation, the on-disk layout looks like this:
~/.claude/workflows/
thorough-review.js -> thorough-review/review.js
thorough-review/
review.js
deps/
severity-rubric/
severity-rubric.md
Striatum creates a symlink at the top level (thorough-review.js) pointing into the Workflow’s subdirectory so Claude discovers the entrypoint. The Prompt dependency is nested under deps/, available for the workflow script to reference at runtime. One command resolved the dependency graph, placed everything where Claude expects it, and wired up discovery.
Workflows only support --target claude (not Cursor). This is by design: Workflow scripts are a Claude Code feature.
The Dependency Model, Proven
When I shipped v0.1.0, the dependency model only had one configuration to prove: a Skill depending on another Skill. It worked, but it was a narrow test. The real question was whether the same model could handle artifacts of different kinds depending on each other.
With v0.3.0, that question is answered. A Workflow can depend on a Prompt. A Skill can depend on a Prompt. The resolution pipeline does not care about the kind of the dependency, only the source (OCI or Git), the reference, and the version. The same pack, push, pull, and install lifecycle applies to all three kinds. The same transitive resolution applies regardless of whether the dependency is a Skill, a Prompt, or a Workflow.
To support this cleanly, the cache is now kind-aware. Artifacts are stored under ~/.striatum/cache/Skill/, ~/.striatum/cache/Prompt/, or ~/.striatum/cache/Workflow/. This prevents collisions when a Skill and a Prompt share the same name (which is a reasonable scenario: a code-review Skill might depend on a code-review Prompt). The same separation motivated the new --kind flag on striatum uninstall, which disambiguates when multiple artifact kinds share a name.
Other Improvements
striatum inspect now supports both OCI and Git references. You can inspect an artifact’s manifest without pulling any layers, which is useful for checking metadata, version, and dependencies before committing to an install.
striatum inspect quay.io/myorg/workflows/thorough-review:1.0.0
striatum inspect git:https://github.com/example/skill.git@v1.0.0
This release also includes stronger validation for digest formats, commit SHAs, and path traversal protection.
Three Kinds, One Model
The first post argued that distribution is a feature. v0.3.0 takes that further: composability is a feature. Skills, Prompts, and Workflows are different things with different purposes, but they share a single packaging model, a single dependency resolution pipeline, and the same OCI registries your organization already runs. That is the bet Striatum is making: the same infrastructure that distributes your container images can distribute your entire AI toolchain.
Try it out: v0.3.0 release | GitHub | brew install hbelmiro/striatum/striatum