Verified by Sigistry
A Claude Code plugin can run hooks on your machine, spawn subagents with tools, and inject skills straight into your agent's context. 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, injection-free skills, and no secrets.
What Sigistry verifies
Sigistry applies one open, evidence-cited method across the agent supply chain. This page is the plugin surface; the others are one click away.
Plugins
Eight static security checks, re-run by CI on every change.
You are hereSkills
Screened for prompt-injection, greedy triggers, and unsafe scripts.
Learn more →A–F scorecardMCP servers
Graded against the 2026-07-28 spec, with evidence and a right to respond.
Learn more →Safety checkerMCP AppsNew
ui:// resources checked for spec conformance and sandbox hygiene.
Learn more →The eight checks
Verification is a pass/fail run of eight static checks. All eight 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.
Skill safety
A SKILL.md is injected into the agent’s context when it triggers, which makes skills a prompt-injection surface. Verified skills are statically confirmed to shadow no built-in or plugin command, declare honestly-scoped triggers (no "use on every request"), contain no instruction-override, concealment, or exfiltration language, and ship no scripts that pipe remote content to a shell, decode hidden payloads, read credential files, or send secrets to the network.
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 with the exact checks CI runs. Locally:Or from inside the Claude session that is building your plugin: connect the registry MCP server (
claude mcp add --transport http sigistry https://sigistry.com/mcp) and ask Claude to runverify_plugin. It hands Claude the recipe to run this same verifier locally, so your code never leaves your machine and nothing needs to be published first. - 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 sigistry.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 Sigistry badge mean?
It means the plugin passed all eight checks of the Sigistry verification methodology at its current version: manifest integrity, hook safety, agent tool scopes, command hygiene, skill structure, skill safety, no secrets, and documentation. The checks that matter most: hooks run arbitrary commands on your machine, and skills inject text straight into your agent’s context, so verified plugins are statically confirmed to ship only advisory fail-safe hooks and injection-free, honestly-scoped skills.
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. When the v1.1 skill-safety check landed, it immediately failed 10 of our own 19 plugins on skill naming discipline, which we fixed before shipping the check. Failures either get fixed or the plugin stays unverified, and its badge URL renders a gray not-verified badge.
Why do skills need their own safety check?
Because a skill is not code that runs in a sandbox, it is text injected directly into the agent’s context when the skill triggers. A hostile skill can attempt to override the agent’s instructions, conceal actions from the user, trigger greedily on every request to hijack unrelated work, or ship helper scripts that exfiltrate credentials. The skill-safety check statically screens for command shadowing, greedy triggers, instruction-override and concealment language, and unsafe script patterns. Static heuristics have limits, which is why the methodology is public and every result lists exactly what was checked.
Is the badge just an image, or is the status machine-readable?
Both. The SVG badge is served at sigistry.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 eight 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 eight 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.