Publish an extension
Your extension stays in your repository. Listing it is a pointer to one commit in the official registry, opened as a pull request — not an upload, an account, or a build service.
On this page(4 sections)
What publishing is
intentic does not host extension code. A registry entry is your repository name and a full 40-character commit sha. When someone installs from the gallery or from Sandbox → Extensions → Discover, their sandbox clones that commit from your git host directly; nothing passes through intentic's servers.
Publishing and installing are free: no cut, no metering, no telemetry on extension use. Delisting removes only the pointer; your repo is unchanged.
Getting into the official gallery
Two entrances converge on one pull request against the official registry. There is nowhere to sign up.
- Add the topic. Put
intentic-extensionon your public GitHub repository, with anintentic-extension.jsonat its root (or at the path your manifest lives). A nightly job resolves your latest commit, checks the manifest and shipped bundle at that sha, and opens the pull request for you. That is the whole submission process when the extension lives at the repo root on GitHub. - Or open the pull request yourself. Required when the extension lives in a subdirectory, or when the source is on GitLab, Codeberg or Bitbucket rather than GitHub topic discovery — the same checks run on the exact source in that pull request.
Two independent automated reviewers read that source before merge: Trivy (dependencies, committed secrets, deployment configuration) and an intentic agent that inspects every executable surface without running author code. A finding or an unjudged audit keeps the pull request unmergeable. After merge, the extension appears in the gallery and in-app browse, installable in one click at the pinned sha.
Without the gallery
A registry is for discovery, not a gate. Anyone with your repo URL and a commit sha can install from Capabilities → Add → Extension or by pasting the URL on Sandbox → Extensions. A company can also point Discover at its own git repo that holds a .claude-plugin/marketplace.json — the same mechanism the app uses for alternate registries.
A workspace extension under .intentic/config/workspace-extensions/ runs without publishing at all; publishing is the step that makes the same code installable in other people's sandboxes at a pinned commit.
What installers see
The install dialog is your manifest rendered as plain English: one line per declared contribution, with the exact daemon routes spelled out underneath, at the commit they approve. The narrowest honest manifest makes for a short dialog; a broad declaration is long whether or not the code uses every route. Install & manage extensions is the whole experience from their side.
Related pages
- Install & manage extensions: discover, approve, update and turn extensions off once listed.
- Publish & registries: registry file format, source shapes, publisher slugs and the full diagram.
- Build an extension: author the manifest and bundle this page assumes you already have.
- Verification & trust: what listed, verified and blocked each claim on a card.