679f52da9e
Adds an `emit-verdict` job to scan-plugins.yml that posts a sticky comment per scanned entry to the corresponding bump PR, with marker `<!-- bump-pr-verdict:<name> -->`. The body is a schema_v1 JSON block, the same shape `anthropics/claude-plugins-community-internal`'s `scan-external-plugins.yml` already emits, so any consumer that already reads verdicts from that schema works uniformly across both repos. What this enables ----------------- Lets downstream consumers (label automation, dashboards, anything that wants per-entry verdict signal) read verdicts directly from the PR rather than scraping job logs or downloading artifacts. The current options are log-scraping (truncated after log retention) or fetching the `scan-verdicts` artifact (retention-limited and only after upload succeeds). What does NOT change -------------------- - The `scan` required check is unaffected (emit-verdict is `continue-on-error: true` at the job level — failures here MUST NOT block the required gate). - Verdict cache, scan flow, and revert-failed-bumps.yml are unchanged. - No new permission scopes (uses `pull-requests: write` at the job level, identical to other PR-commenting jobs in this repo). Schema notes ------------ - `scan.*` axes (clone, schema, binaries, etc.) emit as "skipped" — this workflow runs the policy review only, not per-entry static checks. Shape kept compatible with -internal's schema_v1 so the same consumers work uniformly on both repos. - `policy.has_broad_scope_hooks`, `has_undisclosed_telemetry`, `description_matches_behavior` emit as null — those granular axes aren't surfaced by this workflow's per-entry artifact yet. Consumers that map `null → "?"` for display already handle this gracefully. - `policy.status` is execution state (not outcome). Map source → status: scan-action-run → "ran"; cache-served → "cached". Outcome lives in `policy.passes`. policy.status vocabulary matches the `ran|cached|missing|gated_out|infra_error` convention from -internal's emit-verdict. PR resolution ------------- `pull_request` events carry the PR number directly. The bump workflow creates bump PRs via GITHUB_TOKEN (which doesn't fire `pull_request` triggers — recursion guard) and dispatches this scan via `workflow_dispatch` on the bump branch; in that case the job looks up the open PR by head ref via REST. No PR found (scan_all dispatch on main, etc.) → no-op with notice. Co-authored-by: Claude Opus 4.7 (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.