📝 Written ● Intermediate Updated 2026-05-13

Publish a plugin to a marketplace

Sharing a plugin by git URL works once. Publishing it to a marketplace makes "install the team's standard tooling" a single keystroke that anyone on your team can run, and that the next new hire runs on day one without asking.

Plugins are most useful when shared. The reason isn't grand — it's just that the same hook that's worth writing for yourself is worth writing for your team, and once it's worth writing for your team, the friction of "okay, clone this repo, run this command, copy this folder there" becomes the actual bottleneck. People who would happily install a polished plugin won't bother with one that requires five terminal steps to set up.

A marketplace is the directory layer that closes that gap. It's a small JSON manifest listing one or more plugins, hosted somewhere your team can reach. Once a user adds your marketplace (one command, one URL), every plugin in it becomes installable by short name. lingcode plugin install tdd instead of lingcode plugin install git+https://github.com/yourorg/lingcode-plugins/tree/main/tdd. The first form is the kind of thing teammates actually run.

The trade-off worth understanding: marketplaces are install-time snapshots. When a user runs marketplace add, LingCode reads the manifest as it was that moment. There's no auto-update flow — to refresh, you remove and re-add the marketplace. This is deliberate (auto-pulling plugin changes from a remote feed would be a security risk), but it shapes how you operate one.

What you'll learn

The marketplace.json schema
How to host the marketplace (and what hosting actually means)
The user-side marketplace add and plugin install flow
Why there's no update flow — and how to live with that
Versioning conventions for plugins inside a marketplace

Step 1: Author the marketplace manifest

One JSON file lists the plugins

Create marketplace.json at the root of your distribution location:

{
  "name": "acme",
  "description": "Internal LingCode plugins for the Acme engineering team.",
  "plugins": [
    {
      "name": "tdd",
      "description": "Acme's TDD workflow: write the failing test first.",
      "source": "git+https://github.com/acme/lingcode-plugins.git",
      "subpath": "tdd"
    },
    {
      "name": "deploy-staging",
      "description": "Deploy the current branch to Acme's staging environment.",
      "source": "git+https://github.com/acme/lingcode-plugins.git",
      "subpath": "deploy-staging"
    }
  ]
}

The schema is small: a marketplace has a name, a description, and a list of plugins. Each plugin entry has its own name, description, source (where to clone from), and subpath (folder within the source). LingCode uses the source+subpath to fetch the actual plugin when a user installs.

Step 2: Host the manifest

Anywhere it can be fetched

"Hosting" a marketplace is hosting one JSON file plus the plugin folders it points at. Two natural choices:

A git repo. Put marketplace.json at the root, plugins in subfolders, push to GitHub. Users add the marketplace by git URL; LingCode reads the manifest from the default branch.
A static file at a stable URL. Drop marketplace.json on a CDN or static host, point plugin source URLs at git URLs separately. Useful if you want the marketplace metadata decoupled from the plugin code.

For most teams the git-repo approach is simpler: one repository contains both the marketplace and all its plugins, and updating either is a normal commit. Make the repo private if the plugins reference internal things.

Step 3: User adds the marketplace

One command, one URL

Your teammates run, once:

lingcode plugin marketplace add https://github.com/acme/lingcode-plugins

LingCode reads the marketplace.json at that location, snapshots it into ~/.claude/marketplaces/acme/, and from then on knows every plugin the marketplace advertises.

Step 4: User installs plugins by short name

The payoff

With the marketplace registered, installing plugins is now:

lingcode plugin install tdd
lingcode plugin install deploy-staging

No URLs, no subpaths, no copying. LingCode looks up tdd across registered marketplaces, finds it in acme, fetches and installs. lingcode plugin search lists every available plugin if a user wants to browse.

For onboarding: add the marketplace add command to your team's "new developer setup" doc, alongside the steps for cloning the main repo. Two minutes, one command, every plugin the team uses is in scope.

Step 5: Live with the no-update model

Snapshots, not subscriptions

Once a user has added your marketplace, their snapshot is frozen. New plugins you add to the manifest don't appear in their plugin search output until they re-add the marketplace. This is the trade-off for security: auto-pulling plugin metadata from a remote feed would mean trusting that remote forever.

Two patterns that work well with this constraint:

Announce in chat or docs. When you add a new plugin, post a note: "new plugin available, run marketplace remove acme && marketplace add <url> to refresh." Most teams will do it.
Version your marketplace. Each plugin entry can carry a version field; users running lingcode plugin update <name> get the latest from the marketplace they have registered. They still don't see new plugins without re-adding, but they get newer versions of plugins they already have.

Step 6: Conventions worth adopting early

Three habits that compound

Versioning. Tag your marketplace repo with semver-style tags (v0.3.0) every time you change a plugin meaningfully. Even if no tooling consumes the tags, future-you reads them and orients.
Per-plugin README. Every plugin folder gets its own README explaining what it does, what it changes, and (for hooks) what it blocks. Users who installed without reading get a place to look back to.
A CHANGELOG. At the marketplace level. One line per change. Saves five re-investigations later.

Plugins with hooks trigger consent. When a user runs plugin install tdd, if the plugin contains hooks/hooks.json or executable scripts, LingCode prompts before installing. Your marketplace doesn't bypass that — and shouldn't. The consent prompt is part of the security model, not a UX wart.