Packs: the extension a person installs
manifest.jsonname, release, domain, the embedded ontology's origin.claude-plugin/plugin.jsongenerated; depends on the engine pluginskills/start/starts a project from the installed copyontology/<name>/the ontology, and everything it extends, embeddedviews/the apps that show its graphA pack is the whole thing a person installs into Claude Code (model/packs.py, the plan in plans/packs.md): one ontology, the skills that know how to use it, the views that show its graph, and the plugin manifest Claude Code reads.
The ontology is embedded under ontology/<name>/ with every ontology it extends beside it, a copy with where it came from recorded, so a pack composes with nothing else on the machine and the engine can still say when the registry holds a newer release of it.
oto pack new <name> --ontology <name>scaffolds one under ~/.oto/packs/ (OTO_PACKS overrides); oto pack check validates the manifest, the embedded ontology, every view against its vocabulary, the skills and the plugin manifest, and runs the publishability scan; oto pack refresh re-embeds the ontology at its current release and regenerates the generated files.
The generated files are .claude-plugin/plugin.json, whose version is <release>.0.0 and which depends on the engine plugin oto, and the skill start, which tells an agent to run oto init --pack "${CLAUDE_PLUGIN_ROOT}": Claude Code substitutes the installed plugin's directory, so a project starts from a pack with nothing fetched.
oto init --pack <name|dir>installs the pack's ontology (its origin kept in the project's
record, and the pack named beside it, so oto status and oto ontology diff still work) and
copies its views under <project>/views/. A view by name is also found under the packs on this
machine.
A registry lists packs beside ontologies, under packs/<name> because a pack and its ontology usually share a name: oto pack list|show|add|update mirror the ontology verbs, and oto pack publish --to <registry> copies the pack in, bumps its release, regenerates the plugin files so the plugin version follows, updates the index and the marketplace, and tags <name>--v<release>.0.0, the convention Claude Code uses to resolve plugin versions.
The marketplace, .claude-plugin/marketplace.json, lists the engine plugin first, as a GitHub source from the engine the registry records, then every pack, so /plugin marketplace add <registry> then /plugin install <pack>@<registry> installs a pack and the engine with it, and a pack's dependency on oto resolves inside the same marketplace.
The catalogue (catalogue.py) is how a person browses before installing: oto registry site in a registry checkout writes a static site, one page for the registry with packs and ontologies grouped by domain, one page per pack (install lines, the classes with the question each answers and why it exists, the relations, the actions, the skills, the views, the guide, the changelog) and one per ontology.
A pack's page draws its sample graph with the explorer: a throwaway project is started from the pack, built, and exported as the explorer's static site under the page. The registry's site workflow, written with the check workflow when a registry is created, generates it on every push and publishes it with GitHub Pages; the site directory is ignored by git.