0d82eac145
* bump: switch to per-entry PR mode (one PR per stale plugin) Replaces the single batched bump PR with one PR per stale plugin so a single failing plugin no longer blocks the rest. Pins to a feature branch of the bump-plugin-shas action that adds 'pr-mode: per-entry'; re-pin to the merge commit on the action's main when that lands. - pr-mode: per-entry → one PR per plugin on bump/<slug> - max_bumps default lowered 130 → 30 (per-entry scans cost more) - scan dispatch fanned out over pr-urls JSON (one per per-entry branch) - header comments updated for per-entry semantics * bump: re-pin to merged composite action SHA on -community main The pr-mode: per-entry input now lives on main of the bump-plugin-shas action (merged at e2019b2a). Update the pin and drop the now-stale header comment that tracked the feature branch. * bump: dispatch all three required checks per per-entry PR Bump PRs are opened with GITHUB_TOKEN, which doesn't fire on:pull_request (recursion guard). The per-entry cutover already dispatched scan-plugins.yml per branch to satisfy the `scan` required check, but `check` (Check MCP URLs) and `validate` (Validate Plugins) are also required on main and likewise never fired — leaving every bump PR BLOCKED on missing checks (observed on the batched #2079, which only cleared after a human-authored push re-fired the pull_request workflows). Fix: dispatch all three workflows per per-entry bump branch. Each runs its job unconditionally on workflow_dispatch, so the check run lands on the branch HEAD (= PR head) and satisfies the required check. - validate-plugins.yml: add workflow_dispatch trigger (check-mcp-urls.yml already had one). gh workflow run requires the trigger on the default branch; this lands together with the per-entry bump so main stays consistent. - bump-plugin-shas.yml: loop the dispatch over {scan-plugins,check-mcp-urls,validate-plugins}; tolerate a single transient dispatch failure (warn, don't abort) so one hiccup can't strand the rest of the batch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * bump: fail the per-entry check-dispatch step when a dispatch fails The dispatch step logged each failed gh workflow run as a warning and exited 0, so a transient API error or rate limit could leave a per-entry bump PR missing a required check while the bump run still showed green. The composite action skips slugs with an open PR, so the stranded PR was never retried. Attempt every dispatch (one failure must not strand the other branches), record failures via a temp file (the while loop runs in a pipe subshell), then emit an error and exit non-zero if any dispatch failed, so the bump run goes red and the affected PR can be re-dispatched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude Code Plugins Directory
A curated directory of high-quality plugins for Claude Code.
⚠️ Important: Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended or that they won't change. See each plugin's homepage for more information.
Structure
/plugins- Internal plugins developed and maintained by Anthropic/external_plugins- Third-party plugins from partners and the community
Installation
Plugins can be installed directly from this marketplace via Claude Code's plugin system.
To install, run /plugin install {plugin-name}@claude-plugins-official
or browse for the plugin in /plugin > Discover
Contributing
Internal Plugins
Internal plugins are developed by Anthropic team members. See /plugins/example-plugin for a reference implementation.
External Plugins
Third-party partners can submit plugins for inclusion in the marketplace. External plugins must meet quality and security standards for approval. To submit a new plugin, use the plugin directory submission form.
Plugin Structure
Each plugin follows a standard structure:
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Plugin metadata (required)
├── .mcp.json # MCP server configuration (optional)
├── commands/ # Slash commands (optional)
├── agents/ # Agent definitions (optional)
├── skills/ # Skill definitions (optional)
└── README.md # Documentation
Skill-bundle plugins
When a plugin's source repository ships skills (SKILL.md files) without a .claude-plugin/plugin.json manifest, the marketplace entry can declare the skills directly using strict: false and an explicit skills array.
{
"name": "example-bundle",
"description": "Brief description of the bundled skills.",
"author": { "name": "Author Name" },
"category": "development",
"source": {
"source": "git-subdir",
"url": "https://github.com/example-org/sdk.git",
"path": "packages/agent-skills",
"ref": "main",
"sha": "<commit sha>"
},
"strict": false,
"skills": [
"./skill-a",
"./skill-b",
"./skill-c"
],
"homepage": "https://github.com/example-org/sdk"
}
Each path in skills is relative to source.path and points at a directory containing a SKILL.md. Paths can reach deeper than a single level — for example, ["./libA/skill-1", "./libB/skill-2"] exposes a curated subset across multiple library subdirectories. Each skill is registered as <plugin-name>:<skill-name> in Claude Code.
For the underlying schema, see Strict mode in the marketplace documentation.
License
Please see each linked plugin for the relevant LICENSE file.
Documentation
For more information on developing Claude Code plugins, see the official documentation.