Claude Skill

build-plugin

Bundle skills, hooks, agents, or an MCP server into one installable Claude Code plugin and ship it. Use when asked to bundle tools into one plugin, package tools for a colleague, publish a plugin to a marketplace, share my tools with my team, or ship a plugin. Asks who it's for a

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download techwolf-ai-ai-first-toolkit-plugins_tool-build-kit_skills_build-plugin-2ee7841.zip · 8 KB
techwolf-ai/ai-first-toolkit 129 5 forks MIT Updated 2d ago
Part of techwolf-ai/ai-first-toolkit — 20 skills

Install

skills CLI npx skills add https://github.com/techwolf-ai/ai-first-toolkit/tree/main/plugins/tool-build-kit/skills/build-plugin
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install techwolf-ai-ai-first-toolkit@llmmart
Git git clone https://github.com/techwolf-ai/ai-first-toolkit.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole techwolf-ai/ai-first-toolkit collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Build Plugin

Bundle many tools (skills, hooks, agents, MCP servers) into one installable Claude Code plugin and distribute it. The defining move of this skill: establish who the plugin is for and where it will live with AskUserQuestion before assembling anything, then tailor every phase to that answer. A personal one-project bundle and a public team marketplace share almost nothing past "assemble", so branch early and commit to the branch.

How this relates to build-mcp

build-mcp builds one MCP server: analyze a service, implement the tools, deploy, scale. build-plugin bundles many tools (including MCP servers produced by build-mcp) into a single shareable unit and distributes it. When build-mcp reaches its Distribute phase for a team or public audience, it hands off here: packaging into a plugin and listing it on a marketplace is this skill's job. Use build-mcp to make a server, then build-plugin to ship it alongside your skills, hooks, and agents.

The four phases

  1. Analyze: decide what tools go in the bundle, and name it.
  2. Assemble: build the plugin folder and manifest, test it locally with claude --plugin-dir.
  3. Ship: put it on a marketplace repo, on the right git host, public or private, with one-click enablement for a team.
  4. Maintain: versions, updates, ownership, and admin controls.

Run them in order. The AskUserQuestion answers from Phase 0 gate Ship and Maintain.

Phase 0: Establish context (AskUserQuestion, do this first)

Before assembling anything, branch on the user's context. Ask the audience question first; it is the headline decision and it cascades into everything downstream. Then ask the git host only if it is still ambiguous. Ask one question at a time.

Question 1 (always, ask first): Audience:

Use AskUserQuestion:

  • header: "Audience"
  • question: "Who is this plugin for? This decides where it's hosted and how it's shared."
  • options:
    1. "Just me": personal bundle of my own tools, one machine or a couple of projects.
    2. "My team / org": shared internally, installed by colleagues.
    3. "Public / external": published openly for anyone to install.

Question 2 (conditional, skip for "Just me"): Git host:

Skip entirely for "Just me" (no remote needed). Ask for team or public:

  • header: "Git host"
  • question: "Where will the marketplace repo live?"
  • options:
    1. "GitHub": unlocks the owner/repo shorthand and Anthropic's public directory.
    2. "GitLab or other git host": works via the full https://...git URL, no GitHub mirror needed.
    3. "Not sure yet": decide during Ship; GitHub is the smoothest default.

Confirm the resolved tuple back to the user in one line before proceeding (e.g. "Bundling a team plugin of three skills plus one MCP server, hosted on a private GitHub marketplace repo"). That tuple drives the branch table below.

Branch table (the spine of this skill)

Phase Just me Team/org (GitHub) Team/org (GitLab/other) Public
Ship N/A, no marketplace. Load via claude --plugin-dir, or scaffold it in your skills dir (claude plugin init) to auto-load every session. Marketplace repo on GitHub; entry source: {source:"github", repo:"org/repo"} or a relative "./path". Private repo optional to keep it internal. Marketplace repo on GitLab/Bitbucket/self-hosted; entry source: {source:"url", url:"https://...git"}. Public marketplace repo; entry by host as above. Be deliberate: anyone who knows the repo can install, and plugins run arbitrary code.
Enable N/A, stop here. It is already loaded on your machine. /plugin marketplace add org/repo then /plugin install name@marketplace; or auto-enable for the team via project .claude/settings.json. /plugin marketplace add https://gitlab.com/team/plugins.git then /plugin install name@marketplace; same .claude/settings.json auto-enable. Same commands; owner/repo shorthand is GitHub-only, others use the full URL.
Maintain Bump version in plugin.json for a clean update boundary; you are the only user. /plugin marketplace update; one maintainer per plugin; fixes land via merge request. Org-wide enforcement via managed settings. Same, via the GitLab/other merge-request flow. Same, plus a public changelog and a clear versioning policy.

