Verified by ClaudeRegistry
A Claude Code plugin can run hooks on your machine, spawn subagents with tools, and shape what your AI does. The badge means we statically verified, with an open-source script and published criteria, that a plugin is safe to install: honest manifests, advisory-only hooks, least-privilege agents, and no secrets.
The seven checks
Verification is a pass/fail run of seven static checks. All seven must pass at the plugin's current version. Nothing is executed; every check reads source.
Manifest integrity
plugin.json is valid and complete (name, version, license, description), and every command, agent, and skill the marketplace entry advertises exists on disk, in both directions. No drift between what is listed and what ships.
Hook safety
Hook scripts are advisory-only and fail-safe: no network calls, no filesystem writes, no credential or .env access, no dynamic code evaluation, and an unconditional exit(0) inside try/catch so a hook bug can never block your session. Subprocess use is allowed only for constant, read-only git commands.
Agent tool scopes
Every subagent declares an explicit least-privilege tools list. Analysis-type agents (auditors, scanners, reviewers) must not carry Write or Edit; only agents whose stated job is producing or changing files may.
Command hygiene
Every command carries frontmatter with a description, so what it does is inspectable before you run it.
Skill structure
Every skill has a valid SKILL.md with name and description, and every reference file the skill points to actually exists.
No secrets
No credentials, API keys, tokens, or private keys anywhere in the plugin. Documentation may show redacted teaching examples; executable code may not contain secrets at all.
Documentation
A substantive README that documents purpose, the correct installation commands, and usage.
How it runs
- The methodology is code: scripts/verify-plugins.mjs in the marketplace repository. Read it, run it, challenge it.
- Results are machine-readable: verified.json records every check, its evidence, and the date, per plugin and per version.
- Failures are real. The first full run failed 5 of 16 plugins; the findings were fixed (including a README that documented the wrong install commands) and the methodology kept the stricter rules.
- CI enforces it: a GitHub Action re-runs every check on every pull request and fails the build if any plugin fails or if verified.json no longer matches the code, so a badge can never silently drift from what it vouches for.
Submit your plugin
External plugins are welcome, in three tiers. Listed: your plugin stays in your own repository and the registry points at it; no badge, because nothing pins what the code is. Verified at commit: your plugin stays in your repository, but you pin a commit SHA; we clone and verify exactly that commit, your badge reads verified @<sha>, and a daily drift watchdog flips it to outdated if your repo moves past the pin. Verified (strongest): your plugin is vendored into the registry via pull request and re-verified by CI on every change, so the badge always describes exactly what users install. All verified tiers include a human review of hook and agent code. Four steps:
- Self-check locally with the exact checks CI runs:
- Fork the marketplace repository and either vendor your plugin under
plugins/<your-plugin-name>/, or keep it in your repo and add a commit pin (repo, SHA, path) to.claude-plugin/external-pins.jsonalongside your marketplace.json entry (see CONTRIBUTING.md). - Regenerate
verified.json(node scripts/verify-plugins.mjs) and open the PR. CI re-runs everything; a maintainer reviews your hook and agent code by hand. - On merge, your plugin is live in the registry with its badge at a stable URL.
Embed the badge
Every verified plugin has a badge at clauderegistry.com/badge/<plugin-id>.svg. It links back to the plugin's page, where the per-check results are shown. Drop this in your README and replace PLUGIN-ID:
FAQ
What does the Verified by ClaudeRegistry badge mean?
It means the plugin passed all seven checks of the ClaudeRegistry verification methodology at its current version: manifest integrity, hook safety, agent tool scopes, command hygiene, skill structure, no secrets, and documentation. The check that matters most: hooks run arbitrary commands on your machine, so verified plugins are statically confirmed to ship only advisory, fail-safe, non-network hooks.
How is verification performed?
By an open-source static-analysis script (scripts/verify-plugins.mjs in the marketplace repository). It reads every file in the plugin and never executes anything. The script writes a machine-readable verified.json, which is the source of truth for every badge. Verification is re-run when a plugin version changes.
Can a plugin fail verification?
Yes, and the methodology has teeth: on its first full run it failed 5 of 16 plugins, including one whose README documented the wrong installation commands entirely. Failures either get fixed or the plugin stays unverified, and its badge URL renders a gray not-verified badge.
Is the badge just an image, or is the status machine-readable?
Both. The SVG badge is served at clauderegistry.com/badge/<plugin-id>.svg, and the underlying verified.json (per-check results, dates, methodology version) is public in the marketplace repository, so agents and CI systems can consume the raw data.
Can I get my own plugin verified?
Yes. Run the verifier against your plugin locally (node scripts/verify-plugins.mjs path/to/your-plugin), then open a PR vendoring your plugin into the marketplace repository. CI re-runs the same seven checks and blocks any PR where verified.json is stale, and a maintainer reviews your hook and agent code by hand before merge. On merge your plugin is listed, verified, and its badge goes live.
Do I have to move my plugin into the registry repository to get verified?
No. You can keep your plugin in your own repository and get verified at a pinned commit: we clone exactly that commit, run all seven checks against it, and your badge reads "verified @<short-sha>", a claim that stays true forever because a commit cannot change. A daily drift watchdog compares your repo HEAD to the pin; the moment you push past the verified commit, the badge flips to "outdated" until you re-pin and re-verify. Vendoring into the registry remains the strongest tier: there the badge always describes exactly what users install.
What stops an author from changing the code after earning the badge?
For vendored plugins, nothing can change without re-verification: CI re-runs every check on every change to the registry repository. For externally-hosted pinned plugins, the badge only ever vouches for the pinned commit, and the daily drift watchdog marks the plugin "outdated" as soon as the repository moves past that commit. In both cases the badge cannot keep vouching for code nobody checked.