ox addons
Browse, install, update, and remove add-ons for your team. An add-on installs into your Team Context, never into a single repository, so every repository on the team receives it and every AI coworker on the team sees the same selection.
What an add-on contains
An add-on is a versioned bundle of three things your team selects once:
| Part | What it gives an AI coworker |
|---|---|
| Skills | What to do, and when |
| Rules | Conventions to follow |
| Context | The reference material those skills carry with them |
Context here is not your Team Context, and not arbitrary documents. It is the material a specific skill needs in order to be worth following: the briefs, tables, examples, and source material that ship inside that skill, in its references/ and assets/. A document nothing points at is never opened, but material carried by a skill is found exactly when that skill is.
Usage
Subcommands
| Command | Description |
|---|---|
ox addons list | Show available add-ons and which ones this team has installed |
ox addons install <name> | Install an add-on into your Team Context |
ox addons update <name> | Update an installed add-on to the catalog's current version |
ox addons remove <name> | Remove an installed add-on from your Team Context |
Examples
Today every add-on comes from the catalog compiled into your ox binary. The list shows what this build ships and nothing else: not team-published skills (those come from ox skills publish) and not any remote source.
ox addons chooses what your team installs, and ox sync distributes it. Pass --version to name the exact version you expect. The catalog in your ox build holds one version of each add-on, so any other version fails.
Flags
| Flag | Subcommands | Description |
|---|---|---|
--version | install | Expect this exact version. The catalog holds one version of each add-on, so any other version fails |
--json | list, install, update, remove | Emit machine-readable JSON |
How versions and updates work
- Pinned. Add-on content stays pinned to an exact version and digest until someone runs
ox addons update. - Replaced, not merged. An update replaces every file the add-on owns and removes owned files its new version no longer ships. There is no merge and no conflict state.
- Reported, not prevented. Owned files are not yours to edit. If your team edited one, the ox CLI replaces or removes it anyway, then names it in a warning. It does not ask first. Commit Team Context edits before you run
ox addons updateorox addons remove, so that git history keeps them. - Collisions refused. The ox CLI never overwrites a file it does not own. It refuses a name that collides with something hand-authored rather than merging it.
Scripts stay off until you approve them
Add-on files are always written non-executable, and a provider cannot choose otherwise. Content that arrives with runnable scripts still needs ox skills approve <name> before an AI coworker may read it, and that command's --allow-scripts before anything becomes runnable. Installing an add-on grants neither.
What's next
- ox skills - Inspect your team's skills, publish your own, and approve runnable content
- ox sync - Sync Team Context, which distributes installed add-ons
- Team skills - How skills reach every coworker on the team
- Team Context - Where add-ons install