If a cell says "N/A, stop here" for the chosen branch, say so explicitly and move on. Do not pad it. The Enable row is the team-facing half of Ship (turning the marketplace on for colleagues), not a separate phase.

Reference files:

  • references/assemble.md: plugin folder layout, the manifest fields, moving existing ~/.claude/ tools in, local claude --plugin-dir testing, skill namespacing, claude plugin validate.
  • references/marketplace.md: the marketplace.json shape, per-host source types, add and install commands, public vs private and auth.
  • references/team-enablement.md: project .claude/settings.json auto-enable, org-wide managed-settings enforcement.
  • references/maintain.md: updates, version bumps, ownership, fixes via merge request.

Load only the references the current branch and phase need. Progressive disclosure.

Phase 1: Analyze

Decide what goes in the bundle before you build the folder.

  1. Inventory the tools. List every skill, hook, agent, and MCP server the plugin should carry. A plugin can hold any mix; each type sits in its own place in the layout (see assemble.md).
  2. Draw the boundary. One plugin is one coherent unit that updates together. If two groups of tools serve different audiences or version on different clocks, that is two plugins.
  3. Name it. Kebab-case, distinct, describes the bundle not one tool inside it. The name becomes the skill namespace (/my-plugin:skill) and the marketplace entry key.
  4. Note what already exists loose. Tools sitting in ~/.claude/skills, ~/.claude/agents, or a personal settings.json will move into the plugin and the loose originals get deleted, so you do not run duplicates (assemble.md covers this).

Deliverable: the plugin name plus a list of what it will contain. Confirm with the user before assembling.

Phase 2: Assemble

Read references/assemble.md. Build the folder to the layout, write the manifest, then test locally.

  1. Create the plugin dir. Only plugin.json goes inside .claude-plugin/; skills/, agents/, hooks/hooks.json, and .mcp.json sit at the plugin ROOT.
  2. Write .claude-plugin/plugin.json with name, description, version, author.
  3. Move the inventoried tools in and delete the loose originals.
  4. Validate, then load-test. claude plugin validate . checks the manifest and layout with no login. claude plugin details <name> lists the skills, hooks, and servers it discovered, also login-free. claude --plugin-dir ./my-plugin (it also accepts a .zip) loads it into a live session so you can invoke a tool; that one needs you logged in.

For a "Just me" bundle this is the last substantive phase: it is loaded, it works, stop.

Phase 3: Ship

Only for team or public. Read references/marketplace.md, and references/team-enablement.md for the auto-enable path. Branch on the git-host answer.

  1. Create the marketplace repo, or reuse an existing one. Add .claude-plugin/marketplace.json at its root with name, owner, and a plugins[] entry for this plugin.
  2. Set the entry source by host: relative "./path" if the plugin lives in the same repo, {source:"github", repo:"owner/repo"} for GitHub, or {source:"url", url:"https://...git"} for GitLab, Bitbucket, or self-hosted. There is no gitlab source type.
  3. Choose public vs private to match the audience. A private repo keeps a team plugin internal; a public repo is installable by anyone who knows it, running arbitrary code with the user's privileges, so make that choice deliberately.
  4. Confirm the install path a colleague runs: /plugin marketplace add owner/repo (GitHub shorthand) or the full https://...git URL for any other host, then /plugin install name@marketplace.

Phase 4: Maintain

Read references/maintain.md. Branch lightly; the mechanics are the same across hosts.

  1. Updates. Users pull new versions with /plugin marketplace update or at startup.
  2. Version boundary. Bump version in plugin.json so users get a clean update boundary; omit it and Claude Code treats every commit SHA as a new version.
  3. Ownership. One maintainer per plugin. Fixes land via merge request, since the source is a git repo.
  4. Org controls (team/public, admin job). Force-install, an allowlist (strictKnownMarketplaces), or a denylist (blockedMarketplaces) live in a managed-settings file, set by an admin, not per user (team-enablement.md).

Done criteria

  • The plugin validates (claude plugin validate) and its tools show up (claude plugin details); loading it via claude --plugin-dir in a session invokes at least one.
  • It is on a marketplace repo the resolved audience can reach, public or private matching that audience (or, for "Just me", it is loaded locally and there is no marketplace).
  • The user can name exactly how a colleague installs it, two-command or one-click, matching the audience answer.
Files (ai-first-toolkit)
  • references
    • assemble.md 3 KB 
      # Assemble: folder, manifest, local test

Build the plugin folder, write its manifest, move your loose tools in, and test it before shipping anything.

## Folder layout

Only `plugin.json` lives inside `.claude-plugin/`. Everything else sits at the plugin ROOT:

```
my-plugin/
  .claude-plugin/
    plugin.json          # the manifest, the ONLY thing inside .claude-plugin/
  skills/
    my-skill/
      SKILL.md
  agents/
    my-agent.md
  hooks/
    hooks.json
  .mcp.json              # MCP servers this plugin ships
  README.md
```

`skills/`, `agents/`, `hooks/hooks.json`, and `.mcp.json` are auto-discovered at the plugin root. A plugin can carry any mix of these; none is required.

## The manifest

`.claude-plugin/plugin.json`:

```json
{
  "name": "my-plugin",
  "description": "One line on what the bundle does.",
  "version": "0.1.0",
  "author": { "name": "Your Name" }
}
```

`name` (kebab-case) and `description` are the essentials; `version` (semver) gives users a clean update boundary; `author` is an object with `name`. Keep `name`/`description` in sync with any marketplace entry that points at this plugin, but do not repeat `version` there: `plugin.json` always wins, so a stale marketplace version is silently ignored (see maintain.md).

To ship MCP servers, add a `.mcp.json` at the plugin root (auto-discovered) or point `plugin.json` at one with an `mcpServers` key. Use `${CLAUDE_PLUGIN_ROOT}` for any bundled paths, since marketplace plugins are copied into `~/.claude/plugins/cache`.

## Move existing tools in, delete the originals

Tools you already run loose from `~/.claude/` (a skill in `~/.claude/skills`, an agent in `~/.claude/agents`, hooks in your personal `settings.json`) should move INTO the plugin folder. Then delete the loose originals, otherwise the tool loads twice and you run duplicates. After moving, the plugin is the single source for those tools.

## Scaffold and validate

- `claude plugin init <name>` scaffolds a new plugin skeleton INTO your skills directory (`~/.claude/skills/<name>/`), not the current folder. A plugin living there auto-loads every session as `<name>@skills-dir`, no `--plugin-dir` flag needed, which is the smoothest path for a personal ("Just me") bundle.
- `claude plugin validate .` (or `claude plugin validate ./my-plugin`) checks the manifest and layout. It needs no login.

## Local test

```bash
claude --plugin-dir ./my-plugin
```

Loads the plugin straight from disk, no marketplace needed. It also accepts a `.zip` of the plugin. In the session, confirm every bundled tool shows up and invoke at least one. Skills are namespaced by plugin: a skill named `my-skill` in plugin `my-plugin` is invoked as `/my-plugin:my-skill`.

`claude --plugin-dir` opens an interactive session, so it needs you logged in. For a quick login-free check that the plugin is well-formed and its tools are discovered, use `claude plugin validate ./my-plugin` and `claude plugin details my-plugin`.

This local path is the whole story for a "Just me" bundle: assemble, load, verify, stop.
    • maintain.md 1.5 KB 
      # Maintain: updates, versions, ownership

Once a plugin is shipped, keep it updatable and owned.

## Updates

Users pull new versions with `/plugin marketplace update`, or Claude Code checks at startup. There is nothing to redeploy on your side beyond pushing to the marketplace repo.

## Version boundary

Set `version` (semver) in `plugin.json`. Users only get an update when you bump it, so a version bump is a clean, intentional update boundary. Omit `version` everywhere and Claude Code falls back to the git commit SHA, treating every commit as a new version, which is noisier than you usually want. Claude Code resolves the version from `plugin.json` first, then the marketplace entry, then the commit SHA, so do not set `version` in both places: `plugin.json` always wins, and a stale one there silently masks the value in the marketplace entry.

## Ownership

One maintainer per plugin. Because the source is a git repo, fixes and new tools land the normal way: a merge request against the marketplace repo, reviewed and merged, then a version bump. Contributors do not need any special plugin tooling, just the git host's PR/MR flow.

## Admin controls (team/org)

Org-wide update and install policy (force-install, allowlist, denylist) lives in a managed-settings file set by an administrator, not per user. See `team-enablement.md`. Keep the maintainer role and the admin role distinct: the maintainer ships versions, the admin decides which marketplaces and plugins are allowed on managed machines.
    • marketplace.md 3 KB 
      # Marketplace: list, host, install

A marketplace is a git repo with a `marketplace.json` that lists one or more plugins. Colleagues add the marketplace once, then install plugins from it.

> For the plugin-packaging and marketplace mechanics shared with build-mcp, see `../../build-mcp/references/distribute-marketplace.md`. This file stays self-contained; that one goes deeper on shipping an MCP server specifically.

## The manifest

`.claude-plugin/marketplace.json` at the marketplace repo root:

```json
{
  "name": "company-tools",
  "owner": { "name": "DevTools Team", "email": "devtools@example.com" },
  "description": "Internal DevTools plugins.",
  "plugins": [
    {
      "name": "my-plugin",
      "source": "./plugins/my-plugin",
      "description": "What the bundle does."
    }
  ]
}
```

Required: top-level `name` (kebab-case), `owner.name`, and a `plugins[]` array. Each entry needs at least `name`, `source`, and `description`. Add a top-level `description` too: without it `claude plugin validate` warns `No marketplace description provided`.

## Source by git host

The `source` field tells Claude Code where the plugin lives:

- **Same repo**: a relative path string, `"./plugins/my-plugin"`.
- **GitHub**: `{ "source": "github", "repo": "owner/repo" }`.
- **GitLab, Bitbucket, self-hosted**: `{ "source": "url", "url": "https://gitlab.com/team/plugins.git" }`. There is NO `gitlab` source type; the generic `url` source covers every non-GitHub host.
- **A subdirectory of a monorepo**: `{ "source": "git-subdir", "url": "https://...git", "path": "plugins/my-plugin" }`, which sparse-clones just that path. Handy when many plugins live in one repo.

## Add and install

Run these at your terminal as `claude plugin ...`, or inside a Claude Code session as the `/plugin ...` slash form. The terminal form:

```bash
# GitHub: owner/repo shorthand works
claude plugin marketplace add owner/repo

# Any other host: full .git URL
claude plugin marketplace add https://gitlab.com/team/plugins.git

# then install a plugin from the added marketplace
claude plugin install my-plugin@company-tools
```

In a session the same commands are `/plugin marketplace add ...` and `/plugin install ...`. The `owner/repo` shorthand is GitHub-only. Every other host uses the full `https://...git` URL. Anthropic's public plugin directory is likewise a GitHub-only convenience; a GitLab marketplace works directly, no GitHub mirror needed.

## Public vs private, and auth

- A **private** repo keeps a team plugin internal. Public GitHub repos work for team enablement just as well; a private repo is an option for keeping tools internal, not a requirement.
- **Manual** `/plugin` use rides your existing git credential helper, so a private repo just works if you can already clone it.
- **Background auto-updates** read `GITHUB_TOKEN` or `GITLAB_TOKEN` from the environment for private repos.
- Making a marketplace **public** is a real decision: anyone who knows the repo can add and install from it, and plugins run arbitrary code with the user's privileges. Do it deliberately.
    • team-enablement.md 1.5 KB 
      # Team enablement: one-click and org-wide

Two levers past a plain marketplace: a project-level auto-enable that prompts teammates on trust, and an org-wide managed-settings enforcement that an admin controls.

## Project auto-enable (one-click for teammates)

Commit a `.claude/settings.json` to the project repo. Anyone who trusts the folder gets a one-click prompt to install the listed plugins.

```json
{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": { "source": "github", "repo": "org/plugins-repo" }
    }
  },
  "enabledPlugins": {
    "my-plugin@company-tools": true
  }
}
```

- `extraKnownMarketplaces` is an object keyed by marketplace name; the value is `{ "source": { ... } }` using the same source shapes as a marketplace entry (`github` repo, or `url` for GitLab/other).
- `enabledPlugins` is an object keyed by `"plugin@marketplace"` with a boolean value.
- On trusting the folder, teammates are prompted to install; they do not run the `/plugin` commands by hand.

## Org-wide enforcement (admin job)

For a whole org, an admin uses a managed-settings file (system-level, not per-user) to enforce policy:

- **Force-install**: push plugins to every user automatically.
- **`strictKnownMarketplaces`**: an allowlist; only these marketplaces may be added.
- **`blockedMarketplaces`**: a denylist of marketplaces users may not add.

This is an administrator action on managed machines, not something an individual sets. Flag it as such when the audience is a large org.
  • SKILL.md 9.6 KB 
    ---
name: build-plugin
description: "Bundle skills, hooks, agents, or an MCP server into one installable Claude Code plugin and ship it. Use when asked to bundle tools into one plugin, package tools for a colleague, publish a plugin to a marketplace, share my tools with my team, or ship a plugin. Asks who it's for and where it's hosted, then walks analyze, assemble, ship, and maintain, tailored to that answer. Sibling to build-mcp."
---

# Build Plugin

Bundle many tools (skills, hooks, agents, MCP servers) into one installable Claude Code plugin and distribute it. The defining move of this skill: establish who the plugin is for and where it will live with `AskUserQuestion` before assembling anything, then tailor every phase to that answer. A personal one-project bundle and a public team marketplace share almost nothing past "assemble", so branch early and commit to the branch.

## How this relates to build-mcp

`build-mcp` builds one MCP server: analyze a service, implement the tools, deploy, scale. `build-plugin` bundles many tools (including MCP servers produced by `build-mcp`) into a single shareable unit and distributes it. When `build-mcp` reaches its Distribute phase for a team or public audience, it hands off here: packaging into a plugin and listing it on a marketplace is this skill's job. Use `build-mcp` to make a server, then `build-plugin` to ship it alongside your skills, hooks, and agents.

## The four phases

1. **Analyze**: decide what tools go in the bundle, and name it.
2. **Assemble**: build the plugin folder and manifest, test it locally with `claude --plugin-dir`.
3. **Ship**: put it on a marketplace repo, on the right git host, public or private, with one-click enablement for a team.
4. **Maintain**: versions, updates, ownership, and admin controls.

Run them in order. The `AskUserQuestion` answers from Phase 0 gate Ship and Maintain.

## Phase 0: Establish context (AskUserQuestion, do this first)

Before assembling anything, branch on the user's context. Ask the **audience** question first; it is the headline decision and it cascades into everything downstream. Then ask the git host only if it is still ambiguous. Ask one question at a time.

**Question 1 (always, ask first): Audience:**

Use `AskUserQuestion`:
- header: "Audience"
- question: "Who is this plugin for? This decides where it's hosted and how it's shared."
- options:
  1. "Just me": personal bundle of my own tools, one machine or a couple of projects.
  2. "My team / org": shared internally, installed by colleagues.
  3. "Public / external": published openly for anyone to install.

**Question 2 (conditional, skip for "Just me"): Git host:**

Skip entirely for "Just me" (no remote needed). Ask for team or public:
- header: "Git host"
- question: "Where will the marketplace repo live?"
- options:
  1. "GitHub": unlocks the `owner/repo` shorthand and Anthropic's public directory.
  2. "GitLab or other git host": works via the full `https://...git` URL, no GitHub mirror needed.
  3. "Not sure yet": decide during Ship; GitHub is the smoothest default.

Confirm the resolved tuple back to the user in one line before proceeding (e.g. "Bundling a team plugin of three skills plus one MCP server, hosted on a private GitHub marketplace repo"). That tuple drives the branch table below.

## Branch table (the spine of this skill)

| Phase | Just me | Team/org (GitHub) | Team/org (GitLab/other) | Public |
|-------|---------|-------------------|-------------------------|--------|
| **Ship** | N/A, no marketplace. Load via `claude --plugin-dir`, or scaffold it in your skills dir (`claude plugin init`) to auto-load every session. | Marketplace repo on GitHub; entry `source: {source:"github", repo:"org/repo"}` or a relative `"./path"`. Private repo optional to keep it internal. | Marketplace repo on GitLab/Bitbucket/self-hosted; entry `source: {source:"url", url:"https://...git"}`. | Public marketplace repo; entry by host as above. Be deliberate: anyone who knows the repo can install, and plugins run arbitrary code. |
| **Enable** | N/A, stop here. It is already loaded on your machine. | `/plugin marketplace add org/repo` then `/plugin install name@marketplace`; or auto-enable for the team via project `.claude/settings.json`. | `/plugin marketplace add https://gitlab.com/team/plugins.git` then `/plugin install name@marketplace`; same `.claude/settings.json` auto-enable. | Same commands; `owner/repo` shorthand is GitHub-only, others use the full URL. |
| **Maintain** | Bump `version` in `plugin.json` for a clean update boundary; you are the only user. | `/plugin marketplace update`; one maintainer per plugin; fixes land via merge request. Org-wide enforcement via managed settings. | Same, via the GitLab/other merge-request flow. | Same, plus a public changelog and a clear versioning policy. |

If a cell says "N/A, stop here" for the chosen branch, say so explicitly and move on. Do not pad it. The **Enable** row is the team-facing half of Ship (turning the marketplace on for colleagues), not a separate phase.

Reference files:
- **references/assemble.md**: plugin folder layout, the manifest fields, moving existing `~/.claude/` tools in, local `claude --plugin-dir` testing, skill namespacing, `claude plugin validate`.
- **references/marketplace.md**: the `marketplace.json` shape, per-host `source` types, add and install commands, public vs private and auth.
- **references/team-enablement.md**: project `.claude/settings.json` auto-enable, org-wide managed-settings enforcement.
- **references/maintain.md**: updates, version bumps, ownership, fixes via merge request.

Load only the references the current branch and phase need. Progressive disclosure.

## Phase 1: Analyze

Decide what goes in the bundle before you build the folder.

1. **Inventory the tools.** List every skill, hook, agent, and MCP server the plugin should carry. A plugin can hold any mix; each type sits in its own place in the layout (see assemble.md).
2. **Draw the boundary.** One plugin is one coherent unit that updates together. If two groups of tools serve different audiences or version on different clocks, that is two plugins.
3. **Name it.** Kebab-case, distinct, describes the bundle not one tool inside it. The name becomes the skill namespace (`/my-plugin:skill`) and the marketplace entry key.
4. **Note what already exists loose.** Tools sitting in `~/.claude/skills`, `~/.claude/agents`, or a personal `settings.json` will move into the plugin and the loose originals get deleted, so you do not run duplicates (assemble.md covers this).

Deliverable: the plugin name plus a list of what it will contain. Confirm with the user before assembling.

## Phase 2: Assemble

Read **references/assemble.md**. Build the folder to the layout, write the manifest, then test locally.

1. Create the plugin dir. Only `plugin.json` goes inside `.claude-plugin/`; `skills/`, `agents/`, `hooks/hooks.json`, and `.mcp.json` sit at the plugin ROOT.
2. Write `.claude-plugin/plugin.json` with `name`, `description`, `version`, `author`.
3. Move the inventoried tools in and delete the loose originals.
4. Validate, then load-test. `claude plugin validate .` checks the manifest and layout with no login. `claude plugin details <name>` lists the skills, hooks, and servers it discovered, also login-free. `claude --plugin-dir ./my-plugin` (it also accepts a `.zip`) loads it into a live session so you can invoke a tool; that one needs you logged in.

For a "Just me" bundle this is the last substantive phase: it is loaded, it works, stop.

## Phase 3: Ship

Only for team or public. Read **references/marketplace.md**, and **references/team-enablement.md** for the auto-enable path. Branch on the git-host answer.

1. Create the marketplace repo, or reuse an existing one. Add `.claude-plugin/marketplace.json` at its root with `name`, `owner`, and a `plugins[]` entry for this plugin.
2. Set the entry `source` by host: relative `"./path"` if the plugin lives in the same repo, `{source:"github", repo:"owner/repo"}` for GitHub, or `{source:"url", url:"https://...git"}` for GitLab, Bitbucket, or self-hosted. There is no `gitlab` source type.
3. Choose public vs private to match the audience. A private repo keeps a team plugin internal; a public repo is installable by anyone who knows it, running arbitrary code with the user's privileges, so make that choice deliberately.
4. Confirm the install path a colleague runs: `/plugin marketplace add owner/repo` (GitHub shorthand) or the full `https://...git` URL for any other host, then `/plugin install name@marketplace`.

## Phase 4: Maintain

Read **references/maintain.md**. Branch lightly; the mechanics are the same across hosts.

1. **Updates.** Users pull new versions with `/plugin marketplace update` or at startup.
2. **Version boundary.** Bump `version` in `plugin.json` so users get a clean update boundary; omit it and Claude Code treats every commit SHA as a new version.
3. **Ownership.** One maintainer per plugin. Fixes land via merge request, since the source is a git repo.
4. **Org controls (team/public, admin job).** Force-install, an allowlist (`strictKnownMarketplaces`), or a denylist (`blockedMarketplaces`) live in a managed-settings file, set by an admin, not per user (team-enablement.md).

## Done criteria

- The plugin validates (`claude plugin validate`) and its tools show up (`claude plugin details`); loading it via `claude --plugin-dir` in a session invokes at least one.
- It is on a marketplace repo the resolved audience can reach, public or private matching that audience (or, for "Just me", it is loaded locally and there is no marketplace).
- The user can name exactly how a colleague installs it, two-command or one-click, matching the audience answer.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude